Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Samstag, 3. März 2018, 15:39:50 CET schrieb Michał Górny:
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case, it does not mean
> that other members of toolchain or any other team will not end up having
> to remember extra rules like 'do not remove this ebuild because X wants
> it'.

We need to do that anyway, if only as a service to more technically oriented 
users. I think we should keep in mind that the corresponding audiences are 
where we draw our power users and potential developers. 

This idea for sure applies to toolchain packages and parts of base system.
Keeping track of old software we want to keep via, say, a wiki page is the 
easiest part.

As an example, I restored a specific old auto* version because it is required 
for gcc *development* (not usage). 

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Andreas,

"Andreas K. Huettel"  writes:

> Well, in principle the idea is OK. We already/still keep some old
> glibc, gcc, and binutils versions for that reason.
>
> However, I have a few conditions.
>
> * Only masked. Only prefix keywords.

Not problem for masking.  For keywords, prefix-standalone uses usual
keywords, not prefix keywords.

  
https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#Search_pathes

> If you really must unmask them in a specific prefix profile, you must
> provide big fat warnings about the resulting security risks.  (I dont
> know how things went in prehistoric times, but recently there have
> been a LOT of glibc-related CVEs. Many fixes can be backported, but
> definitely not all of them.)

Yes, I think that's the way to go to keep users reminded of security
risks involved.

> * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
> rules apply.

Agreed!  Old glibc becomes a burden for toolchain-glibc.eclass
maintenance.  We'd better make them standalone.

