[gentoo-dev] rfc: glibc versions prior to 2.19-r1

[gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

All,

the following is a comment Mike made about the status of glibc in an
earlier thread on this list:

On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
> upstream glibc has dropped support for older Linux kernels.  your choices:
>  - upgrade your kernel
>  - switch to a different C library
>  - stick with glibc-2.19 for a while
> 
> be warned though there are no plans atm to backport things to glibc-2.19.  
> this includes security fixes, but more importantly as time moves on, making 
> newer gcc versions sanely compile glibc.  we've kept older glibc versions 
> around to be nice, and on a part time basis for cross-compiling, but none of 
> those are given priority.  i.e. fixes come as people feel like doing them.
> 
> certainly once glibc-2.20+ goes stable, there is no expectation let alone 
> requirement that packages in the tree be kept working with older glibc 
> versions.  the maintenance cost there is unreasonable.
> 
> i guess if you're stuck on old crap, now would be a good time to start 
> preparing to unstick your crap.  glibc-2.20 will most likely be in ~arch in 
> the next 6 months.
> -mike

Since glibc-2.19-r1 is stable everywhere, what I want to know is whether
we can remove versions *prior* to 2.19-r1 at this point.

If we do, that makes it easy to fix bug 478764 [1], because there would
only be three versions of glibc we have to worry about.

thoughts?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=478764

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/21/2014 03:28 PM, William Hubbs wrote:
> All,
> 
> the following is a comment Mike made about the status of glibc in
> an earlier thread on this list:
> 
> On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>> upstream glibc has dropped support for older Linux kernels.  your
>> choices: - upgrade your kernel - switch to a different C library 
>> - stick with glibc-2.19 for a while
>> 
>> be warned though there are no plans atm to backport things to
>> glibc-2.19. this includes security fixes, but more importantly as
>> time moves on, making newer gcc versions sanely compile glibc.
>> we've kept older glibc versions around to be nice, and on a part
>> time basis for cross-compiling, but none of those are given
>> priority.  i.e. fixes come as people feel like doing them.
>> 
>> certainly once glibc-2.20+ goes stable, there is no expectation
>> let alone requirement that packages in the tree be kept working
>> with older glibc versions.  the maintenance cost there is
>> unreasonable.
>> 
>> i guess if you're stuck on old crap, now would be a good time to
>> start preparing to unstick your crap.  glibc-2.20 will most
>> likely be in ~arch in the next 6 months. -mike
> 
> Since glibc-2.19-r1 is stable everywhere, what I want to know is
> whether we can remove versions *prior* to 2.19-r1 at this point.
> 
> If we do, that makes it easy to fix bug 478764 [1], because there
> would only be three versions of glibc we have to worry about.
> 
> thoughts?
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=478764
> 

I suppose it makes sense to drop old glibc ebuilds.

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUlx7ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZCJ4H/0coofEKcsika34IaHI609gR
Q2ZOhmcgV82wu6zwpIRVQaIDFCfo170c1g6OfffaaVLpu6VrvlN0lOxA0s2fPVuk
pyf3ZjmElVyhncPtfCBIlygfvdabEv5UCEi8dgOe59tz6SyXarvRdKdQOsWy8yRx
38LGDH/vcmlcTbVKXfKuNPZ52hhfTspw7/QDxIqwufDqXaFV/sP+nLRTWKlK293I
twO6biE3m60ggwaEyL5+LT4ZQZTQ2MnfDpBD8Rr1+xPwIj7rvgbJCVul1B1NZq6m
gxYS078K8SeSEroum4wrZKj6OI8oIAic7Apa9wpp+tDXPOMYYn7SxvNtOBVpa/w=
=rlNJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

21.12.2014 22:26, Markos Chandras пишет:
> On 12/21/2014 03:28 PM, William Hubbs wrote:
>> All,
> 
>> the following is a comment Mike made about the status of glibc in
>> an earlier thread on this list:
> 
>> On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>>> upstream glibc has dropped support for older Linux kernels.  your
>>> choices: - upgrade your kernel - switch to a different C library
>>> - stick with glibc-2.19 for a while
>>>
>>> be warned though there are no plans atm to backport things to
>>> glibc-2.19. this includes security fixes, but more importantly as
>>> time moves on, making newer gcc versions sanely compile glibc.
>>> we've kept older glibc versions around to be nice, and on a part
>>> time basis for cross-compiling, but none of those are given
>>> priority.  i.e. fixes come as people feel like doing them.
>>>
>>> certainly once glibc-2.20+ goes stable, there is no expectation
>>> let alone requirement that packages in the tree be kept working
>>> with older glibc versions.  the maintenance cost there is
>>> unreasonable.
>>>
>>> i guess if you're stuck on old crap, now would be a good time to
>>> start preparing to unstick your crap.  glibc-2.20 will most
>>> likely be in ~arch in the next 6 months. -mike
> 
>> Since glibc-2.19-r1 is stable everywhere, what I want to know is
>> whether we can remove versions *prior* to 2.19-r1 at this point.
> 
>> If we do, that makes it easy to fix bug 478764 [1], because there
>> would only be three versions of glibc we have to worry about.
> 
>> thoughts?
> 
>> William
> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=478764
> 
> 
> I suppose it makes sense to drop old glibc ebuilds.
> 
> 

+1 from me. They also have various security issues(all that are <2.17
are definitely have them)

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Lars Wendler]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On Sun, 21 Dec 2014 09:28:48 -0600 William Hubbs wrote:

