Recently the version of libgcrypt was increased to 1.1.94 as a result of this newpg would not build against the newer libgcrypt i sent an email to gcrypt-devel list and this is what i got back
<quote> Don't build newpg at all. It has been superseded by gnupg-1.9.x .
You would need an old libgcrypt < 1.1.42 to build it. The configure sscript was not able to detect newer versions with a changed API. </quote>
we have a problem here seems we no longer need newpg but we need things it provides for gpgme gpgme03 cryptplug gpa kgpg (which doesnt complain so much just says its not there) to get these things it provides we need to go to the newer gnupg or we need to revert back to the older libgcrypt.
being so late in the cycle i dont know which would be best. so i thought id ask before filling a bug against something. it does need to be fixed before final is out as people will complain if they cant decrypt email in kmail or mutt gpa doesnt work etc. i think we should probably go back to the old version of libgcrypt
Dennis
Dennis Gilmore (dennis@ausil.us) said:
Recently the version of libgcrypt was increased to 1.1.94 as a result of this newpg would not build against the newer libgcrypt i sent an email to gcrypt-devel list and this is what i got back
<quote> Don't build newpg at all. It has been superseded by gnupg-1.9.x .
You would need an old libgcrypt < 1.1.42 to build it. The configure sscript was not able to detect newer versions with a changed API.
</quote>
we have a problem here seems we no longer need newpg but we need things it provides for gpgme gpgme03 cryptplug gpa kgpg (which doesnt complain so much just says its not there) to get these things it provides we need to go to the newer gnupg or we need to revert back to the older libgcrypt.
being so late in the cycle i dont know which would be best. so i thought id ask before filling a bug against something. it does need to be fixed before final is out as people will complain if they cant decrypt email in kmail or mutt gpa doesnt work etc. i think we should probably go back to the old version of libgcrypt
For a third-party package we don't ship? It's probably not going to happen at this point. Note that, for example, mutt with gnupg will work pretty much the same as it normally does in core - it doesn't require libgcrypt.
libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
Bill
Once upon a time Sunday 02 May 2004 12:53 pm, Bill Nottingham wrote:
Dennis Gilmore (dennis@ausil.us) said:
For a third-party package we don't ship? It's probably not going to happen at this point. Note that, for example, mutt with gnupg will work pretty much the same as it normally does in core - it doesn't require libgcrypt.
libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
Bill
well fedora.us has quite a few packages that do require it ie gpgme gpgme03 cryptplug. mutt needs gpgme03 kmail uses cryptplug which needs gpgme03 so you are breaking packages in fedora.us and saying too bad not good, consideration has to be taken to packages in extras and it seems its not. so it leaves us to upping gnupg to a version that is considered alpha to support the extras tree or does that not come into consideration?
So far the fedora project seems to be Red Hat doing what it wants with slightly more input from others but no real effort to open the project up. for a while now ive been starting to get a bad taste in my mouth about the whole thing and more and more it seems to be justified.
Dennis
Dennis Gilmore (dennis@ausil.us) said:
For a third-party package we don't ship? It's probably not going to happen at this point. Note that, for example, mutt with gnupg will work pretty much the same as it normally does in core - it doesn't require libgcrypt.
libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
well fedora.us has quite a few packages that do require it ie gpgme gpgme03 cryptplug. mutt needs gpgme03
mutt doesn't use gpgme at all without adding external patches and rebuilding first. Ergo, not a concern for Core or Extras, only Alternatives.
kmail uses cryptplug which needs gpgme03 so you are breaking packages in fedora.us and saying too bad not good
gpgme03 actually builds without newpg just fine, and therefore doesn't depend on libgcrypt. I assume you've built it that way explicitly for S/MIME?.
consideration has to be taken to packages in extras and it seems its not.
TBH, it's the first time I've heard of this conclict. In some cases, it is impossible to test against the entirety of fedora.us, especially when it's not all even built for FC2.
so it leaves us to upping gnupg to a version that is considered alpha to support the extras tree or does that not come into consideration?
Thats *a* alternative (fedora.us is shipping 'alpha' gpgme, anyway), but not a good one. Carrying around a libgcrypt1 compat library certainly seems much simpler, and would be trivial to package.
So far the fedora project seems to be Red Hat doing what it wants with slightly more input from others but no real effort to open the project up.
Yes, exactly! We want to ram everything down your throat. MUWHAHAHAHA. WE WILL BREAK YOUR SOFTWARE AND CRUSH YOU, YOU INSIGNIFICANT WORM! Next step, looting, pillaging, and rampaging.
We're just trying to add functionality requested by our users.
Bill
Once upon a time Sunday 02 May 2004 3:00 pm, Bill Nottingham wrote:
Dennis Gilmore (dennis@ausil.us) said:
kmail uses cryptplug which needs gpgme03 so you are breaking packages in fedora.us and saying too bad not good
gpgme03 actually builds without newpg just fine, and therefore doesn't depend on libgcrypt. I assume you've built it that way explicitly for S/MIME?.
yes both gpgme and gpgme03 are built with s/MIME support in fedora.us
Dennis
Dennis Gilmore (dennis@ausil.us) said:
kmail uses cryptplug which needs gpgme03 so you are breaking packages in fedora.us and saying too bad not good
gpgme03 actually builds without newpg just fine, and therefore doesn't depend on libgcrypt. I assume you've built it that way explicitly for S/MIME?.
yes both gpgme and gpgme03 are built with s/MIME support in fedora.us
So, the package that comes down to breaking is newpg, correct?
libgcrypt actually will get upgraded again, to 1.2.0. It's the Right Thing To Do, as it's the first official stable release that they've done; even the previous 1.1.12 (or whatever) series wasn't deemed as such by then. So it's really the version we should be shipping, and we do have an app that uses it.
In the short term, yes, we should probably have a libgcrypt1 package in extras. In the long term, core should move to gnupg-2.0, and some of this will go away. (In fact, just the fact that there's gpgme03 and gpgme package shows problems... everything should really be using one interface.)
Bill
Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
Dennis Gilmore (dennis@ausil.us) said:
kmail uses cryptplug which needs gpgme03 so you are breaking packages in fedora.us and saying too bad not good
gpgme03 actually builds without newpg just fine, and therefore doesn't depend on libgcrypt. I assume you've built it that way explicitly for S/MIME?.
yes both gpgme and gpgme03 are built with s/MIME support in fedora.us
So, the package that comes down to breaking is newpg, correct?
yes newpg wont build at present. and yes i saw they said that 1.2.0 was the first stable release it seems that the whole gnupg project has a weird mix of dependacies stable software relying on unstable and alpha software
libgcrypt actually will get upgraded again, to 1.2.0. It's the Right Thing To Do, as it's the first official stable release that they've done; even the previous 1.1.12 (or whatever) series wasn't deemed as such by then. So it's really the version we should be shipping, and we do have an app that uses it.
ill work on a libgcrypt1 package in the intrim solution. using gnupg2 would reslove most if not all of the problems
In the short term, yes, we should probably have a libgcrypt1 package in extras. In the long term, core should move to gnupg-2.0, and some of this will go away. (In fact, just the fact that there's gpgme03 and gpgme package shows problems... everything should really be using one interface.)
they seem to update some things and not others. it seems in a much bigger mess that pwlib and openh323
Dennis
On Sun, 2004-05-02 at 08:38, Dennis Gilmore wrote:
Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
So, the package that comes down to breaking is newpg, correct?
Yes.
ill work on a libgcrypt1 package in the intrim solution. using gnupg2 would reslove most if not all of the problems
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
Once upon a time Sunday 02 May 2004 9:51 pm, Ville Skyttä wrote:
On Sun, 2004-05-02 at 08:38, Dennis Gilmore wrote:
Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
So, the package that comes down to breaking is newpg, correct?
Yes.
ill work on a libgcrypt1 package in the intrim solution. using gnupg2 would reslove most if not all of the problems
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
should we just package a gnupg2 package now? can it be done cleanly to have 2 versions of gnupg on the system at once? we will need to file a bug against gnupg i guess to try and make sure that when it gets to gnupg2 that we have the Obsoletes: newpg in it.
Dennis
On Sun, 2004-05-02 at 14:51, Ville Skyttä wrote:
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages in fedora.us which have been "fixed" according to the above.
On Sun, May 23, 2004 at 06:16:11PM +0300, Ville Skyttä wrote:
On Sun, 2004-05-02 at 14:51, Ville Skyttä wrote:
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages in fedora.us which have been "fixed" according to the above.
newpg has been obsoleted in favour of gnupg2 by its own authors, and since it is a security crucial package I would make the jump to gnupg2 now, otherwise you may have security maintenance problems with newpg.
Have a look at ATrpms.net, if you like.
Ville Skyttä wrote:
On Sun, 2004-05-02 at 14:51, Ville Skyttä wrote:
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages in fedora.us which have been "fixed" according to the above.
Just a followup to an old thread... gnupg2 and gpgme have now been submitted to fedora.us:
gnupg2: http://bugzilla.fedora.us/show_bug.cgi?id=2179 gpgme: http://bugzilla.fedora.us/show_bug.cgi?id=2180
-- Rex
Once upon a time Thursday 28 October 2004 2:57 pm, Rex Dieter wrote:
Ville Skyttä wrote:
On Sun, 2004-05-02 at 14:51, Ville Skyttä wrote:
As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I believe we can find a clean solution by packaging libgcrypt1 and changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages in fedora.us which have been "fixed" according to the above.
Just a followup to an old thread... gnupg2 and gpgme have now been submitted to fedora.us:
gnupg2: http://bugzilla.fedora.us/show_bug.cgi?id=2179 gpgme: http://bugzilla.fedora.us/show_bug.cgi?id=2180
-- Rex
FC3 will not need cryptplug for kmail as kmail now includes the necessary support. however it does need gpgme i will run some tests to see if we can drop gpgme03
Dennis
On Thu, 28 Oct 2004 20:05:19 -0500, Dennis Gilmore wrote:
FC3 will not need cryptplug for kmail as kmail now includes the necessary support. however it does need gpgme i will run some tests to see if we can drop gpgme03
We don't drop gpgme03 because software using the old GPGME API has not been ported to the new API yet, e.g. Sylpheed and Sylpheed-claws.
Dennis Gilmore wrote:
Rex Dieter wrote:
Just a followup to an old thread... gnupg2 and gpgme have now been submitted to fedora.us: gnupg2: http://bugzilla.fedora.us/show_bug.cgi?id=2179 gpgme: http://bugzilla.fedora.us/show_bug.cgi?id=2180
FC3 will not need cryptplug for kmail as kmail now includes the necessary support.
To be precise, kmail needs both gpgme and gnupg2 to provide what cryptplug formerly did. Ideally, kmail (kdenetwork) could be built against gpgme's shared library too.
-- Rex
On Sun, May 02, 2004 at 10:37:22AM +1000, Dennis Gilmore wrote:
Recently the version of libgcrypt was increased to 1.1.94 as a result of this newpg would not build against the newer libgcrypt
newpg has been flagged as obsoleted by the authors in favour of gnupg2. You can get working copies of gnupg/gnupg2, gpgme, libgcrypt, libassuan, libksba at ATrpms.net for FC1 back to RH7.3. FC2 will also be supported when it gets released.
-
Axel Thimm -
Bill Nottingham -
Dennis Gilmore -
Michael Schwendt -
Rex Dieter -
Ville Skyttä