> * Try to stick to a minimum of required features (and a minimum of required 
> versions).
> We want to strongly avoid adding conditionals to other packages. [#]

Sure, the feature set will be kept bare minimal.  For example, handened
patches will be removed.

> * Please use our gentoo glibc repo to keep track of branches and patchsets.
> Happy to show you the details sometime soon.

Thanks Andreas.  Much appreciated.

> [#] If not for such "old version" considerations, we could soon move the 
> libtirpc headers to the place where the glibc headers used to live. That 
> could 
> save us a ...load of patching and bugfixing. By keeping flexibility and 
> compatibility, that is unfortunately not possible.

That's where I see providing glibc-2.16 and 2.19 in special profiles
might shed light on this delimma.  We keep versions of glibc to make
sure some old systems do not break.  But those systems are not clearly
defined.  We don't have a guideline for when and how to remove them.
(We used to keep them almost indefinitely before the reformation of
toolchain project.)

By explicitly spelling out the range of kernels a specific glibc
supports, and only keeping the minimal set of old versions, the
boundaries are defined.

Cheers,
Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Michał,

Michał Górny  writes:

>> I am on the toolchain alias, and I am interested in joining the project.
>> I will be responsible to deal with all the bugs for glibc-2.16 and
>> glibc-2.19.  Bug wranglers' work load does not change.
>> 
>> Yes, I apologize this will generate some noise for toolchain@g.o.  But I
>> anticipate people on the team are interested in receiving those emails.
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case,

What I ask is a special treatment of glibc.  I do not intend to explore
a generic solution in this thread.  And don't get me wrong, I support
tree cleaning by all means.

Glibc is special, llvm is the only other (not so similar) example.  No
more package will be special like this.  This will not set a bad example
or bad excuses for keeping outdated ebuilds.  I don't see your argument
of generic case.

> it does not mean that other members of toolchain or any other team
> will not end up having to remember extra rules like 'do not remove
> this ebuild because X wants it'.

Is that a problem?  When at least 1 person is eager to maintain an
package, the package could be kept.  Consider that person as the de
facto upstream.

Consider glibc-2.16 as a sys-libs/glibc-revived package that is too
closely connected to sys-libs/glibc be treated as a 2nd package.  Then
the package argument carries to a special version of ebuild.

Cheers,
Benda

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Michał Górny]

W dniu sob, 03.03.2018 o godzinie 22∶51 +0900, użytkownik Benda Xu
napisał:
> Hi Michał,
> 
> Michał Górny  writes:
> 
> > > I am sure you are aware that Prefix has two variants: one is
> > > prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
> > > of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
> > > Android/Linux.[1]
> > > 
> > > For LLVM example, it is prefix-rpath, which hosts its own overlay at
> > > repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
> > > the overlay.  But we still keep the ultimate goal of merging prefix.git
> > > into gentoo.git.
> > 
> > I am also keeping old versions of LLVM for Prefix team. That's why I'd
> > really prefer to get rid of them and have them in some common overlay
> > that all Prefix users can use.
> 
> Yes that's true. The case of LLVM for prefix-rpath is similar as glibc
> for prefix-standalone.
> 
> For the argument of overlay refer to the message below vvv
> 
> > > What we are discussing in this thread, however, is prefix-standalone, it
> > > uses the official gentoo repository without any overlay.  It works
> > > perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
> > > 2 ebuilds for prefix-standalone is an overkill.
> > 
> > Maybe it is. But isn't making maintenance of Gentoo packages more
> > complexity for Prefix an overkill? We are effectively switching
> > from trivial model of 'assign bug with X to maintainer' to checking
> > which maintainer applies to which version of X.
> 
> I am on the toolchain alias, and I am interested in joining the project.
> I will be responsible to deal with all the bugs for glibc-2.16 and
> glibc-2.19.  Bug wranglers' work load does not change.
> 
> Yes, I apologize this will generate some noise for toolchain@g.o.  But I
> anticipate people on the team are interested in receiving those emails.
> 

That's not a solution. That's cheap a cheap excuse that works for one
package, for today. It does not solve the generic case, it does not mean
that other members of toolchain or any other team will not end up having
to remember extra rules like 'do not remove this ebuild because X wants
it'.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Andreas,

I really appreciate your interest as I am try to convince our fellows.

"Andreas K. Huettel"  writes:

> another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> instead.

> Yes I know they are even older, but these are the versions that RHEL
> uses, and for which RH still provides support (until 2020 for 2.5,
> 2024 for 2.12)...
> https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

> That however would require that the RHEL patchsets are public
> somehwere. Which I doubt... after all there's an "E" in RHEL...

> [...]

> ... except that my personal motivation has dropped somewhat when
> noticing that the CentOS package applies 552 (!) patches on top of
> 2.17.

Carrying Redhat patches are not only technical unfeasible, but also out
of our best interest.  The reasons are the following.

glibc-2.5 does not support fortify, thus breaking gentoo version of gcc
since verison 4.3 (Bug 289757).  The original purpose of
prefix-standalone was to introduce newer glibc from gentoo to solve this
issue.  So shipping glibc-2.5 requires maintaining seperate versions of
gcc.

glibc has some tolerance for kernel.  2012 glibc-2.16 supports 2004
linux-2.6.8.  It buys us 8 years!  That's the basis for the magic of
prefix-standalone.  gcc in turn has some tolerance for glibc.  So far
glibc-2.16 is still supported by the newest gcc but glibc-2.5 is
definitely out of the game.

I hear your instinct for RHEL versions for security consideration.  But
in this use case, the kernels are usually outdated for many years and
prone to multiple privilege escalation CVE's.  If the administrators of
these systems cared about security, these antiques wouldn't have existed
in the first place.

Therefore, using edge versions of glibc-2.16 (newest glibc to support
linux 2.6+) and 2.19 (newest glibc to support linux 2.6.16+) makes more
sense.

Yours,
Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Michał,

Michał Górny  writes:

>> I am sure you are aware that Prefix has two variants: one is
>> prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
>> of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
>> Android/Linux.[1]
>> 
>> For LLVM example, it is prefix-rpath, which hosts its own overlay at
>> repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
>> the overlay.  But we still keep the ultimate goal of merging prefix.git
>> into gentoo.git.
>
> I am also keeping old versions of LLVM for Prefix team. That's why I'd
> really prefer to get rid of them and have them in some common overlay
> that all Prefix users can use.

Yes that's true. The case of LLVM for prefix-rpath is similar as glibc
for prefix-standalone.

For the argument of overlay refer to the message below vvv

>> What we are discussing in this thread, however, is prefix-standalone, it
>> uses the official gentoo repository without any overlay.  It works
>> perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
>> 2 ebuilds for prefix-standalone is an overkill.
>
> Maybe it is. But isn't making maintenance of Gentoo packages more
> complexity for Prefix an overkill? We are effectively switching
> from trivial model of 'assign bug with X to maintainer' to checking
> which maintainer applies to which version of X.

I am on the toolchain alias, and I am interested in joining the project.
I will be responsible to deal with all the bugs for glibc-2.16 and
glibc-2.19.  Bug wranglers' work load does not change.

Yes, I apologize this will generate some noise for toolchain@g.o.  But I
anticipate people on the team are interested in receiving those emails.

Cheers,
Benda

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi William and Alec,

Yes, I hear you.  

What I want to do is not randomly throwing upstream-unmaintained package
versions into Gentoo tree.  But the opposite, 1 specially maintained
glibc ebuild serving as a compatible layer will isolate the obsolete
linux kernel from the modern Gentoo tree.  Synonymically, 1 glibc ebuild
will allow the rest of the Gentoo tree compile and run on 10+ years old
platforms.

The users trapped with antique OS will be able to use tools from Gentoo,
and Gentoo will expand its horizon for new use cases.

Detailed replies inline, mostly repeating of the above point for special
cases.

William Hubbs  writes:

> I am with mgorny on this, this sort of specialized support does not
> belong in the main tree.
>
> The kernel versions you are talking about aren't even supported by the
> upstream kernel folks any more -- the oldest lts version is 3.2.99.

I am with you.  I don't care about outdated kernels.  Therefore I am
interested in a compatible layer that screens out the kernel.  So far, 1
glibc does the job.

Alec Warner  writes:

> So I actually originally thought this as well and settled on some
> logic that is:
>
> The problem we are trying to solve is supporting very old
> distros. This has two impacts on the tree:

> a) Very old versions of some packages stay in the tree because they
> are needed to support these old platforms.

