I'm rebasing libgcrypt in rawhide to libgcrypt-1.6.1. The new upstream release contains many improvements over the old one especially in terms of new crypto algorithm support and performance improvements.
Unfortunately the rebase bumps soname to libgcrypt.so.20 due to dropping some long-ago deprecated API calls. This should not break builds of any reasonably current software. I've included the temporary old shared library so the buildroots are not broken.
I will try to rebuild the dependencies eventually.
Regards,
Tomas Mraz wrote:
I'm rebasing libgcrypt in rawhide to libgcrypt-1.6.1. The new upstream release contains many improvements over the old one especially in terms of new crypto algorithm support and performance improvements.
Unfortunately the rebase bumps soname to libgcrypt.so.20 due to dropping some long-ago deprecated API calls. This should not break builds of any reasonably current software. I've included the temporary old shared library so the buildroots are not broken.
I will try to rebuild the dependencies eventually.
Including MinGW list -- ping epienbroek, rjones
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
Richard.
On Fri, 2014-02-28 at 19:37 +0000, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
Since google-chrome-stable is not part of the distribution I do not see why we should keep a compat package.
OTOH important libraries that still break soname instead of using symbol versioning in 2014 really make me frown loudly...
Simo.
On Fri, 28 Feb 2014 20:29:12 +0000 Richard Hughes hughsient@gmail.com wrote:
On 28 Feb 2014 19:51
OTOH important libraries that still break soname instead of using symbol versioning in 2014 really make me frown loudly..
Is there a best practice guide here? I'm guilty of breaking soname in my stuff every few years...
I think www.akkadia.org/drepper/dsohowto.pdf is still the primary documentation
Dan
Dne 28.2.2014 20:51, Simo Sorce napsal(a):
On Fri, 2014-02-28 at 19:37 +0000, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
Since google-chrome-stable is not part of the distribution I do not see why we should keep a compat package.
Not that I am Chrome user, but AFAIK, the compat-packages are exactly for third party stuff used on Fedora. Here is some previous discussion on this topic:
https://lists.fedoraproject.org/pipermail/packaging/2009-August/006431.html
Vít
On 03/03/2014 10:13 AM, Vít Ondruch wrote:
Dne 28.2.2014 20:51, Simo Sorce napsal(a):
On Fri, 2014-02-28 at 19:37 +0000, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
Since google-chrome-stable is not part of the distribution I do not see why we should keep a compat package.
Not that I am Chrome user, but AFAIK, the compat-packages are exactly for third party stuff used on Fedora.
My sentiments exactly. In Fedora package collection, we can rebuild / fix up all the packages to make use of the new ABI, but the main reason to have compat packages is the 3rd party stuff.
Workstation is trying to come up with ways to offer a stable base platform that 3rd party developers could target [1], and in my opinion libgcrypt should be part of that base ABI.
I would be happy to look the other way if we had Chromium in the Fedora repo, but since we don't, I think it would make sense to try and make Chrome's life easier by keeping the underlying libraries stable. After all, the "fix" that would come from the Chrome / Chromium side would likely be bundling the libgcrypt binaries with the upstream rpm.
On Pá, 2014-02-28 at 14:51 -0500, Simo Sorce wrote:
On Fri, 2014-02-28 at 19:37 +0000, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
Since google-chrome-stable is not part of the distribution I do not see why we should keep a compat package.
OTOH important libraries that still break soname instead of using symbol versioning in 2014 really make me frown loudly...
I'm sorry but this is not glibc and the thing that was dropped is an long ago deprecated API which simply cannot be supported by the codebase anymore if it wanted to evolve reasonably. Adding it only as fake API calls which would fail would not help much I suppose.
The problem is that when a library API is written from scratch it is sometimes unavoidable to make mistakes in the design of the API that for any reasonable further development of the library the API calls have to be dropped.
Of course once the API becomes mature such API call drops should be avoided if possible.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2014 02:37 PM, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz tmraz@redhat.com wrote:
This should not break builds of any reasonably current software.
libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64
I guess not much we can do there, other than maintain a compat package -- right? :(
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt. Note: I have not tested it for any use other than making sure that Google Chrome runs with it. I will try to keep it updated with any security updates that come out for F20, but I make no promises. Use at your own risk.
For the record, I am currently running successfully on Rawhide with Google Chrome.
(For the record, this does not replace the standard libgcrypt; it supplements it. So anything built normally in Koji will be linked with the updated .so.20 version).
Richard.
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
On Wed, Jul 2, 2014 at 11:19 PM, Kalev Lember kalevlember@gmail.com wrote:
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
Why not blame Google to update their environments??
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/02/2014 11:19 AM, Kalev Lember wrote:
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
Short answer: no. I don't have the time or inclination to attempt to maintain a compat *crypto* library. There's far too much possibility for disaster there.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
On 07/02/2014 11:19 AM, Kalev Lember wrote:
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
Short answer: no. I don't have the time or inclination to attempt to maintain a compat *crypto* library. There's far too much possibility for disaster there.
To clarify: in my COPR, it's use-at-your-own-risk. If we moved it to Rawhide, I'm on the hook to make sure it's constantly kept up-to-date and keep track of vulnerabilities. I'm not prepared to take that level of ownership on. I only built this COPR because I was updating to Rawhide today and this bit me. I'm being nice and sharing it, with the expectation that it's really only meant for this singular use-case, which should be obsoleted as soon as Google moves to the newer libgcrypt (or bundles their own, whatever).
On 07/02/2014 05:24 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
On 07/02/2014 11:19 AM, Kalev Lember wrote:
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
Short answer: no. I don't have the time or inclination to attempt to maintain a compat *crypto* library. There's far too much possibility for disaster there.
Fair enough, that's totally understandable if you don't want to maintain a crypto library. I just had to ask :)
However, we've got a F21 release looming closer and I'd like to make sure major 3rd party apps keep working out of the box. And yes, this includes Chrome.
This is especially important since we don't have Chromium in the Fedora repositories; otherwise we could tell users to use that instead.
I feel like this is our (Fedora's) responsibility to provide a libgcrypt compat package, since it's been part of standard ABI for a while and 3rd party packages are likely to rely on it. In my book, it's fine to phase a widely used ABI out, but not pull the plug in a single release.
It's unreasonable to ask 3rd party developers to follow Rawhide closely and port stuff while F21 is still under development. A much better 3rd party developer story would be saying:
"Hi Mr. 3rd Party Developer, we've released F21 today with a new libcrypt. We'll remove old libcrypt in F22 but we are providing ABI compatiblity for F21 lifetime; you have 6 months to port your stuff."
Anyone here interested in maintaining a libgcrypt compat package for F21 lifetime? I'd be happy to help sort out packaging and get this through the review process.
To clarify: in my COPR, it's use-at-your-own-risk. If we moved it to Rawhide, I'm on the hook to make sure it's constantly kept up-to-date and keep track of vulnerabilities. I'm not prepared to take that level of ownership on. I only built this COPR because I was updating to Rawhide today and this bit me. I'm being nice and sharing it, with the expectation that it's really only meant for this singular use-case, which should be obsoleted as soon as Google moves to the newer libgcrypt (or bundles their own, whatever).
I'm afraid that this could lead to technically capable people using your copr because it provides an easy way out, and leaving others out in the cold. People who'd be able to fix this in rawhide proper switch to using your copr, and end users who expect point and click Chrome installation to work are going to be disappointed and look for alternatives.
On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember kalevlember@gmail.com wrote:
Anyone here interested in maintaining a libgcrypt compat package for F21 lifetime? I'd be happy to help sort out packaging and get this through the review process.
Have you got any response from Google actually?
On 07/02/2014 06:11 PM, Christopher Meng wrote:
On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember kalevlember@gmail.com wrote:
Anyone here interested in maintaining a libgcrypt compat package for F21 lifetime? I'd be happy to help sort out packaging and get this through the review process.
Have you got any response from Google actually?
You must be confusing me with someone else. I am not a libgcrypt maintainer and haven't talked to Google about this.
On Thu, Jul 3, 2014 at 12:22 AM, Kalev Lember kalevlember@gmail.com wrote:
You must be confusing me with someone else. I am not a libgcrypt maintainer and haven't talked to Google about this.
No.
It's a burden for downstream to ship such a compat- package for chrome only, and chrome is not a part of Fedora.
On Thu, Jul 03, 2014 at 12:35:26AM +0800, Christopher Meng wrote:
It's a burden for downstream to ship such a compat- package for chrome only, and chrome is not a part of Fedora.
Maintaining software in general is a burden, but we do it for the benefit of our users anyway. The best case scenario would certainly be for Google to update their packages, but if they don't then how does rendering the package uninstallable benefit our users who want to install it?
On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Thu, Jul 03, 2014 at 12:35:26AM +0800, Christopher Meng wrote:
It's a burden for downstream to ship such a compat- package for chrome only, and chrome is not a part of Fedora.
Maintaining software in general is a burden, but we do it for the benefit of our users anyway. The best case scenario would certainly be for Google to update their packages, but if they don't then how does rendering the package uninstallable benefit our users who want to install it?
I don't think they "don't" if you could give google-chrome-unstable a try.
On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote:
On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
Maintaining software in general is a burden, but we do it for the benefit of our users anyway. The best case scenario would certainly be for Google to update their packages, but if they don't then how does rendering the package uninstallable benefit our users who want to install it?
I don't think they "don't" if you could give google-chrome-unstable a try.
I don't follow. My understanding was that all the Chrome builds were generic RPMs rather than tracking a specific branch of Fedora, so how does the rate of development releases do anything to help us get them to update their packages to build against a more recent gcrypt?
On Wed, Jul 02, 2014 at 06:03:33PM +0200, Kalev Lember wrote:
On 07/02/2014 05:24 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
On 07/02/2014 11:19 AM, Kalev Lember wrote:
On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
This is not an official solution, but I am now providing a COPR for Rawhide installs that provides a compatibility library for libgcrypt.
That's awesome, but can we get this in rawhide proper instead? I'd be happy to help get this through the review process if you need a reviewer.
Short answer: no. I don't have the time or inclination to attempt to maintain a compat *crypto* library. There's far too much possibility for disaster there.
Fair enough, that's totally understandable if you don't want to maintain a crypto library. I just had to ask :)
However, we've got a F21 release looming closer and I'd like to make sure major 3rd party apps keep working out of the box. And yes, this includes Chrome.
This is especially important since we don't have Chromium in the Fedora repositories; otherwise we could tell users to use that instead.
In this specific case, users have two options: – use Chromium from Spot's repository – use Chromium from Russian Fedora repository
Third option is: – use compat libgcrypt from Stephen's repository.
Those are not really different, but I suppose maintaining multiple version of crypto library is worse. Either way, it is up to Google to provide precompiled software with up-to-date environment.
-
Christopher Meng -
Dan Horák -
Kalev Lember -
Matthew Garrett -
Michael Cronenworth -
Richard Hughes -
Simo Sorce -
Stephen Gallagher -
Tomas Mraz -
Tomasz Torcz -
Vít Ondruch