9:38 a.m.
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
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10:50 a.m.
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
1:37 p.m.
On 28 February 2014 15:38, Tomas Mraz <tmraz(a)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.
1:51 p.m.
On Fri, 2014-02-28 at 19:37 +0000, Richard Hughes wrote:
On 28 February 2014 15:38, Tomas Mraz <tmraz(a)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.
--
Simo Sorce * Red Hat, Inc * New York
2:34 p.m.
On Fri, 28 Feb 2014 20:29:12 +0000
Richard Hughes <hughsient(a)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
3:13 a.m.
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(a)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
3:54 a.m.
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(a)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.
--
Kalev,
also not a Chrome user.
[1] See the "3rd party software" bullet point in the Workstation PRD:
https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Overall_plans_...
10:01 a.m.
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(a)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.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
10:13 a.m.
-----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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO0IY4ACgkQeiVVYja6o6MCUACfbARjh/JlrX2Kd/40SzHYdJVm
nmgAn3wcxXSUa15VX2cAIT651ZQLi6D+
=XlIR
-----END PGP SIGNATURE-----
10:19 a.m.
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.
--
Thanks,
Kalev
10:20 a.m.
On Wed, Jul 2, 2014 at 11:19 PM, Kalev Lember <kalevlember(a)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??
10:22 a.m.
-----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 SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO0I7MACgkQeiVVYja6o6PIEQCgkV/CpCi43z25Nz/W1y+dpDsP
C2IAoICVySLOxqhJFSrxVxxv2CY08tdv
=TomH
-----END PGP SIGNATURE-----
10:24 a.m.
-----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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlO0JDcACgkQeiVVYja6o6NLSgCfQVvwmyK+szYOCSq8O35H/wtx
1J4An0VYxt3tSGteebrzwOWQMwy434GH
=jSLy
-----END PGP SIGNATURE-----
11:03 a.m.
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.
--
Kalev
11:11 a.m.
On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember <kalevlember(a)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?
11:22 a.m.
On 07/02/2014 06:11 PM, Christopher Meng wrote:
On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember
<kalevlember(a)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.
--
Kalev
11:35 a.m.
On Thu, Jul 3, 2014 at 12:22 AM, Kalev Lember <kalevlember(a)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.
https://code.google.com/p/chromium/issues/detail?id=369973
12:11 p.m.
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?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:20 p.m.
On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett <mjg59(a)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.
1:27 p.m.
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(a)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?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:15 p.m.
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.
--
Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded
processor.''
xmpp: zdzichubg(a)chrome.pl -- Mitchell Blank on LKML
3586
days inactive
3710
days old
21 comments
11 participants
participants (11)
-
Christopher Meng -
Dan Horák -
Kalev Lember -
Matthew Garrett -
Michael Cronenworth -
Richard Hughes -
Simo Sorce -
Stephen Gallagher -
Tomas Mraz -
Tomasz Torcz -
Vít Ondruch