s/some packages/1 glibc ebuild/

The concerned package is only 1 version of glibc per a group of kernels,
no more.  It is well-contained, not a can of worms.

> b) Very old versions of some packages will need to drop keywords for
> 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded
> only for 'prefix' but not for 'x86' or 'amd64'.

To clarify, prefix-standalone uses implicit keyword scheme, the same
usual keywords as 'amd64'.  We could mask the old versions as the status
quo.

> This is because the latter two are not well tested[1]
>
> A and B are both mostly about control and maintenance of the tree
> itself (these do not necessarily reflect the quality or stability of
> prefix as a platform.)
>
> The separate problem is:

> Given some prefix users are running prefix on these old platforms, how
> do we detect when support for them breaks (as it did for py3, and will
> again in the future when something else critical breaks.) 

We can require each platform (or profile) to have at least 1 dev as an
active user, for example:

  https://wiki.gentoo.org/wiki/Project:Prefix#Platform_matrix

Recently, I have found an ultimate solution to the python3 puzzle.
Usually, glibc exposes all the symbols it supports.  Whether the kernel
supports the symbols are determined at runtime.  But, if the glibc is
patched to be faithful to the kernels it is running on, python3 happily
compiles and runs.  And yes, we know exactly what kernels are expected,
e.g. glibc-2.16 for linux-2.6 ~ 2.6.15.  Therefore we have a define goal
to patch the glibc.

By this strategy, even RHEL4 runs python-3.6 well.

> I'm curious to hear more about this process, but I think its
> orthogonal to in-tree or in-overlay support; other than the overlay
> gives you more control over when to release / withdraw various package
> versions (more control than just keywords do in the main tree.)  Note
> that Gentoo itself purports to offer only 1 year of support for the
> main tree; so just based on that axiom alone I think trying to support
> 10+ year old platforms goes against what the main-tree is targeting.

Again, a glibc ebuild isolates the antique kernel and all the dirty work
of supporting 10+ year old platform is absorbed in 1 ebuild.  Therefore
the 1-year-of-support model of Gentoo tree is not violated and
untouched.

Hope that address the concerns of potential degradation of our main tree
quality.

Cheers,
Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Mittwoch, 28. Februar 2018, 11:57:37 CET schrieb Andreas K. Huettel:
>
> > https://git.centos.org/summary/rpms!glibc.git
> 
> 2.5 and 2.12 aren't there, but for 2.17 it looks good, this seems to be the
> complete patchset. We should be able to translate that into a gentoo branch.

... except that my personal motivation has dropped somewhat when noticing that 
the CentOS package applies 552 (!) patches on top of 2.17.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Mittwoch, 28. Februar 2018, 11:20:36 CET schrieb James Le Cuirot:
> On Wed, 28 Feb 2018 11:10:13 +0100
> 
> "Andreas K. Huettel"  wrote:
> > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> > instead.
> > 