>All,
>
>the following is a comment Mike made about the status of glibc in an
>earlier thread on this list:
>
>On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>> upstream glibc has dropped support for older Linux kernels.  your
>> choices:
>>  - upgrade your kernel
>>  - switch to a different C library
>>  - stick with glibc-2.19 for a while
>> 
>> be warned though there are no plans atm to backport things to
>> glibc-2.19. this includes security fixes, but more importantly as
>> time moves on, making newer gcc versions sanely compile glibc.
>> we've kept older glibc versions around to be nice, and on a part
>> time basis for cross-compiling, but none of those are given
>> priority.  i.e. fixes come as people feel like doing them.
>> 
>> certainly once glibc-2.20+ goes stable, there is no expectation let
>> alone requirement that packages in the tree be kept working with
>> older glibc versions.  the maintenance cost there is unreasonable.
>> 
>> i guess if you're stuck on old crap, now would be a good time to
>> start preparing to unstick your crap.  glibc-2.20 will most likely
>> be in ~arch in the next 6 months.
>> -mike
>
>Since glibc-2.19-r1 is stable everywhere, what I want to know is
>whether we can remove versions *prior* to 2.19-r1 at this point.
>
>If we do, that makes it easy to fix bug 478764 [1], because there would
>only be three versions of glibc we have to worry about.
>
>thoughts?
>
>William
>
>[1] https://bugs.gentoo.org/show_bug.cgi?id=478764

+1 from me. I cannot think of any scenario where we need to keep such
old glibc versions around.

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

IMHO, maintaining a sensible set of old glibc versions of the last 5
years makes sense, and we should try to support it:

> +1 from me. I cannot think of any scenario where we need to keep such
> old glibc versions around.

One scenario is to create a cross-compile toolchain with specific old
versions of gcc/binutils/glibc/linux-headers in mind.

Here, a common problem is that glibc is forward, but not backward
compatible. Thus, specific old versions of glibc are usually required.

Further, we also maintain a big history of gcc, binutils and
linux-headers versions. This would become a bit moot when we restrict
glibc to relatively modern versions.

At least it would limit the usefulness and flexibility of crossdev
drastically...


An alternative approach might be to drop keywords completely from old
versions that do not get any backports from our side any more.
With this, those would be still available for crossdev - but without any
functionality or security guarantee from our side.

As for the issue with functions.sh - I fail to see how this must be
resolved by dropping old versions...

Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 820 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
> IMHO, maintaining a sensible set of old glibc versions of the last 5
> years makes sense, and we should try to support it:

We have a general policy in the distro that says we only have to worry
about one year. Besides that, linux-2.6.32, which is the oldest kernel
glibc-2.20 will support was released in 2009, so I think it is
reasonable to drop the old glibc versions.

> 
> > +1 from me. I cannot think of any scenario where we need to keep such
> > old glibc versions around.
> 
> One scenario is to create a cross-compile toolchain with specific old
> versions of gcc/binutils/glibc/linux-headers in mind.
> 
> Here, a common problem is that glibc is forward, but not backward
> compatible. Thus, specific old versions of glibc are usually required.
>
> Further, we also maintain a big history of gcc, binutils and
> linux-headers versions. This would become a bit moot when we restrict
> glibc to relatively modern versions.

As has already been stated, older than glibc-2.20 will not be considered
supported once 2.20 hits stable, and 2.20 works with >=linux-2.6.32,
which was released in 2009.

Furthermore, I still think we need to look at how far back we are going
with gcc/binutils/linux-headers.

> 
> At least it would limit the usefulness and flexibility of crossdev
> drastically...
> 
> 
> An alternative approach might be to drop keywords completely from old
> versions that do not get any backports from our side any more.
> With this, those would be still available for crossdev - but without any
> functionality or security guarantee from our side.

An even better way to do this would be for someone to make an overlay
somewhere if they want this old stuff. I'm not saying that people
shouldn't be able to use it, but we shouldn't carry it in the main
portage tree. After all, we are not a software archival service.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Rich Freeman]

On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <williamh@gentoo.org> wrote:
> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>> years makes sense, and we should try to support it:
>
> We have a general policy in the distro that says we only have to worry
> about one year. Besides that, linux-2.6.32, which is the oldest kernel
> glibc-2.20 will support was released in 2009, so I think it is
> reasonable to drop the old glibc versions.
>

I think a general policy like this makes sense.  Nothing prevents a
maintainer from keeping around stuff longer, but that should be up to
them (and issues in old versions shouldn't be the responsibility of
others to clean up if they are blockers - just move forward and let
things break after a warning or treeclean if the problem is really
serious).

Manpower is limited in Gentoo in general, and there is little point in
pouring a lot of it into one particular package unless you pour just
as much effort into other related packages.  By having a guideline of
one year it gives everybody something to aim for - we keep around
year-old kernels that work with year-old gcc and glibc and year-old
sysvinit implementations, and so on.  It also lets our users have a
sense up-front of what to expect - they /might/ happen to get a bit
more out of the odd package, but we're not RHEL.

If somebody wants to run a "Gentoo Ancient" overlay or such, more power to them!

--
Rich

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/22/14 10:39, Rich Freeman wrote:
> On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <williamh@gentoo.org> wrote:
>> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>>> years makes sense, and we should try to support it:
>> We have a general policy in the distro that says we only have to worry
>> about one year. Besides that, linux-2.6.32, which is the oldest kernel
>> glibc-2.20 will support was released in 2009, so I think it is
>> reasonable to drop the old glibc versions.
>>
> I think a general policy like this makes sense.  Nothing prevents a
> maintainer from keeping around stuff longer, but that should be up to
> them (and issues in old versions shouldn't be the responsibility of
> others to clean up if they are blockers - just move forward and let
> things break after a warning or treeclean if the problem is really
> serious).

