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
18 matches
Mail list logo
