On 23 December 2014 at 00:11, Andreas K. Huettel 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
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 fu
On 12/23/14 21:40, Matt Turner wrote:
On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile 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 toolcha
On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile 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
Am 23. Dec 2014, 16:51 schrieb William Hubbs :
>> 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 b
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 wa
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
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 a
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,
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
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. Y
On Mon, Dec 22, 2014 at 11:55 PM, William Hubbs 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 w
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 toolcha
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 giv
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
On Mon, Dec 22, 2014 at 4:22 PM, Andreas K. Huettel
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 g
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
> >
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,
On Mon, Dec 22, 2014 at 11:20 AM, 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.
On Mon, Dec 22, 2014 at 10:52 AM, Anthony G. Basile wrote:
> On 12/22/14 10:39, Rich Freeman wrote:
>>
>> On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs
>> wrote:
>>>
>>> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
IMHO, maintaining a sensible set of old glibc versi
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,
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 ke
> +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
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,
>
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
On 12/22/14 10:39, Rich Freeman wrote:
On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs 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 gene
On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs 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 sa
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.
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
versi
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. you
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 dro
-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 dr
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
33 matches
Mail list logo