Please let's not "tidy up" gentoo.  That "old" stuff is useful even if 
its not useful to those who don't see a use for it.  Let the maintainers 
decide if they want to put effort into keeping it around.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1402 bytes --]

Am Montag, 22. Dezember 2014, 16:52:22 schrieb Anthony G. Basile:
> 
> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if
> its not useful to those who don't see a use for it.  Let the maintainers
> decide if they want to put effort into keeping it around.

Well the side effect of this is that arcane and unmaintainable bandworms like 
toolchain.eclass are generated, with dozens of case distinctions for packages 
that *nearly* noone needs. Yes it's fine to keep old things for a few people, 
does it merit slowing everyone else down though?

Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3, 
2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3, 
2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?

(On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2, 
4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4, 
4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4, 
4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2? 

I mean, it's not as if these were the exact same packages as when originally 
stabilized, in an archiving sense, since in the meantime random eclass 
settings were flipped around.)

+1 for an "archive overlay"

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
[...]
> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2, 
> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4, 
> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4, 
> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2? 

Yes, we do. There is a lot of software out there which needs
specific gcc version. E.g. I have fortran code which depends
gcc:3.4. Other example are cuda implementations which usually lag
behind mainstream gcc by one middle version.

And please don't say "just fix it", some of such software is
binary, some other is too large to be updated regularly.

While one year support is a good policy for a common packages, it
is in no way an upper limit for support and core packages should be
considered carefully here.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/22/14 11:20, Andrew Savchenko wrote:
> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
>> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
>> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
>> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
>> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.

Its not as corner as people think it is.  I wasn't even thinking of cuda.

>
> And please don't say "just fix it", some of such software is
> binary, some other is too large to be updated regularly.
>
> While one year support is a good policy for a common packages, it
> is in no way an upper limit for support and core packages should be
> considered carefully here.

Thank you.

>
> Best regards,
> Andrew Savchenko


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Rich Freeman]

On Mon, Dec 22, 2014 at 11:20 AM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
>> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
>> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
>> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
>> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?
>
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.
>
> And please don't say "just fix it", some of such software is
> binary, some other is too large to be updated regularly.
>

You don't have to fix that software.  You just have to sign up to
co-maintain gcc so that you can take care of all those old versions
you want to keep and ensure that they don't break when there are
changes to other packages.  I just proposed that it should be up to
the maintainer, which can be you.

I could care less if gcc has 300 versions in the tree - I'd say 300 is
better than 5.  I just don't expect that other package maintainers
deal with bugs like "can't stabilize foo-6 because it will make
systems running a 4-year-old version of gcc unbootable."  If an
upcoming change makes gcc-2.95 systems unbootable they can just log a
bug and a news item assuming somebody notices it before it gets
committed (maybe giving the gcc maintainer a week to fix it before
plowing ahead), and if nobody notices it before it goes stable no big
deal.  If you're running such oddball configurations on Gentoo that is
what we're all about, but you should be thoroughly testing changes
before deploying them in production because certainly nobody else is
going to do it for you...

--
Rich

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1679 bytes --]

Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
> 
> > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > breath) 4.9.2?
> 
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.

Which gives us 3.4, 4.6, 4.7, 4.8, 4.9 at most.

> And please don't say "just fix it", 

I'm not saying "just fix it", I'm saying "... and of course you will happily 
join toolchain team and/or maintain the single gcc version that you need, at 
your own pace". 

> some of such software is
> binary, some other is too large to be updated regularly.

Please give REASONS why things should remain maintained. So far (except for 
the gcc-3/hardened explanations, and for gcc-3 doing more fortran than 
gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it", 
proprietary binary blobs (should we even care? if yes, why?) and similar. 

I'm VERY happy to hear arguments. Especially if they come with good practical 
and detailed examples that we all can understand. I guess we're all curious to 
learn about more Gentoo use cases.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Rich Freeman]

On Mon, Dec 22, 2014 at 4:22 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
>
>> And please don't say "just fix it",
>
> I'm not saying "just fix it", I'm saying "... and of course you will happily
> join toolchain team and/or maintain the single gcc version that you need, at
> your own pace".
>

This really is the basic principle that tends to govern most of these
things.  This isn't about getting rid of stuff that people want to
take care of.  This is about not forcing devs to take care of software
that they have no desire to take care of.  Nobody is preventing
anybody from maintaining old versions of gcc/glibc/linux/etc.  I'm
sure everybody would be happy to work with anybody who is active and
doing such things.  The problem comes in when people want to hold up
stabilization of other packages or changes to eclasses/profiles/etc on
the grounds that some ancient version of glibc that nobody is actually
bothering to maintain will be broken by the change.

If you don't have a policy like this, then people just give up on
doing new things with Gentoo, and then all that you have left are
people who want the old things but can't be bothered to keep them
working.  The goal here is to keep the effort required to take Gentoo
in a new direction low.  That is how we end up with things like
Prefix, multilib (in its various forms), multiple init
implementations, and so on.

As long as somebody makes sure that the old versions of glibc will
continue to boot when their dependencies are satisfied, then nobody is
going to force anybody to remove them.  The onus is just on those who
want to keep those packages to ensure that they are maintained.

--
Rich

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

On Mon, 22 Dec 2014 22:22:41 +0100 Andreas K. Huettel wrote:
> Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
> > On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> > [...]
> > 
> > > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > > breath) 4.9.2?
> > 
> > Yes, we do. There is a lot of software out there which needs
> > specific gcc version. E.g. I have fortran code which depends
> > gcc:3.4. Other example are cuda implementations which usually lag
> > behind mainstream gcc by one middle version.
> 
> Which gives us 3.4, 4.6, 4.7, 4.8, 4.9 at most.