> 
> You maybe won't get the full details of the changes but all the patches
> are here. This looks like a much better breakdown than you get with
> their kernel patches.
> 
> https://git.centos.org/summary/rpms!glibc.git

2.5 and 2.12 aren't there, but for 2.17 it looks good, this seems to be the 
complete patchset. We should be able to translate that into a gentoo branch.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[James Le Cuirot]

On Wed, 28 Feb 2018 11:10:13 +0100
"Andreas K. Huettel"  wrote:

> another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 instead.
> 
> Yes I know they are even older, but these are the versions that RHEL uses, 
> and 
> for which RH still provides support (until 2020 for 2.5, 2024 for 2.12)...
> https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping
> 
> That however would require that the RHEL patchsets are public somehwere. 
> Which 
> I doubt... after all there's an "E" in RHEL...

You maybe won't get the full details of the changes but all the patches
are here. This looks like a much better breakdown than you get with
their kernel patches.

https://git.centos.org/summary/rpms!glibc.git

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgps0dqy2j8lW.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18...

Benda, 

another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 instead.

Yes I know they are even older, but these are the versions that RHEL uses, and 
for which RH still provides support (until 2020 for 2.5, 2024 for 2.12)...
https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

That however would require that the RHEL patchsets are public somehwere. Which 
I doubt... after all there's an "E" in RHEL...

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Michał Górny]

W dniu nie, 25.02.2018 o godzinie 19∶31 +0900, użytkownik Benda Xu
napisał:
> Hi Michał,
> 
> Michał Górny  writes:
> 
> > I don't think this is the first old version Prefix team needs keeping.
> > Another example are old versions of LLVM.
> 
> I am sure you are aware that Prefix has two variants: one is
> prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
> of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
> Android/Linux.[1]
> 
> For LLVM example, it is prefix-rpath, which hosts its own overlay at
> repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
> the overlay.  But we still keep the ultimate goal of merging prefix.git
> into gentoo.git.

I am also keeping old versions of LLVM for Prefix team. That's why I'd
really prefer to get rid of them and have them in some common overlay
that all Prefix users can use.

> What we are discussing in this thread, however, is prefix-standalone, it
> uses the official gentoo repository without any overlay.  It works
> perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
> 2 ebuilds for prefix-standalone is an overkill.

Maybe it is. But isn't making maintenance of Gentoo packages more
complexity for Prefix an overkill? We are effectively switching
from trivial model of 'assign bug with X to maintainer' to checking
which maintainer applies to which version of X.

> 
> Yours,
> Benda
> 
> 1. https://wiki.gentoo.org/wiki/Project:Prefix

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> them are data acquisition hubs or computing clusters.  No administrator
> cares about security as long as they "work".
> 
> Under the form "Prefix", Gentoo is set out to rescue users trapped in
> these abandoned wastelands of antiques.  After years of work, we have
> achieved that goal, except one minor thing: glibc periodically drop
> support for old linux kernels, the lastest glibc supporting linux 2.6.8
> is 2.16 and for linux-2.6.18 it is glibc-2.19.
> 
> With the recent reunion of the Toolchain Project, old glibc versions are
> masked and removed, accelerating the adoption of new versions.  This
> opens a new oppotunity for the Prefix: people stops caring about
> unsupported glibc versions, the Prefix Project can take them over
> without worrying about breaking other peoples' machines.

Well, in principle the idea is OK. We already/still keep some old glibc, gcc, 
and binutils versions for that reason.

However, I have a few conditions.

* Only masked. Only prefix keywords.
If you really must unmask them in a specific prefix profile, you must provide 
big fat warnings about the resulting security risks.
(I dont know how things went in prehistoric times, but recently there have 
been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely 
not all of them.)

* No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
rules apply.

