Re: Selection of kernel for Lenny
Steve Langasek a écrit : Hi Aurelien, Hi! On Mon, Jul 07, 2008 at 06:19:01PM +0200, Aurelien Jarno wrote: - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. Have you gotten any closer to finding the cause of this regression? Yes, I have now found the cause of the regression, it is actually not due to linux-libc-dev. Sorry about the wrong information, I have been misleaded by the randomness of the bug... The bug has been triggered by a patch fixing another bug, and is due to problems in lock implementation on hppa (hence the randomness). More details in bug #489906. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Hi Aurelien, On Mon, Jul 07, 2008 at 06:19:01PM +0200, Aurelien Jarno wrote: - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. Have you gotten any closer to finding the cause of this regression? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Thu, 10 Jul 2008, Andres Salomon wrote: On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: [...] I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. Not to mention OLPC support; it would be *really* nice to be able to use d-i to install Debian onto an XO. Of course, other things (grub-under-OFW or just plain OFW support, jffs2 formatting support, etc) would need to be in place as well for it to work. I haven't kept up on the status of those things, but I know that people have been working on them. right forgot to mention PS3 efforts too. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
* Luk Claes [EMAIL PROTECTED] [2008-07-07 23:31]: No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. hint added. Do you know why it hasn't moved to testing yet? The output of grep-excuses doesn't mean anything to me in this case. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Thu, Jul 10, 2008 at 11:15:58AM +0300, Martin Michlmayr wrote: * Luk Claes [EMAIL PROTECTED] [2008-07-07 23:31]: No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. hint added. Do you know why it hasn't moved to testing yet? The output of grep-excuses doesn't mean anything to me in this case. Because linux-modules-contrib-2.6 is not ready. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Thu, Jul 10, 2008 at 10:47:38AM +0200, Bastian Blank wrote: On Thu, Jul 10, 2008 at 11:15:58AM +0300, Martin Michlmayr wrote: * Luk Claes [EMAIL PROTECTED] [2008-07-07 23:31]: No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. hint added. Do you know why it hasn't moved to testing yet? The output of grep-excuses doesn't mean anything to me in this case. Because linux-modules-contrib-2.6 is not ready. shouldn't that be ignored!? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Hi, On Thursday 10 July 2008 10:47, Bastian Blank wrote: Do you know why it hasn't moved to testing yet? The output of grep-excuses doesn't mean anything to me in this case. Because linux-modules-contrib-2.6 is not ready. How is a package in contrib holding up a package in main? regards, Holger pgp700VrxvNxH.pgp Description: PGP signature
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: [...] I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. Not to mention OLPC support; it would be *really* nice to be able to use d-i to install Debian onto an XO. Of course, other things (grub-under-OFW or just plain OFW support, jffs2 formatting support, etc) would need to be in place as well for it to work. I haven't kept up on the status of those things, but I know that people have been working on them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off As a poor simple user, this seems mistaken. Correct me if I'm wrong, but isn't it the case that d-i quickly comes out once a kernel is in *testing* so the problem with d-i dragging is really that the kernel team doesn't support testing only unstable (from the sounds of it). I mean in another email max says that testing is on an unsupported kernel. WTF. .24 isn't that old and I'm not sure if .25 is even in testing yet (when I last checked it wasn't). Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com signature.asc Description: PGP signature
Re: Selection of kernel for Lenny
Daniel Dickinson [EMAIL PROTECTED] writes: On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off As a poor simple user, this seems mistaken. Correct me if I'm wrong, but isn't it the case that d-i quickly comes out once a kernel is in *testing* so the problem with d-i dragging is really that the kernel team doesn't support testing only unstable (from the sounds of it). I mean in another email max says that testing is on an unsupported kernel. WTF. .24 isn't that old and I'm not sure if .25 is even in testing yet (when I last checked it wasn't). For d-i matters if the kernel is ready (or almost ready) to migrate to testing since it's very problematic for us to break user installation using daily images during the Debian kernel stabilization effort that, today, is done in unstable. Testing kernel, nowadays, is indeed unsupported since to update it is much harder and risk since the kernel doesn't have a period of time on unstable (it needs to go throught testing-proposed-updates) before hitting testing. What we're proposing is a change on that. Leaving those first uploads some time on experimental and then moving to unstable when major problems were solve (as is done in many other teams as Xorg, KDE, GNOME, ...) and then reducing the time required for the kernel to migrate from unstable to testing. Doing that, it would allow us to move d-i much fastly to the unstable kernel since we'd be in a much safe bed. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. we have allways stated that .26 will be the release kernel. i don't understand why this would come as a surprise. .26 is to be released in a week, which is early enough to prepare all stuff including testing migration. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. agreed on the week point, but not to your conclusions. it often happens that d-i is blocking on older release. like the beta that happened to want to stick to 2.6.22 which was a pure catastrophe, half a year too old, without support for e1000e and newer intel boards.. We worked around this for .24 by doing an upstream stable update through t-p-u. dannf did and he is from the kernel team. it was not a workaround, but again a stick to previous instead of working forward. Upstream does seem to recognize the fact that a new release will need at least a few updates before it is actually stable and usable, and will therefore do at least a few stable updates (for both new stable and stable -1 in parallel). This basically happens in parallel to the new merge window (say the time to -rc2) and some upstream releases get longer term upstream stable support (.18, .22, .25). .22 didn't stay long with us. this was said back then for .16 and didn't matter on the long run. My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. don't see any point on that. it wouldn't accelerate the meta package sort. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. this is a currently a week point, but unstable is the place to sort such. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off would wish that kmuto be an official d-i member. he even tracks rc snapshot releases when necessary. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. I don't understand why this would come as a surprise. I'll start with reminding you that the toolchain is frozen and that the kernel is part of it. Now could you explain how changing kernel for a new upstream, with the well known fact that one needs to wait for the .2/.3 to have a decent working kernel (IOW in at least 2/3 weeks after the release) is not a disruptive change[1]? Add testing migration to that, plus tied transitions, then I expect a really good rationale from you to explain why a 6-8 weeks delay in the toolchain freeze (IOW in the release process) is acceptable and needed[2]. The fact that you're unable to understand that is quite worrying. [0] http://lists.debian.org/debian-release/2007/04/msg00189.html [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? [2] and I'm pretty sure the d-i crew has alike reservations. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8H2BrkvQe0.pgp Description: PGP signature
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) * has upstream coordination with xen and openvz * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. I don't understand why this would come as a surprise. I'll start with reminding you that the toolchain is frozen and that the kernel is part of it. Now could you explain how changing kernel for a new upstream, with the well known fact that one needs to wait for the .2/.3 to have a decent working kernel (IOW in at least 2/3 weeks after the release) is not a disruptive change[1]? Add testing migration to that, plus tied transitions, then I expect a really good rationale from you to explain why a 6-8 weeks delay in the toolchain freeze (IOW in the release process) is acceptable and needed[2]. a freeze exception for releasing debian with an uptodate and tuned system is worth. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. kind regards -- maks ps fjp is wrong we don't switch to pata and are not forced to do so for 2.6.26, no idea, where he got that idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
maximilian attems [EMAIL PROTECTED] writes: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. agreed on the week point, but not to your conclusions. it often happens that d-i is blocking on older release. like the beta that happened to want to stick to 2.6.22 which was a pure catastrophe, half a year too old, without support for e1000e and newer intel boards.. This was mostly caused due the risk of the kernel to not be ready on time. We do need to have a better process to avoid those two problems to happen from now on. ... My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. don't see any point on that. it wouldn't accelerate the meta package sort. But it would accelerate the d-i migration since we could mostly of time do the switch at same time of kernel going sid. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. this is a currently a week point, but unstable is the place to sort such. No. experimental is the place for that. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off would wish that kmuto be an official d-i member. he even tracks rc snapshot releases when necessary. It is different case when we are working with a full set of architectures and planning to not hurt users. You need to agree that if one derivative breaks, it hurts much less people then if oficial d-i breaks. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. And how about the other and correlated changes that would be need like toolchain and base? We're on _freeze_, bear that on mind. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote: On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) I'm really afraid with the number of bugs it'll open though. * has upstream coordination with xen and openvz Does this mean that dom0 will work with .26 ? If yes, then maybe .26 is really worth considering. If not, this is quite moot. * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. Well, we did asked for updates from core teams in our mails to d-d-a numerous times without our prior nagging, which was clearly meant to avoid this kind of communication issues. For the rest I assume the release team will have to discuss things a bit further. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. Well, that's a sine qua non condition. L-L-Dev breakages are horrible, and we just cannot aford one. It does not mean that I consider .26 to be a clever idea right now, but a l-l-d breakage would be a plain no-go. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpab0ChSrdEt.pgp Description: PGP signature
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 03:27:17PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote: On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) I'm really afraid with the number of bugs it'll open though. upstream has much better control of it thanks to kernelopps, random .config boot tests and regression handling. * has upstream coordination with xen and openvz Does this mean that dom0 will work with .26 ? If yes, then maybe .26 is really worth considering. If not, this is quite moot. we get snapshot working, that is *important* for guest. otherwise you would not be able to migrate your debian guest. and please don't dismiss openvz, which is the new emerging namespace solution that has more features then vserver and works actively on upstream merge. we have worked together with openvz devs to have .26 openvz images. * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 of course a lot of fixes and forgot to mention the * Read-only bind mounts which can come in really handy for chroots and buildd. we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. Well, we did asked for updates from core teams in our mails to d-d-a numerous times without our prior nagging, which was clearly meant to avoid this kind of communication issues. For the rest I assume the release team will have to discuss things a bit further. okay sorry for having not catched that. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. Well, that's a sine qua non condition. L-L-Dev breakages are horrible, and we just cannot aford one. It does not mean that I consider .26 to be a clever idea right now, but a l-l-d breakage would be a plain no-go. sure fully agreeed. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 maximilian attems wrote: * Read-only bind mounts which can come in really handy for chroots and buildd. JFYI: recently 'bindfs' package was uploaded to Debian archive, it can do it easily without new kernel. My 2 cents, only. Regards, Eugene V. Lyubimkin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhzfLUACgkQchorMMFUmYwwOACgwTTcdSiNuJiko0tT+mG8seHc APgAnRSe2822LNilSH8Yfohmq4APr2O6 =GI4a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 05:41:57PM +0300, Eugene V. Lyubimkin wrote: maximilian attems wrote: * Read-only bind mounts which can come in really handy for chroots and buildd. JFYI: recently 'bindfs' package was uploaded to Debian archive, it can do it easily without new kernel. not at vfs level. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
(adding d-kernel and d-release) On Monday 07 July 2008, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 03 July 2008, Otavio Salvador wrote: please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 Please wait few more days until we get it properly done on sid (d-i migrates to it). Why? We have never blocked migration of a new kernel when that wasn't needed because of a D-I release. Uploading udebs and switching to a kernel is not dependant on the migration. A new kernel can basically migrate (from a D-I PoV) as soon as a release is out. Except that kernel team wants it to upload 2.6.26 to sid when it's released (probably this week) OK, then _that_ should be discussed, not the migration to testing. The two are completely separate issues. In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. Delaying the upload of .26 to unstable could give us time, as a distribution, to stay up to date with .25, see how things are going with .26 and make a more informed decision. However, if the kernel team (together with maybe the release team) has already decided on .26 for Lenny, then it would be better to get it into unstable ASAP and for D-I to basically skip .25. and we have not yet got all architectures tested with 2.6.25 on d-i. So what? That's largely our own damned fault... Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Selection of kernel for Lenny
Frans Pop a écrit : Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. As the release team is Cc:ed, I just want to make sure it is aware that switching to 2.6.26 possibly means changes to userland, and thus freeze exceptions. A few examples: - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to removed headers. Change have been needed in various packages including glibc. - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. - I have recently uploaded a new version of lm-sensors needed to support 2.6.26 kernels. That said I neither opposed nor in favor of a switch to 2.6.26, I just want to emphasize that it can have a bigger impact than expected on the release planning. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Mon, Jul 07, 2008 at 04:19:01PM +, Aurelien Jarno wrote: Frans Pop a écrit : Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. As the release team is Cc:ed, I just want to make sure it is aware that switching to 2.6.26 possibly means changes to userland, and thus freeze exceptions. A few examples: - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to removed headers. Change have been needed in various packages including glibc. - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. - I have recently uploaded a new version of lm-sensors needed to support 2.6.26 kernels. That said I neither opposed nor in favor of a switch to 2.6.26, I just want to emphasize that it can have a bigger impact than expected on the release planning. Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGLZAYTa17l.pgp Description: PGP signature
Re: Selection of kernel for Lenny
* Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 05:30:09PM +0200, Frans Pop wrote: (adding d-kernel and d-release) On Monday 07 July 2008, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 03 July 2008, Otavio Salvador wrote: please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 Please wait few more days until we get it properly done on sid (d-i migrates to it). Why? We have never blocked migration of a new kernel when that wasn't needed because of a D-I release. Uploading udebs and switching to a kernel is not dependant on the migration. A new kernel can basically migrate (from a D-I PoV) as soon as a release is out. Except that kernel team wants it to upload 2.6.26 to sid when it's released (probably this week) OK, then _that_ should be discussed, not the migration to testing. The two are completely separate issues. In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). disabled. Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. Delaying the upload of .26 to unstable could give us time, as a distribution, to stay up to date with .25, see how things are going with .26 and make a more informed decision. However, if the kernel team (together with maybe the release team) has already decided on .26 for Lenny, then it would be better to get it into unstable ASAP and for D-I to basically skip .25. .26 is the release kernel. so i'm happy with push on it. .25 is a possible backup. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
* Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
maximilian attems [EMAIL PROTECTED] writes: .26 is the release kernel. so i'm happy with push on it. .25 is a possible backup. I'd like to get an official statement from RM team about that so we can move it further. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Michlmayr [EMAIL PROTECTED] writes: * Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkhyZJAACgkQLqiZQEml+FUgZwCfUX/L+aGf7m4sk0rsAua3M3Eo 4SAAoJFrBJQgdwpJ4y+FHgUPEdAUFkTF =i8PB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. We worked around this for .24 by doing an upstream stable update through t-p-u. Upstream does seem to recognize the fact that a new release will need at least a few updates before it is actually stable and usable, and will therefore do at least a few stable updates (for both new stable and stable -1 in parallel). This basically happens in parallel to the new merge window (say the time to -rc2) and some upstream releases get longer term upstream stable support (.18, .22, .25). My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Selection of kernel for Lenny
Otavio Salvador wrote: Martin Michlmayr [EMAIL PROTECTED] writes: * Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. hint added. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Monday 07 July 2008, Frans Pop wrote: .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). #d-uk just gave me this tidbit: ... am I missing something or will the move to .26, with libata binding before most of the IDE stuff, cause a lot of pain unless the distro manages the move from hd* to sd*? Which is basically the why don't we have persistent device naming issue (on which I won't comment). There's two things to say about this (assuming status quo otherwise): - this will probably reduce the pain on reboots for new installations as module loading order should become more predictable between different boots - this may increase the pain for people upgrading from Etch to Lenny, or not, or ... Other related issue/question. Early in lenny, when libata first stuck up its head, we made some effort to disable drivers or remove duplicate PCI IDs so that existing users using the old IDE drivers would not suddenly be confronted with a hda-sda switch. I have not really followed Debian kernels regarding this, but currently I think we basically just have both IDE and ATA drivers enabled. Correct? Are any of those early avoid duplicate PCI ID patches still active? Do we have any idea yet how this is going to be handled/documented for upgrades? signature.asc Description: This is a digitally signed message part.
