Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:26:40AM +0200, Frans Pop wrote: On Wednesday 17 May 2006 20:53, Sven Luther wrote: We have metapackages in place, which i believe will take charge of upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any kernel upgrade, will need a reboot, which is not without risk, but which we should hopefully have ironed out all the major problems by the time of the etch release, so it should be made to be painless (or documented in the release notes). Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See the Sarge release notes for some potential issues users may face. Ok, i have read the sarge release notes, an i thus propose the following plan for etch : 1) we create a new package, linux-compatibility, which would be pre-depended on by the linux-image packages, and which would provide a predepend script, /etc/kernel/predepend.d/compatibility. 2) this pre-depend script will examine from what kernel we are upgrading (what kernel we are running, discovered by uname), what arch/subarch we are on, and based on that, make sure any number of known upgrade problems are respected. This will not fix all the cases, but new problems can be filed as bug reports against this package. 3) Since it is a pre-depend, we can inform the user about the issues, and even propose some automated fixes for the most common issues. We can also make sure to not call bootloader-update if the upgrade still is known to be breaking, after informing the user. 4) This would mean maintaining a mapping of name-changed modules and searching /etc/modules for them, detecting a lvm1 scenario, check for the presence of a sata controller, and propose the /dev/hda - /dev/sda changes, keyboard and mouse configuration. I am not sure alsa warrants a pre-depend fix, but we can inform the user of this issue. We use bugs against these packages to mass-test upgrade from sarge during the freeze phase, and complete this upgade package. So, it may not be trivial, but right now the issues are documented in the release notes, this would allow to either fix them during the upgrade, or at least include the documentation in the packages themselves, as not everyone reads release notes. What do you think about this plan ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Fri, May 19, 2006 at 06:19:21AM +0200, Sven Luther wrote: Maybe more interesting would be a list of all those arches and subarches who still have problems with 2.6, and a list of issues, so people with interest to work on them, can help out. Yes, I think both are interesting and could crosslink. This page would list the packages that need go be removed, and a terse explanation of why they need to stay. The terse explanation could include a link to a page that has more details about what the problems are. Both would be very good to announce broadly (hopefully by piggybacking on a release team update) so that people know what work is needed. Personally, the way I'd prefer to track this is to file a bug for removal of each of these packages now, but somehow mark them as on hold. For example: Bug #X: ftp.d.o: Please remove kernel-image-2.4-apus from sid/etch Bug #Y: d-i: stop using kernel-image-2.4-apus Bug #Z: linux-2.6: Add support for apus Where bug Y blocks bug X. However, I imagine the ftp masters wouldn't appreciate us filing bugs that we don't want them to fix yet. This could also be doubled in a list of issues which are debian specific patches also, and not yet merged upstream, with some kind of plan or eta or whatever for such a merge. Sure. I don't have any insight into the existing problems (other than indirectly based on what you, Thiemo Martin have mentioned here). So I'm probably not the best person to start such a page. By the way, sorry for the crudeness of that wiki page; I had to leave before I finished cleaning it up figured I'd just commit it first. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:18:29AM +0100, Thiemo Seufer wrote: dann frazier wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? Mips/mipsel d-i hasn't fully switched to 2.6 yet. Is there a urgent need to remove 2.4 from etch? There is a need to remove 2.4 *before* etch, but the reason for requesting the removal now is just to make it clear we will not ship 2.4 in etch - that's not a good reason to break existing d-i betas though. We could solve the same problem by just asking the release team to announce it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). This makes sense to me; maybe we should create a hitlist of 2.4 stuff that needs to be removed before etch, and remove all the bits that don't break d-i now, something like: http://wiki.debian.org/DebianKernel2%2e4EtchHitList -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 03:31:06PM -0500, dann frazier wrote: On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that powerpc/pmac/nubus is not yet ported to 2.6, we had a (largely untested though) 2.4.27 nubus kernel in sarge. This makes sense to me; maybe we should create a hitlist of 2.4 stuff that needs to be removed before etch, and remove all the bits that don't break d-i now, something like: http://wiki.debian.org/DebianKernel2%2e4EtchHitList Maybe more interesting would be a list of all those arches and subarches who still have problems with 2.6, and a list of issues, so people with interest to work on them, can help out. This could also be doubled in a list of issues which are debian specific patches also, and not yet merged upstream, with some kind of plan or eta or whatever for such a merge. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Tue, May 16, 2006 at 05:04:00PM -0500, dann frazier wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? No, please go ahead. If nothing else, it will allow for cleanup of other code bases which still think in terms of 2.4 kernels. Developers at DebConf have pointed out to me that removing these packages would help avoid confusion/unnecessary bug reports. Yep. The rough consensus was also to continue to support systems for which users have compiled their own 2.4 - if we proceed with this removal, we might ask the release team to explicitly note this in a d-d-a e-mail so that package maintainers do not break 2.4 support if possible. Ah, this kills the above mentioned cleanup though. Only d-i will be able to benefit from it, as it doesn't really make sense to keep those features for non-official kernels. On the other hand, if you'd really like to see 2.4 kernel images in Debian *and* are willing to assist with the security maintenance necessary to make this possible, please let me know. I vote against. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
[EMAIL PROTECTED] wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? Please do. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Tue, 16 May 2006, dann frazier wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? full ack. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
* dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Tue, May 16, 2006 at 05:04:00PM -0500, dann frazier wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? Developers at DebConf have pointed out to me that removing these packages would help avoid confusion/unnecessary bug reports. The rough consensus was also to continue to support systems for which users have compiled their own 2.4 - if we proceed with this removal, we might ask the release team to explicitly note this in a d-d-a e-mail so that package maintainers do not break 2.4 support if possible. How do you plan to handle upgrade from sarge for users that are running 2.4 kernel ? What should the release note say about that? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Sven Luther wrote: On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Frans, Joey, what is your opinion about this? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 09:47:27AM -0500, Stephen R Marenka wrote: To my knowledge *vme* and atari don't have large followings. True. [...] Although we do have buildds running for those subarchs, I believe they are running with custom kernels anyway. Err, no, ska is running a stock Debian kernel. I've stopped compiling custom kernels a while back. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 03:59:40PM +0200, Martin Michlmayr wrote: * Sven Luther [EMAIL PROTECTED] [2006-05-17 15:53]: In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. I know, but that'll probably break d-i. Probably yes, altough a two step removal (first from sid, then from etch), would maybe make this less severe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 07:51:32PM +0200, Michael Schmitz wrote: running with custom kernels anyway. Atari requires patches not in the kernel packages as I recall. IIRC 2.4.30 worked pretty much out of the box except for the serial driver (which is crucial for networking ATM). On _my_ CT60 I had to hack a bit more, but I guess I'm the only one with the CT60 installed on top of a 030 clock booster :-) 2.4 for stock Atari and even CT60 on stock Falcon should work out of the box. Isn't that stock 2.4.31 or something? I'm not sure that is what is in the 2.4.27 debian packages. (I could easily be wrong though. ;) So, as long as we're not dropping full support for 2.4 in other subsystems, I don't see a problem. Right. What subsystems might be affected? I think I've heard glibc wants to drop some cruft. I'm sure there are others. -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:57:51AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2006-05-16 17:04]: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? For mips/mipsel, there's at least one sub-arch that is not in 2.6 yet. It's getting close though, but in the meantime I'd like to keep 2.4. For arm, I've recently removed the last bits of 2.4 from d-i and I was going to request the removal after the next d-i beta. In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
* Sven Luther [EMAIL PROTECTED] [2006-05-17 15:53]: In general, imho 2.4 should be removed from d-i first for each arch, and then after the next beta the 2.4 kernel images can be removed. We can start with the removal of 2.4 from those architectures which no longer use 2.4 at all (e.g. powerpc). Notice that we are not asking removal from d-i, but from the archive completely. I know, but that'll probably break d-i. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
On Wed, May 17, 2006 at 01:03:13PM +0200, Christian T. Steigies wrote: Does any m68k subarch still need a 2.4 kernel? d-i is currently paying (at least some) attention to amiga, atari, q40, *vme*, and mac. Of those, only amiga seems to be ready for a full switch to 2.6. mac works on some hardware. We've never really supported q40, so that's not a loss. mac doesn't work with 2.4, anyway. To my knowledge *vme* and atari don't have large followings. Although we do have buildds running for those subarchs, I believe they are running with custom kernels anyway. Atari requires patches not in the kernel packages as I recall. So, as long as we're not dropping full support for 2.4 in other subsystems, I don't see a problem. Any one else? Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 07:18:11AM -0500, Bill Allombert wrote: On Tue, May 16, 2006 at 05:04:00PM -0500, dann frazier wrote: I believe there's a rough consensus to not ship 2.4 in etch. Anyone object to a filing of bugs to remove these packages from etch? Developers at DebConf have pointed out to me that removing these packages would help avoid confusion/unnecessary bug reports. The rough consensus was also to continue to support systems for which users have compiled their own 2.4 - if we proceed with this removal, we might ask the release team to explicitly note this in a d-d-a e-mail so that package maintainers do not break 2.4 support if possible. How do you plan to handle upgrade from sarge for users that are running 2.4 kernel ? What should the release note say about that? We have metapackages in place, which i believe will take charge of upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any kernel upgrade, will need a reboot, which is not without risk, but which we should hopefully have ironed out all the major problems by the time of the etch release, so it should be made to be painless (or documented in the release notes). If the user had installed a 2.4 kernel without using the metapackages, then his kernel will not be upgraded, as was his express wish, and all is fine for everybody. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: removing 2.4 from etch/sid]
d-i is currently paying (at least some) attention to amiga, atari, q40, *vme*, and mac. Of those, only amiga seems to be ready for a full switch to 2.6. mac works on some hardware. That's been my impression. Christian has been working on 2.6 for Atari lately though. To my knowledge *vme* and atari don't have large followings. Although we do have buildds running for those subarchs, I believe they are Buildds are running _on_ Atari. not for Atari :-) running with custom kernels anyway. Atari requires patches not in the kernel packages as I recall. IIRC 2.4.30 worked pretty much out of the box except for the serial driver (which is crucial for networking ATM). On _my_ CT60 I had to hack a bit more, but I guess I'm the only one with the CT60 installed on top of a 030 clock booster :-) 2.4 for stock Atari and even CT60 on stock Falcon should work out of the box. So, as long as we're not dropping full support for 2.4 in other subsystems, I don't see a problem. Right. What subsystems might be affected? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Wednesday 17 May 2006 22:12, Thiemo Seufer wrote: It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Yes, installs will break to some degree. If no 2.4 kernel is available, d-i will display a list of other available kernels (probably 2.6). However, crossinstalling kernel versions (i.e. installing running 2.4 setting up target with 2.6) is not really supported. It will probably lead to errors and at least some packages incorrectly installed or missing. Full CD installs are of course not affected. IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Full CD installations using that release could then still install 2.4 and we could set completing switches to 2.6 as the main goal for d-i Etch RC1. I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. Cheers, FJP [1] This depends mainly on changes needed to support persistent device naming in d-i which is very much needed for Etch. pgpizERxY1ONi.pgp Description: PGP signature
Re: removing 2.4 from etch/sid
On Wednesday 17 May 2006 20:53, Sven Luther wrote: We have metapackages in place, which i believe will take charge of upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any kernel upgrade, will need a reboot, which is not without risk, but which we should hopefully have ironed out all the major problems by the time of the etch release, so it should be made to be painless (or documented in the release notes). Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See the Sarge release notes for some potential issues users may face. pgpJ4fZ8UWcbc.pgp Description: PGP signature
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:24:57AM +0200, Frans Pop wrote: I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. The m68k porters just had a discussion about this and we're fine with whatever ya'll decide to do. We can always keep some unofficial kernels and installers around if necessary. In other words, don't worry about holding on to any kernels just for us. I hope to keep some 2.4 and 2.2 support in d-i until we get everything moved, but I'll try to keep it out of the way or in a branch. -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
Frans Pop wrote: [snip] IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Switching d-i reqires stable kernels for all subarchitectures, those are now mostly done for mips/mipsel. I hope we complete the move to 2.6 in 3-6 weeks. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:26:40AM +0200, Frans Pop wrote: On Wednesday 17 May 2006 20:53, Sven Luther wrote: We have metapackages in place, which i believe will take charge of upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any kernel upgrade, will need a reboot, which is not without risk, but which we should hopefully have ironed out all the major problems by the time of the etch release, so it should be made to be painless (or documented in the release notes). Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See the Sarge release notes for some potential issues users may face. Well, ok, so we already have a somehwat complete list of issues that the user can face. Contrary to woody-sarge migration though, where 2.6 kernels where not the default, we are facing another issue here, and we should take the time to clearly investigate all those migration problems, and offer a more detailed set of instructions, or even better, some automated way to do it. Naturally, udev is a mess, even in the case of 2.6-2.6 upgrades, and we don't need to handle the case of self built kernels, as the user will probably know how to handle the upgrade and o it by hand. We should do a massive upgrade testing from between the freeze and the release, and provide the best possible way for this. The : You are therefore strongly advised not to upgrade to a 2.6 kernel as part of the upgrade from woody to sarge. Instead, you should first make sure your system works correctly with either the old kernel or with a 2.4 kernel from sarge and do the upgrade to a 2.6 kernel later as a separate project. part of the release note, is not something we can consider now, so this makes a seamless upgrade all the more important. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Thiemo Seufer wrote: It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Frans, Joey, what is your opinion about this? I suppose it's a good reason to do a d-i release w/o 2.4 before dropping the kernel. (The GPL is another good reason..) I hadn't planned to do it that way, and I'd still like to see a decision that the kernel really is about to be dropped before removing it from d-i. -- see shy jo signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
On Wed, May 17, 2006 at 11:39:01PM -0500, Joey Hess wrote: Thiemo Seufer wrote: It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Frans, Joey, what is your opinion about this? I suppose it's a good reason to do a d-i release w/o 2.4 before dropping the kernel. (The GPL is another good reason..) I hadn't planned to do it that way, and I'd still like to see a decision that the kernel really is about to be dropped before removing it from d-i. Who should in your opinion take that decision ? I mean, it has been some time now since the kernel team announced the 2.4 obsolescence, and that it would be removed soonishly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