* Try to stick to a minimum of required features (and a minimum of required 
versions).
We want to strongly avoid adding conditionals to other packages. [#]

* Please use our gentoo glibc repo to keep track of branches and patchsets.
Happy to show you the details sometime soon.


[#] If not for such "old version" considerations, we could soon move the 
libtirpc headers to the place where the glibc headers used to live. That could 
save us a ...load of patching and bugfixing. By keeping flexibility and 
compatibility, that is unfortunately not possible.



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Alec Warner]

On Mon, Feb 26, 2018 at 12:22 PM, William Hubbs  wrote:

> On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote:
> > W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu
> > napisał:
> > > Hi all,
> > >
> > > Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> > > antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> > > them are data acquisition hubs or computing clusters.  No administrator
> > > cares about security as long as they "work".
> > >
> > > Under the form "Prefix", Gentoo is set out to rescue users trapped in
> > > these abandoned wastelands of antiques.  After years of work, we have
> > > achieved that goal, except one minor thing: glibc periodically drop
> > > support for old linux kernels, the lastest glibc supporting linux 2.6.8
> > > is 2.16 and for linux-2.6.18 it is glibc-2.19.
> > >
> > > With the recent reunion of the Toolchain Project, old glibc versions
> are
> > > masked and removed, accelerating the adoption of new versions.  This
> > > opens a new oppotunity for the Prefix: people stops caring about
> > > unsupported glibc versions, the Prefix Project can take them over
> > > without worrying about breaking other peoples' machines.
> > >
> > > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/
> kernel-2.6.16+
> > > unmasks  > > /lib/gentoo/functions.sh transition.  prefix/kernel-2.6+ with
> glibc-2.16
> > > is also planned.  In addition, glibc have to be patched to get python3
> > > built[1-3], which is urgent once portage drops python2[4].
> > >
> > >
> > > So I would like to hear what you guys think if I:
> > >
> > >   - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the
> > > selected Prefix profiles;
> > >
> > >   - maintain those selected outdated glibc versions on the
> > > infrastructure of the Toolchain Project[5];
> > >
> > >   - (optional) add an exception to the toolchain support policy[6].
> >
> >
> > How about moving them to an overlay?
>
> I am with mgorny on this, this sort of specialized support does not
> belong in the main tree.


So I actually originally thought this as well and settled on some logic
that is:

The problem we are trying to solve is supporting very old distros. This has
two impacts on the tree:
  a) Very old versions of some packages stay in the tree because they are
needed to support these old platforms.
  b) Very old versions of some packages will need to drop keywords for
'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded only
for 'prefix' but not for 'x86' or 'amd64'. This is because the latter two
are not well tested[1]

A and B are both mostly about control and maintenance of the tree itself
(these do not necessarily reflect the quality or stability of prefix as a
platform.)

The separate problem is:
Given some prefix users are running prefix on these old platforms, how do
we detect when support for them breaks (as it did for py3, and will again
in the future when something else critical breaks.) I'm curious to hear
more about this process, but I think its orthogonal to in-tree or
in-overlay support; other than the overlay gives you more control over when
to release / withdraw various package versions (more control than just
keywords do in the main tree.)

Note that Gentoo itself purports to offer only 1 year of support for the
main tree; so just based on that axiom alone I think trying to support 10+
year old platforms goes against what the main-tree is targeting.

-A


> The kernel versions you are talking about aren't even supported by the
> upstream kernel folks any more -- the oldest lts version is 3.2.99.
>
> Thanks,
>
> William
>
>

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[William Hubbs]

On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote:
> W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu
> napisał:
> > Hi all,
> > 
> > Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> > antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> > them are data acquisition hubs or computing clusters.  No administrator
> > cares about security as long as they "work".
> > 
> > Under the form "Prefix", Gentoo is set out to rescue users trapped in
> > these abandoned wastelands of antiques.  After years of work, we have
> > achieved that goal, except one minor thing: glibc periodically drop
> > support for old linux kernels, the lastest glibc supporting linux 2.6.8
> > is 2.16 and for linux-2.6.18 it is glibc-2.19.
> > 
> > With the recent reunion of the Toolchain Project, old glibc versions are
> > masked and removed, accelerating the adoption of new versions.  This
> > opens a new oppotunity for the Prefix: people stops caring about
> > unsupported glibc versions, the Prefix Project can take them over
> > without worrying about breaking other peoples' machines.
> > 
> > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
> > unmasks  > /lib/gentoo/functions.sh transition.  prefix/kernel-2.6+ with glibc-2.16
> > is also planned.  In addition, glibc have to be patched to get python3
> > built[1-3], which is urgent once portage drops python2[4].
> > 
> > 
> > So I would like to hear what you guys think if I:
> > 
> >   - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the
> > selected Prefix profiles;
> >  
> >   - maintain those selected outdated glibc versions on the
> > infrastructure of the Toolchain Project[5];
> > 
> >   - (optional) add an exception to the toolchain support policy[6].
> 
> 
> How about moving them to an overlay?