That was just two examples from my experience. Other users may
have different demands. That's why I'm not sure it is safe to
remove 2.95. Also people may need older versions for testing (e.g.
to check for possible regressions).

As far as I understand right now older gcc versions are not a large
maintenance hassle, so to be on a safe side we should keep the
latest version on each branch. That is exactly what is done right
now: prior to (4.5) we have only latest ebuild per branch.

> > And please don't say "just fix it", 
> 
> I'm not saying "just fix it", I'm saying "... and of course you will happily 
> join toolchain team and/or maintain the single gcc version that you need, at 
> your own pace". 

Frankly I had thoughts about joining toolchain, but probably I'm
too green as a Gentoo dev to do this right now.

> > some of such software is
> > binary, some other is too large to be updated regularly.
> 
> Please give REASONS why things should remain maintained. So far (except for 
> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than 
> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it", 
> proprietary binary blobs (should we even care? if yes, why?) and similar. 
> 
> I'm VERY happy to hear arguments. Especially if they come with good practical 
> and detailed examples that we all can understand. I guess we're all curious to 
> learn about more Gentoo use cases.

I can't justify for you each gcc version in the list, but I already
described use cases I encountered. The main point is that most
users don't read this list and it is highly likely that people need
another gcc versions for similar reasons but for a different
software.

As far as I understand from this discussion, a main issue is that
proposed changes in toolchain.eclass will broke old ebuilds.
Solution looks very simple to me: just use toolchain-v2.eclass for
new stuff.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

All,

this discussion got side-tracked into gcc, which was not my intent;
let's go back to my specific question about glibc.

On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote:
> > some of such software is
> > binary, some other is too large to be updated regularly.
> 
> Please give REASONS why things should remain maintained. So far (except for 
> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than 
> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it", 
> proprietary binary blobs (should we even care? if yes, why?) and similar. 
 
 I vote that we shouldn't care about proprietary binary blobs.

> I'm VERY happy to hear arguments. Especially if they come with good practical 
> and detailed examples that we all can understand. I guess we're all curious to 
> learn about more Gentoo use cases.

With regard to keeping old glibc versions, as far as I
can tell, there are no dependencies in the tree that require a specific
version of glibc.

Also, the oldest kernel I see is far newer than 2.6.32, which is the
oldest kernel being maintained upstream.

Because of that, i see no reason to keep the older versions of glibc
around. This would also give us a chance to clean up the ebuilds without
causing massive breakage. the eblits need to die.

Crossdev was mentioned in discussions on irc, but again it wasn't clear
to me why specific versions of glibc are needed. I don't know of any
hard dependencies in the portage tree like that.

If someone can point to a concrete example of why we should keep
the older versions of glibc, I would like to hear it.


Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

I'm a bit surprised about this discussion as Mike, who currently
maintains the toolchain, has never implied that suddenly older versions
of glibc are unusable. Or that we need a big cleanup.

He simply stated two facts (that have been true for a long time)

 - for a current kernel a current toolchain is necessary and vice versa.

 - we support older versions of glibc (gcc/etc.) mainly for crossdev
   (and some other special purposes) on a best effort basis without any
   usability or security guarantees.

The latter implies that you should not actively use them in your regular
Gentoo setup, not that they must be removed from the tree.

> [...]
>
> Crossdev was mentioned in discussions on irc, but again it wasn't clear
> to me why specific versions of glibc are needed. I don't know of any
> hard dependencies in the portage tree like that.

Again,

just the simple fact that crossdev without the ability to select
specific versions of glibc is only half as useful. And please, do not
underestimate the usefulness of our crossdev script in this regard!

Because you're arguing that no example was presented:
E.g. I've an embedded armv7a-hardfloat board which ships with glibc
2.16 (This is a concrete example and not a vague "some users might need
it".). I want to have a cross compile environment for it to compile some
specific software (not a complete userland). I do not want to replace
the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm
basically forced to compile with a glibc of at most 2.16 (otherwise you
get symbol lookup errors.)


To ease the maintenance burden there are multiple possibilities to
tackle it without removing old glibc versions altogether:

  - We could debundle newer glibc versions from toolchain.eclass/eblits

  - We could migrate older versions in a dedicated overlay with some
    sort of versioned toolchain.eclass/eblits. (same for the other
    canonical packages).

Further, if the fact that specific versions are unmaintained (and do not
get any security backports) it is also possible to just drop keywords.


Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 820 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Tue, Dec 23, 2014 at 09:10:32AM +0100, Matthias Maier wrote:
> I'm a bit surprised about this discussion as Mike, who currently
> maintains the toolchain, has never implied that suddenly older versions
> of glibc are unusable. Or that we need a big cleanup.
> 
> He simply stated two facts (that have been true for a long time)
> 
>  - for a current kernel a current toolchain is necessary and vice versa.
> 
>  - we support older versions of glibc (gcc/etc.) mainly for crossdev
>    (and some other special purposes) on a best effort basis without any
>    usability or security guarantees.
> 
> The latter implies that you should not actively use them in your regular
> Gentoo setup, not that they must be removed from the tree.
 
 I cc'd Mike on my original message in this thread specifically because I
 hoped he would see it and tell me if I was wrong to start discussing a
 cleanup, because I read part of his message as implying that a cleanup might be
 coming.

Specifically, he also said that if you were stuck on old stuff you
should start unsticking your stuff.

> just the simple fact that crossdev without the ability to select
> specific versions of glibc is only half as useful. And please, do not
> underestimate the usefulness of our crossdev script in this regard!
 
 I'm not saying anything about breaking the crossdev script by making it
 unable to select specific versions of glibc.

> Because you're arguing that no example was presented:
> E.g. I've an embedded armv7a-hardfloat board which ships with glibc
> 2.16 (This is a concrete example and not a vague "some users might need
> it".). I want to have a cross compile environment for it to compile some
> specific software (not a complete userland). I do not want to replace
> the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm
> basically forced to compile with a glibc of at most 2.16 (otherwise you
> get symbol lookup errors.)
 
 Ok, this is something to consider then. 2.16 is not all that old, so
 keeping it around for a while longer isn't a big deal.

> To ease the maintenance burden there are multiple possibilities to
> tackle it without removing old glibc versions altogether:
> 
>   - We could debundle newer glibc versions from toolchain.eclass/eblits

I don't see toolchain.eclass being inherited in the glibc ebuilds; it is
just eblits. Honestly I wouldn't have a problem with seeing them die in
all versions of the ebuilds if we can make that happen.

>   - We could migrate older versions in a dedicated overlay with some
>     sort of versioned toolchain.eclass/eblits. (same for the other
>     canonical packages).

It looks like there already is a toolchain overlay that might have this,
check git.overlays.gentoo.org.

> 
> Further, if the fact that specific versions are unmaintained (and do not
> get any security backports) it is also possible to just drop keywords.
 
 (qa hat on for this statement only) as a qa member, my opinion on this
 is, if something has a serious security issue which the maintainer
 knows is not going to be fixed, it doesn't belong in the main tree.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]


Am 23. Dec 2014, 16:51 schrieb William Hubbs <williamh@gentoo.org>:

>> just the simple fact that crossdev without the ability to select
>> specific versions of glibc is only half as useful. And please, do not
>> underestimate the usefulness of our crossdev script in this regard!
>  
>  I'm not saying anything about breaking the crossdev script by making it
>  unable to select specific versions of glibc.

Then, we have to provide the ebuilds for those versions somehow.


>  Ok, this is something to consider then. 2.16 is not all that old, so
>  keeping it around for a while longer isn't a big deal.

Same goes for any other arbitrary version in the course of the last 4
years :-)


>>   - We could migrate older versions in a dedicated overlay with some
>>     sort of versioned toolchain.eclass/eblits. (same for the other
>>     canonical packages).
>
> It looks like there already is a toolchain overlay that might have this,
> check git.overlays.gentoo.org.

I had a closer look at it and it turns out it is Mike's development
and 'ebuild retirement' overlay.

He already maintains some older versions in this overlay.

So, in conclusion, why not just asking him to just move older glibc
versions back to the toolchain overlay as soon as they become
unmaintained (i.e. without security backports)?

Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 820 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Rich Freeman]

On Mon, Dec 22, 2014 at 11:55 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> Because of that, i see no reason to keep the older versions of glibc
> around. This would also give us a chance to clean up the ebuilds without
> causing massive breakage. the eblits need to die.
>

Who is actually maintaining glibc, and what ebuilds do THEY want to
keep around?  I'm not sure why this needs a big community decision
around cleaning them out.

They can keep around 10-year-old versions of glibc as far as I'm
concerned, as long as they promptly address bugs that are blockers for
other packages.  If they don't, then I'm all for unblocking those
other packages (ie the maintainers of the other packages can ignore
old glibc bugs and proceed to break systems that use those versions).
So, nobody is forcing the glibc maintainers to do anything, but
neither are the glibc maintainers forcing anybody else to do anything
to support stuff more than a year old.

--
Rich

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/22/14 23:55, William Hubbs wrote:
> All,
>
> this discussion got side-tracked into gcc, which was not my intent;
> let's go back to my specific question about glibc.
>
> On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote:
>>> some of such software is
>>> binary, some other is too large to be updated regularly.
>> Please give REASONS why things should remain maintained. So far (except for
>> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than
>> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it",
>> proprietary binary blobs (should we even care? if yes, why?) and similar.
>   
>   I vote that we shouldn't care about proprietary binary blobs.

Oh dear god this is going from bad to worse.  I love blobs as much as 
the next person but there are people that need this stuff if gentoo is 
to be useful for them.  Let's not care about blobs and shut down 
linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II 
which need blobs.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote:
> On 12/22/14 23:55, William Hubbs wrote:
> > All,
> >
> > this discussion got side-tracked into gcc, which was not my intent;
> > let's go back to my specific question about glibc.
> >
> > On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote:
> >>> some of such software is
> >>> binary, some other is too large to be updated regularly.
> >> Please give REASONS why things should remain maintained. So far (except for
> >> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than
> >> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it",
> >> proprietary binary blobs (should we even care? if yes, why?) and similar.
> >   
> >   I vote that we shouldn't care about proprietary binary blobs.
> 
> Oh dear god this is going from bad to worse.  I love blobs as much as 
> the next person but there are people that need this stuff if gentoo is 
> to be useful for them.  Let's not care about blobs and shut down 
> linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II 
> which need blobs.

I have never heard him say that keeping old software in the tree is
necessary for the blobs he uses. If that is the case, that is something
that must be considered. I was just echoing the current policy about
blobs; they are not a reason to block stabilization of other
packages etc.

William



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/23/14 09:39, William Hubbs wrote:
> On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote:
>> On 12/22/14 23:55, William Hubbs wrote:
>>> All,
>>>
>>> this discussion got side-tracked into gcc, which was not my intent;
>>> let's go back to my specific question about glibc.
>>>
>>> On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote:
>>>>> some of such software is
>>>>> binary, some other is too large to be updated regularly.
>>>> Please give REASONS why things should remain maintained. So far (except for
>>>> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than
>>>> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it",
>>>> proprietary binary blobs (should we even care? if yes, why?) and similar.
>>>    
>>>    I vote that we shouldn't care about proprietary binary blobs.
>> Oh dear god this is going from bad to worse.  I love blobs as much as
>> the next person but there are people that need this stuff if gentoo is
>> to be useful for them.  Let's not care about blobs and shut down
>> linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II
>> which need blobs.
> I have never heard him say that keeping old software in the tree is
> necessary for the blobs he uses. If that is the case, that is something
> that must be considered. I was just echoing the current policy about
> blobs; they are not a reason to block stabilization of other
> packages etc.
>
> William
>
>

That's not what you said.  I was responding to "I vote that we shouldn't 
care about proprietary binary blobs" not to "I have never heard him say 
that keeping old software in the tree ..."

I test for him on his equipment and there you must care about 
proprietary blobs.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

On Tue, Dec 23, 2014 at 09:46:28AM -0500, Anthony G. Basile wrote:
> On 12/23/14 09:39, William Hubbs wrote:
> > On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote:
> >> On 12/22/14 23:55, William Hubbs wrote:
> >>> All,
> >>>
> >>> this discussion got side-tracked into gcc, which was not my intent;
> >>> let's go back to my specific question about glibc.
> >>>
> >>> On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote:
> >>>>> some of such software is
> >>>>> binary, some other is too large to be updated regularly.
> >>>> Please give REASONS why things should remain maintained. So far (except for
> >>>> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than
> >>>> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it",
> >>>> proprietary binary blobs (should we even care? if yes, why?) and similar.
> >>>    
> >>>    I vote that we shouldn't care about proprietary binary blobs.
> >> Oh dear god this is going from bad to worse.  I love blobs as much as
> >> the next person but there are people that need this stuff if gentoo is
> >> to be useful for them.  Let's not care about blobs and shut down
> >> linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II
> >> which need blobs.
> > I have never heard him say that keeping old software in the tree is
> > necessary for the blobs he uses. If that is the case, that is something
> > that must be considered. I was just echoing the current policy about
> > blobs; they are not a reason to block stabilization of other
> > packages etc.
> >
> > William
> >
> >
> 
> That's not what you said.  I was responding to "I vote that we shouldn't 
> care about proprietary binary blobs" not to "I have never heard him say 
> that keeping old software in the tree ..."
> 
> I test for him on his equipment and there you must care about 
> proprietary blobs.

Sure, but I was just saying that Gentoo policy doesn't currently care
about proprietary blobs.

Specifically, I don't think a proprietary blob or the breakage of one
can be used as a reason to block stabilization of a new version of a
package or removal of an old version of the package wrt the main tree.

That's my understanding of our policy; however, as usual, I am open to
being corrected.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]


> +1 for an "archive overlay"

This sounds like a reasonable compromise.

For the toolchain.eclass problem you mentioned. We could just version
the eclass as needed, something like toolchain-crossdev-vX.eclass. With
this development on the main repository is independent and we would
still have old versions around for crossdev.

Same goes for gcc, and binutils.

Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 820 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/22/14 11:11, Andreas K. Huettel wrote:
> Am Montag, 22. Dezember 2014, 16:52:22 schrieb Anthony G. Basile:
>> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if
>> its not useful to those who don't see a use for it.  Let the maintainers
>> decide if they want to put effort into keeping it around.
> Well the side effect of this is that arcane and unmaintainable bandworms like
> toolchain.eclass are generated, with dozens of case distinctions for packages
> that *nearly* noone needs. Yes it's fine to keep old things for a few people,
> does it merit slowing everyone else down though?
>
> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?

I can't fully speak to this as I'm not familiar.  But are you?

>
> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?

Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown 
number of regressions.  Most people that hit these kinds of problems 
revert to the previous working versions.  Add to that the quantum leaps 
between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact 
that some sensitive software usually aimed a special chips need specific 
versions and the answer is ... yes.

What happened here (in part) is the way we're doing multilib is 
percolating through gentoo and hitting things it doesn't mesh with 
well.  That's fine we have to glue things together correctly. Throwing 
stuff away when it doesn't mesh is not fine when its something good.

>
> I mean, it's not as if these were the exact same packages as when originally
> stabilized, in an archiving sense, since in the meantime random eclass
> settings were flipped around.)
>
> +1 for an "archive overlay"
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 2439 bytes --]

Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile:

> > Well the side effect of this is that arcane and unmaintainable bandworms
> > like toolchain.eclass are generated, with dozens of case distinctions
> > for packages that *nearly* noone needs. Yes it's fine to keep old things
> > for a few people, does it merit slowing everyone else down though?
> > 
> > Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
> > 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
> > 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
> 
> I can't fully speak to this as I'm not familiar.  But are you?

No, I'm not. Which is why I am asking. I'm happy to learn.

> > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > breath) 4.9.2?
> 
> Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown
> number of regressions.  Most people that hit these kinds of problems
> revert to the previous working versions.  

OK, so then let's keep all 4.7.x, 4.8.x, 4.9.x, the latest stable 4.5 and 4.6, 
and maybe 3.4.

> Add to that the quantum leaps
> between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact
> that some sensitive software usually aimed a special chips need specific
> versions and the answer is ... yes.

One of the many moments when I really wish we had gentoostats up and running. 

Is it possible to emerge @system with, say, e.g. gcc-4.0 or 4.1? 

From the discussions about hardened 3.x is still interesting. But how much can 
you still do with it, does anyone try regularly?

Is anyone even testing 2.95 anymore? 

> What happened here (in part) is the way we're doing multilib is
> percolating through gentoo and hitting things it doesn't mesh with
> well.  That's fine we have to glue things together correctly. Throwing
> stuff away when it doesn't mesh is not fine when its something good.

Please explain the specific connection of this problem with multilib. 
(Shouldn't you usually use the same gcc version for your whole system as far 
as you can?)

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/22/14 16:37, Andreas K. Huettel wrote:
> Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile:
>
>>> Well the side effect of this is that arcane and unmaintainable bandworms
>>> like toolchain.eclass are generated, with dozens of case distinctions
>>> for packages that *nearly* noone needs. Yes it's fine to keep old things
>>> for a few people, does it merit slowing everyone else down though?
>>>
>>> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
>>> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
>>> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
>> I can't fully speak to this as I'm not familiar.  But are you?
> No, I'm not. Which is why I am asking. I'm happy to learn.

Shall I google that for you? j/k   Here are the change logs -> 
http://www.gnu.org/software/libc/  There are always some big ticket 
items like I remember when -lrt stuff was moved into glibc or further 
back when resolver stuff was moved out.  Each of these changes usually 
means breakage usually in terms of what breakout libraries you need and 
what linker flags you need.  But I can't pretend to have watched it 
closely like I'm sure Mike does.  I've watched musl and uclibc and just 
hit up against the glibc changes as they mysteriously rain down from 
Drepper.

>>> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
>>> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
>>> 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
>>> 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
>>> breath) 4.9.2?
>> Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown
>> number of regressions.  Most people that hit these kinds of problems
>> revert to the previous working versions.
> OK, so then let's keep all 4.7.x, 4.8.x, 4.9.x, the latest stable 4.5 and 4.6,
> and maybe 3.4.

And how would someone running 4.9 get to 3.4?  I tested on amd64 and I 
can compile any version of gcc in the tree with 4.8, except 2.95 which I 
can't compile with *any* version.  But that's on *amd64*  I did not test 
on the other arches.  It would be bad if we did this and then 3.4 is not 
buildable from4.8 but is from some intermediate version which we 
dumped.  The general testing rule for compiling gcc with gcc is two 
versions back/forwards --- Ryan can correct me if he was doing something 
different, but thats' what I've done for ages. So you really need to 
keep that chain 4.8 -> 4.7 -> 4.6 ... -> 3.3 going.

>
>> Add to that the quantum leaps
>> between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact
>> that some sensitive software usually aimed a special chips need specific
>> versions and the answer is ... yes.
> One of the many moments when I really wish we had gentoostats up and running.

Why not let the maintainer decide what he/she will maintain?  State 
exactly is broken with toolchain that needs fixing and let's fix it.  
But fixing it because its aesthetically unpleasing isn't good 
engineering.  Like the "messy drawer" in the kitchen.  Every other 
drawer is nice and tidy and you marvel at its organizational beauty.  So 
you stuff all the ugly complexity in this one drawer. No matter how much 
you try to organize that drawer, its stays messy.  And here's the 
thing.  Its useful that way.  You can't get your brain around all the 
mess and so you obsess about "cleaning it up" but if you give into the 
temptation, the next time you need that square ladle you dumped because 
it was ugly you'll regret it.

>
> Is it possible to emerge @system with, say, e.g. gcc-4.0 or 4.1?
>
>  From the discussions about hardened 3.x is still interesting. But how much can
> you still do with it, does anyone try regularly?
>
> Is anyone even testing 2.95 anymore?
>
>> What happened here (in part) is the way we're doing multilib is
>> percolating through gentoo and hitting things it doesn't mesh with
>> well.  That's fine we have to glue things together correctly. Throwing
>> stuff away when it doesn't mesh is not fine when its something good.
> Please explain the specific connection of this problem with multilib.
> (Shouldn't you usually use the same gcc version for your whole system as far
> as you can?)
>

Better yet, look at mgorny's ebuild approach to gcc-4.9 and you'll see 
the inclusion of multilib.  We want that for things like 64-bit address 
space in gcc for mips -> https://bugs.gentoo.org/show_bug.cgi?id=477956 
"Build sys-devel/gcc as an N64 binary on MIPS profiles with non-N64 
default ABI"

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Re: rfc: glibc versions prior to 2.19-r1

[Duncan]

Anthony G. Basile posted on Tue, 23 Dec 2014 08:36:44 -0500 as excerpted:

> I've watched musl and uclibc and just hit up against the glibc changes
> as they mysteriously rain down from Drepper.

Just a quick reply to this side point...

There's no indication in your post that you're aware that Drepper is out 
of the glibc picture, now.  He is, and has been for... I think at least a 
year, now.  You could of course google it if you're interested in the 
details, but he has definitely moved on to other things, now, and is no 
longer glibc "controlling god", or even, AFAIK, still involved in glibc 
at all.

(I've seen no need to get involved in the general thread...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/23/14 21:39, Duncan wrote:
> Anthony G. Basile posted on Tue, 23 Dec 2014 08:36:44 -0500 as excerpted:
>
>> I've watched musl and uclibc and just hit up against the glibc changes
>> as they mysteriously rain down from Drepper.
> Just a quick reply to this side point...
>
> There's no indication in your post that you're aware that Drepper is out
> of the glibc picture, now.

Actually klondike did tell me that a while back, but I forgot when I posted.

>    He is, and has been for... I think at least a
> year, now.  You could of course google it if you're interested in the
> details, but he has definitely moved on to other things, now, and is no
> longer glibc "controlling god", or even, AFAIK, still involved in glibc
> at all.
>
> (I've seen no need to get involved in the general thread...)
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Matt Turner]

On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 12/22/14 16:37, Andreas K. Huettel wrote:
>>
>> Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile:
>>
>>>> Well the side effect of this is that arcane and unmaintainable bandworms
>>>> like toolchain.eclass are generated, with dozens of case distinctions
>>>> for packages that *nearly* noone needs. Yes it's fine to keep old things
>>>> for a few people, does it merit slowing everyone else down though?
>>>>
>>>> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
>>>> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
>>>> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
>>>
>>> I can't fully speak to this as I'm not familiar.  But are you?
>>
>> No, I'm not. Which is why I am asking. I'm happy to learn.
>
>
> Shall I google that for you? j/k   Here are the change logs ->
> http://www.gnu.org/software/libc/  There are always some big ticket items
> like I remember when -lrt stuff was moved into glibc or further back when
> resolver stuff was moved out.  Each of these changes usually means breakage
> usually in terms of what breakout libraries you need and what linker flags
> you need.  But I can't pretend to have watched it closely like I'm sure Mike
> does.  I've watched musl and uclibc and just hit up against the glibc
> changes as they mysteriously rain down from Drepper.

Sorry, what would he be Googling? He asked why we needed all of the
various old versions, not why new versions keep coming out.

Also, Drepper hasn't been involved with glibc development in two and a
half years.

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

On 12/23/14 21:40, Matt Turner wrote:
> On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> On 12/22/14 16:37, Andreas K. Huettel wrote:
>>> Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile:
>>>
>>>>> Well the side effect of this is that arcane and unmaintainable bandworms
>>>>> like toolchain.eclass are generated, with dozens of case distinctions
>>>>> for packages that *nearly* noone needs. Yes it's fine to keep old things
>>>>> for a few people, does it merit slowing everyone else down though?
>>>>>
>>>>> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
>>>>> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
>>>>> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
>>>> I can't fully speak to this as I'm not familiar.  But are you?
>>> No, I'm not. Which is why I am asking. I'm happy to learn.
>>
>> Shall I google that for you? j/k   Here are the change logs ->
>> http://www.gnu.org/software/libc/  There are always some big ticket items
>> like I remember when -lrt stuff was moved into glibc or further back when
>> resolver stuff was moved out.  Each of these changes usually means breakage
>> usually in terms of what breakout libraries you need and what linker flags
>> you need.  But I can't pretend to have watched it closely like I'm sure Mike
>> does.  I've watched musl and uclibc and just hit up against the glibc
>> changes as they mysteriously rain down from Drepper.
> Sorry, what would he be Googling? He asked why we needed all of the
> various old versions, not why new versions keep coming out.

I can't say because I haven't followed glibc.  I just point to the 
changelogs since they do indicate big changes between versions. These 
changes are big enough that users might legitimately have to or want to 
stay back.  This suggests that keeping more older versions than usual is 
prudent.  Probably back at least to 2.13 but Mike would have to answer.

We also have large number of ebuilds for uclibc and a similar situation, 
and I appreciate the conservative approach there especially when 
testing/building stages on various arches.

>
> Also, Drepper hasn't been involved with glibc development in two and a
> half years.
>

Yeah klondike told me that long ago but I forgot.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1413 bytes --]

Am Dienstag, 23. Dezember 2014, 14:36:44 schrieb Anthony G. Basile:
> >>> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
> >>> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
> >>> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
> >> 
> >> I can't fully speak to this as I'm not familiar.  But are you?
> > 
> > No, I'm not. Which is why I am asking. I'm happy to learn.
> 
> Shall I google that for you? j/k   Here are the change logs ->
> http://www.gnu.org/software/libc/  There are always some big ticket
> items ...

Hehe, yeah I dont doubt that a lot is changing. :) And probably more will 
come. I'm more concerned about the active maintaining / testing with current 
software of the old versions, but then since I'm not the one maintaining 
them...

