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
On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote:
> On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett 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
On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett 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 w
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 scen
On Thu, Jul 3, 2014 at 12:22 AM, Kalev Lember 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.
http
On 07/02/2014 06:11 PM, Christopher Meng wrote:
> On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember 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
On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember 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?
--
devel mailing list
dev
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 a
-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 provide
-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'
On Wed, Jul 2, 2014 at 11:19 PM, 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
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 re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/28/2014 02:37 PM, Richard Hughes wrote:
> On 28 February 2014 15:38, Tomas Mraz 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.1
On Pá, 2014-02-28 at 14:51 -0500, Simo Sorce wrote:
> On Fri, 2014-02-28 at 19:37 +, Richard Hughes wrote:
> > On 28 February 2014 15:38, Tomas Mraz wrote:
> > > This should not break builds of any reasonably current software.
> >
> > libgcrypt.so.11()(64bit) is needed by (installed)
> > goog
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 +, Richard Hughes wrote:
>>> On 28 February 2014 15:38, Tomas Mraz wrote:
This should not break builds of any reasonably current software.
>>> libgcrypt.so.11()(64bit) is
Dne 28.2.2014 20:51, Simo Sorce napsal(a):
> On Fri, 2014-02-28 at 19:37 +, Richard Hughes wrote:
>> On 28 February 2014 15:38, Tomas Mraz wrote:
>>> This should not break builds of any reasonably current software.
>> libgcrypt.so.11()(64bit) is needed by (installed)
>> google-chrome-stable-33
On Fri, 28 Feb 2014 20:29:12 +
Richard Hughes 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 e
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...
Richard
--
devel mailing list
devel@lists.fedorapro
On Fri, 2014-02-28 at 19:37 +, Richard Hughes wrote:
> On 28 February 2014 15:38, Tomas Mraz 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
On 28 February 2014 15:38, Tomas Mraz 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? :(
Richa
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
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 deprec
22 matches
Mail list logo