I am with mgorny on this, this sort of specialized support does not
belong in the main tree.

The kernel versions you are talking about aren't even supported by the
upstream kernel folks any more -- the oldest lts version is 3.2.99.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Michał,

Michał Górny  writes:

> I don't think this is the first old version Prefix team needs keeping.
> Another example are old versions of LLVM.

I am sure you are aware that Prefix has two variants: one is
prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset
of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
Android/Linux.[1]

For LLVM example, it is prefix-rpath, which hosts its own overlay at
repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
the overlay.  But we still keep the ultimate goal of merging prefix.git
into gentoo.git.

What we are discussing in this thread, however, is prefix-standalone, it
uses the official gentoo repository without any overlay.  It works
perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
2 ebuilds for prefix-standalone is an overkill.

Yours,
Benda

1. https://wiki.gentoo.org/wiki/Project:Prefix

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Michał Górny]

W dniu nie, 25.02.2018 o godzinie 18∶25 +0900, użytkownik Benda Xu
napisał:
> Hi Michał,
> 
> Michał Górny  writes:
> 
> > > So I would like to hear what you guys think if I:
> > > 
> > >   - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the
> > > selected Prefix profiles;
> > >  
> > >   - maintain those selected outdated glibc versions on the
> > > infrastructure of the Toolchain Project[5];
> > > 
> > >   - (optional) add an exception to the toolchain support policy[6].
> > 
> > How about moving them to an overlay?
> 
> I have reflected on this option and concluded it is an overkill to
> create an overlay for only 1 package.
> 

I don't think this is the first old version Prefix team needs keeping.
Another example are old versions of LLVM.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Benda Xu]

Hi Michał,

Michał Górny  writes:

>> So I would like to hear what you guys think if I:
>> 
>>   - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the
>> selected Prefix profiles;
>>  
>>   - maintain those selected outdated glibc versions on the
>> infrastructure of the Toolchain Project[5];
>> 
>>   - (optional) add an exception to the toolchain support policy[6].
>
> How about moving them to an overlay?

I have reflected on this option and concluded it is an overkill to
create an overlay for only 1 package.

Yours,
Benda

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Michał Górny]

W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu
napisał:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> them are data acquisition hubs or computing clusters.  No administrator
> cares about security as long as they "work".
> 
> Under the form "Prefix", Gentoo is set out to rescue users trapped in
> these abandoned wastelands of antiques.  After years of work, we have
> achieved that goal, except one minor thing: glibc periodically drop
> support for old linux kernels, the lastest glibc supporting linux 2.6.8
> is 2.16 and for linux-2.6.18 it is glibc-2.19.
> 
> With the recent reunion of the Toolchain Project, old glibc versions are
> masked and removed, accelerating the adoption of new versions.  This
> opens a new oppotunity for the Prefix: people stops caring about
> unsupported glibc versions, the Prefix Project can take them over
> without worrying about breaking other peoples' machines.
> 
> Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
> unmasks  /lib/gentoo/functions.sh transition.  prefix/kernel-2.6+ with glibc-2.16
> is also planned.  In addition, glibc have to be patched to get python3
> built[1-3], which is urgent once portage drops python2[4].
> 
> 
> So I would like to hear what you guys think if I:
> 
>   - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the
> selected Prefix profiles;
>  
>   - maintain those selected outdated glibc versions on the
> infrastructure of the Toolchain Project[5];
> 
>   - (optional) add an exception to the toolchain support policy[6].


How about moving them to an overlay?

> 
> Thanks and cheers!
> Benda
> 
> 1. https://bugs.python.org/issue28092
> 2. https://bugs.python.org/issue31255
> 3. https://bugs.python.org/issue29157
> 4. 
> https://archives.gentoo.org/gentoo-project/message/7eb61502d827476a9326b0f180dbd2fa
> 5. https://wiki.gentoo.org/wiki/Project:Toolchain/Patchsets_with_Git
> 6. https://wiki.gentoo.org/wiki/Project:Toolchain/Support_policies
> 

-- 
Best regards,
Michał Górny