> And how would someone running 4.9 get to 3.4? 
[...]
> The general testing rule for compiling gcc with gcc is two
> versions back/forwards --- Ryan can correct me if he was doing something
> different, but thats' what I've done for ages. So you really need to
> keep that chain 4.8 -> 4.7 -> 4.6 ... -> 3.3 going.

True, that's a valid point for keeping a "stepladder" of old gcc versions down 
to the earliest version that you want to keep.

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Ben de Groot]

On 23 December 2014 at 00:11, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> +1 for an "archive overlay"

I set up the graveyard overlay for such purposes, a couple of years ago.
But it hasn't taken off: https://github.com/gentoo/graveyard

Feel free to resurrect it. (pun intended)

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Rich Freeman]

On Mon, Dec 22, 2014 at 10:52 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 12/22/14 10:39, Rich Freeman wrote:
>>
>> On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <williamh@gentoo.org>
>> wrote:
>>>
>>> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>>>>
>>>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>>>> years makes sense, and we should try to support it:
>>>
>>> We have a general policy in the distro that says we only have to worry
>>> about one year. Besides that, linux-2.6.32, which is the oldest kernel
>>> glibc-2.20 will support was released in 2009, so I think it is
>>> reasonable to drop the old glibc versions.
>>>
>> I think a general policy like this makes sense.  Nothing prevents a
>> maintainer from keeping around stuff longer, but that should be up to
>> them (and issues in old versions shouldn't be the responsibility of
>> others to clean up if they are blockers - just move forward and let
>> things break after a warning or treeclean if the problem is really
>> serious).
>
>
> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if its
> not useful to those who don't see a use for it.  Let the maintainers decide
> if they want to put effort into keeping it around.
>

Wasn't that what I just said?  Maintainers decide what they want to
put effort into maintaining.  The only bit I added beyond what you
said is that if they DON'T maintain the old versions others don't have
to do it for them.  (ie, bugs against them don't count as blockers
towards other changes in the tree)  Treecleaning is only appropriate
if things are horribly broken, which is the usual policy.

--
Rich