Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 developer
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 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: bluen...@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
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, 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
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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. signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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: bluen...@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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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: bluen...@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
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: bluen...@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
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 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
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 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 pgp_P0Kk8NiU0.pgp Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 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
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 dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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.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
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 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
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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: bluen...@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
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: bluen...@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
> +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 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 pgpyR6iNHgt9R.pgp Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-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 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 dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 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: bluen...@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
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 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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 pgpEZT7DrqxH3.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
-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 iQF8BAEBCgBmBQJUlx7ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZCJ4H/0coofEKcsika34IaHI609gR Q2ZOhmcgV82wu6zwpIRVQaIDFCfo170c1g6OfffaaVLpu6VrvlN0lOxA0s2fPVuk pyf3ZjmElVyhncPtfCBIlygfvdabEv5UCEi8dgOe59tz6SyXarvRdKdQOsWy8yRx 38LGDH/vcmlcTbVKXfKuNPZ52hhfTspw7/QDxIqwufDqXaFV/sP+nLRTWKlK293I twO6biE3m60ggwaEyL5+LT4ZQZTQ2MnfDpBD8Rr1+xPwIj7rvgbJCVul1B1NZq6m gxYS078K8SeSEroum4wrZKj6OI8oIAic7Apa9wpp+tDXPOMYYn7SxvNtOBVpa/w= =rlNJ -END PGP SIGNATURE-
[gentoo-dev] rfc: glibc versions prior to 2.19-r1
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 signature.asc Description: Digital signature
