Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 02:31:14PM +0200, Marco d'Itri wrote: On Aug 25, Thiemo Seufer [EMAIL PROTECTED] wrote: All those popular mips WLAN devices use still 2.4 kernels, some people started to port some of them to 2.6, but the main hindrance are binary only (and thus 2.4 only) drivers. It's not like they are already supported by debian anyway, then. Is there anything else? Can somebody comment on the alpha and m68k situations? The current lack of 2.6 support in the installer for alpha shouldn't really be an obstacle, but 2.6 doesn't currently work on my own alpha so I haven't been particularly motivated to fix up d-i to use it until I can usefully test it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
Horms writes... There are some architectures where 2.4 has been abandonded uptream, and these are being removed from the arcive powerpc (ok, thats one, not some) hppa is as well. It is still useful to have the 2.4 kernel-images in the archive since they are still more stable on some machines. Maybe willy/kyle/thibault can comment more. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 11:39:13PM -0700, Matt Taggart wrote: There are some architectures where 2.4 has been abandonded uptream, and these are being removed from the arcive powerpc (ok, thats one, not some) hppa is as well. It is still useful to have the 2.4 kernel-images in the archive since they are still more stable on some machines. Is it? There were no hppa 2.4 kernels included in sarge, because we were told by Thibaut that the upstream branch was rotting and not worth including. Is there really a reason to think it will be in *better* shape for etch? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Aug 25, Nathanael Nerode [EMAIL PROTECTED] wrote: So can we configure udev to stop managing /dev? This would remove my qualms Yes, as explained in README.Debian. It's not well tested, but it should work (at least in unstable). And another option is to make it use a different dev_root that /dev. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 10:16:02PM +0200, Gabor Gombas wrote: AFAIK the idea is to deprecate everything under /proc which is not strictly process-related information, but that transition will take many years (if ever completed, which I somewhat doubt). It would probably have been easier to rename /proc to /sys and gradually move the process stuff back over :) -- Jon Dowland http://jon.dowland.name/ FD35 0B0A C6DD 5D91 DB7A 83D1 168B 4E71 7032 F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Aug 25, Horms [EMAIL PROTECTED] wrote: There are some architectures where 2.4 is required, its because of these that it seems that we are stuck with 2.4 for Etch. alpha (installer), m68k (2.6 only works on amiga), s390 (installer), mips, mipsel What does installer mean? IIRC SuSE supports s390 with 2.6 kernels. Also, exactly how is 2.6 broken for mips and mipsel? From a quick google search it looks like it's actively developed and even commercially supported. There are some architectures, like i386, which are pretty well maintained upstream for 2.4, so it seems reasonable to keep them, It's not important how they are maintained now, but how they will be in two years. as we need 2.4 because of the first group, and its not a whole lot of extra effort - if it is lets get rid of them. I'm aware of the udev issue, I'm happy for that to be a catalyst for canning 2.4 where possible. But what about the arches that need 2.4. Does that mean we have to backport udev anyway? Not plausible, it depends on sysfs and the drivers core. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 12:43:14AM -0700, Steve Langasek wrote: On Wed, Aug 24, 2005 at 11:39:13PM -0700, Matt Taggart wrote: There are some architectures where 2.4 has been abandonded uptream, and these are being removed from the arcive powerpc (ok, thats one, not some) hppa is as well. It is still useful to have the 2.4 kernel-images in the archive since they are still more stable on some machines. Is it? There were no hppa 2.4 kernels included in sarge, because we were told by Thibaut that the upstream branch was rotting and not worth including. Is there really a reason to think it will be in *better* shape for etch? If its abandonded upstream, I would guess not. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Thursday 25 August 2005 10:45, Marco d'Itri wrote: On Aug 25, Horms [EMAIL PROTECTED] wrote: There are some architectures where 2.4 is required, its because of these that it seems that we are stuck with 2.4 for Etch. alpha (installer), m68k (2.6 only works on amiga), s390 (installer), mips, mipsel What does installer mean? IIRC SuSE supports s390 with 2.6 kernels. Here is a short conversation on #d-kernel on this subject: fjp waldi: Should work be started to support installing using 2.6.12 for s/390? fjp Or is there a reason to stick with 2.4.27? waldi fjp: we have nothing for configuring the hardware fjp waldi: configure in what way? waldi fjp: write the information into sysfs fjp waldi: Is that a kernel problem, a debian problem or a d-i problem? waldi the second fjp what packages are involved? waldi there is no package to do the configuration fjp Anybody working on this or likely to work on it? waldi i do, but no time fjp :-/ waldi i need mostly the same config type for my pseries machines pgpPRe13FAZr1.pgp Description: PGP signature
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 11:14:53PM +0200, martin f krafft wrote: also sprach Gabor Gombas [EMAIL PROTECTED] [2005.08.24.2204 +0200]: So IMHO udev is more generic than hotplug. This is Unix, not monolithic-land. Also, udev was set out to do nothing other than device node management. Well, having both hotplug and udev means a lot of code duplication. That's not very Unix either... The other comment is that udev is not generally accepted. A lot of people still have reservations about it. I think the reason is that udev is still under rapid development and people are only starting to explore the flexibility it provides. Uh, that's one way of looking at it. The other might be sheer insanity on the side of the developers. Well, since Greg K-H is upstream for both udev and hotplug, I'd say that's probably quite unlikely... [snip] Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Aug 25, Frans Pop [EMAIL PROTECTED] wrote: waldi there is no package to do the configuration This looks like something which can be easily fixed before the release. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
Marco d'Itri wrote: On Aug 25, Horms [EMAIL PROTECTED] wrote: There are some architectures where 2.4 is required, its because of these that it seems that we are stuck with 2.4 for Etch. alpha (installer), m68k (2.6 only works on amiga), s390 (installer), mips, mipsel What does installer mean? IIRC SuSE supports s390 with 2.6 kernels. Also, exactly how is 2.6 broken for mips and mipsel? From a quick google search it looks like it's actively developed and even commercially supported. Mips/mipsel spans a wide range of hardware with different capabilities and boot methods. There is no generic kernel. 2.6 on mips is currently well supported for some pricey prototype boards and for some older SGI workstations. All those popular mips WLAN devices use still 2.4 kernels, some people started to port some of them to 2.6, but the main hindrance are binary only (and thus 2.4 only) drivers. The next generation of those devices will _probably_ be based on 2.6. Thiemo signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Aug 25, Thiemo Seufer [EMAIL PROTECTED] wrote: All those popular mips WLAN devices use still 2.4 kernels, some people started to port some of them to 2.6, but the main hindrance are binary only (and thus 2.4 only) drivers. It's not like they are already supported by debian anyway, then. Is there anything else? Can somebody comment on the alpha and m68k situations? -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 03:55:03PM -0300, Otavio Salvador wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 25, Frans Pop [EMAIL PROTECTED] wrote: waldi there is no package to do the configuration This looks like something which can be easily fixed before the release. I don't think a guess is enough to remove something at this stage. No one is removing packages based on guesses. Lets say we think that s390 can be made to work with 2.6, well, that needs to happen and be shown to work for a good portion of the usebase before 2.4 gets pulled. In other words, if there are people using 2.4 for s390, and 2.6 doesn't work, then removal of 2.4 is unlikely. I believe this is the current status. Though perhaps we can work towards changing it. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
also sprach Marco d'Itri [EMAIL PROTECTED] [2005.08.24.1727 +0200]: I'd like to know your opinion about speeding up the transition and removing right now support for hotplug.d/ in your packages, making them depend on udev. I have two comments: udev is a device node manager, not a hook system for generic actions to be taking when a device is plugged or unplugged. RUN rules kinda make this possible, but udev is on the right track of doing the wrong thing (i.e. too much). The other comment is that udev is not generally accepted. A lot of people still have reservations about it. Moreover, several setups cannot be migrated to udev just like that, including 2.4 kernels, but also machines with devices not supporting the new kernel driver model (e.g. commercial drivers). Using udev is a decision that affects large other parts of the system and may break it. Requiring users to make that decision in favour of udev just to use my package (libphidgets) is a little over the top. PS: no need to CC me, I read -devel. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! they that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- benjamin franklin signature.asc Description: Digital signature (GPG/PGP)
Re: removing /etc/hotplug.d/ support
On Aug 24, martin f krafft [EMAIL PROTECTED] wrote: I have two comments: udev is a device node manager, not a hook system for generic actions to be taking when a device is plugged or udev has also been the hotplug multiplexer for some time now. The other comment is that udev is not generally accepted. A lot of people still have reservations about it. Moreover, several setups cannot be migrated to udev just like that, including 2.4 kernels, but also machines with devices not supporting the new kernel driver model (e.g. commercial drivers). 2.4 kernels will not be supported in etch, and we never tried to support proprietary drivers if doing so harms the rest of the system. Some people have reservations, but they appear to be driver more by emotion than by technical reasons. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
also sprach Marco d'Itri [EMAIL PROTECTED] [2005.08.24.1752 +0200]: I have two comments: udev is a device node manager, not a hook system for generic actions to be taking when a device is plugged or udev has also been the hotplug multiplexer for some time now. Yeah. Horrible. Will udev become an editor and MTA too, maybe after etch? 2.4 kernels will not be supported in etch, I don't think this is an authoritative statement. At the moment, some architectures do not work with 2.6. and we never tried to support proprietary drivers if doing so harms the rest of the system. Apart from the tg3-and-related stuff, we never took active action to make lives of those in need of proprietary drivers any more difficult than it already is. Some people have reservations, but they appear to be driver more by emotion than by technical reasons. Really? I have technical issues with udev-does-it-all, and I have issues with the upstream decisions. On a technical level, udev is too Gentoo for me, it's far from stable, and thus far from non-optional integration into Debian. This is my two cents. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! the duration of passion is proportionate with the original resistance of the woman. -- honoré de balzac signature.asc Description: Digital signature (GPG/PGP)
Re: removing /etc/hotplug.d/ support
[EMAIL PROTECTED] (Marco d'Itri) wrote: [/etc/hotplug.d being deprecated in favour of udev RUN rules] I'd like to know your opinion about speeding up the transition and removing right now support for hotplug.d/ in your packages, making them depend on udev. Two points: - I am tired of having to revamp the hotplugging framework every other month; - I don't want to see udev being forced upon our users if a clear, working and transparent upgrade path is not provided for each new version of udev from now on. To be honest, I installed a laptop the other day, and udev works well on it (sarge with a 2.6.12 kernel); but I probably won't be able to upgrade the kernel without running into problems with udev, which is a total pain. udev RUN rules at least guarantee that the device node exists when the script is run, which is definitely an improvement. If only upstream could be a bit more stable. What are we going to get next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 05:36:43PM +0200, martin f krafft wrote: I have two comments: udev is a device node manager, not a hook system for generic actions to be taking when a device is plugged or unplugged. RUN rules kinda make this possible, but udev is on the right track of doing the wrong thing (i.e. too much). Well, I have a different view: udev is a program to receive kernel events and evaluate/execute different rules based on the event, and it comes with a default ruleset to manage /dev nodes. hotplug is a program to receive kernel events and has a hardcoded way to execute some scripts based on these events. So IMHO udev is more generic than hotplug. The other comment is that udev is not generally accepted. A lot of people still have reservations about it. I think the reason is that udev is still under rapid development and people are only starting to explore the flexibility it provides. Moreover, several setups cannot be migrated to udev just like that, including 2.4 kernels, The question is will etch support 2.4 kernels out-of-the-box or not? If it will, then it is indeed a problem; otherwise it is just to be mentioned in the release notes. but also machines with devices not supporting the new kernel driver model (e.g. commercial drivers). As I see many Linux distributions are starting to use udev so commercial drivers will have to catch up in the not-so-distant future. Also, there are some quite easy workarounds (like creating device nodes in an init script) for most of the drivers. Using udev is a decision that affects large other parts of the system and may break it. Yes, that's true. It has a lot of potential however that may worth some breakage, especially since we are quite early in the release cycle. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 06:23:37PM +0200, Julien BLACHE wrote: To be honest, I installed a laptop the other day, and udev works well on it (sarge with a 2.6.12 kernel); but I probably won't be able to upgrade the kernel without running into problems with udev, which is a total pain. I only know of one major upgrade problem related to pre- and post-2.6.12 kernels and pre- and post-0.60 udev that was due to an unfortunate libsysfs bug that did not get detected early enough. The problem as I see it is that the in-kernel hotplug support is still incomplete so people working on hotplug support are likely to use both the latest kernel and latest user-space tools. This means cross-version problems won't be detected until non-developers start to use the code. If only upstream could be a bit more stable. What are we going to get next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs. AFAIK the idea is to deprecate everything under /proc which is not strictly process-related information, but that transition will take many years (if ever completed, which I somewhat doubt). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
also sprach Gabor Gombas [EMAIL PROTECTED] [2005.08.24.2204 +0200]: So IMHO udev is more generic than hotplug. This is Unix, not monolithic-land. Also, udev was set out to do nothing other than device node management. The other comment is that udev is not generally accepted. A lot of people still have reservations about it. I think the reason is that udev is still under rapid development and people are only starting to explore the flexibility it provides. Uh, that's one way of looking at it. The other might be sheer insanity on the side of the developers. The question is will etch support 2.4 kernels out-of-the-box or not? ... which we can't answer yet. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! half a bee, philosophically, must ipso facto half not be. -- monty python signature.asc Description: Digital signature (GPG/PGP)
Re: removing /etc/hotplug.d/ support
On Aug 24, Julien BLACHE [EMAIL PROTECTED] wrote: Two points: - I am tired of having to revamp the hotplugging framework every other month; Not a great point. There has been exactly one other change in the hotplug API in the past, and it started long ago with a very long transition period: switching from map files to hotplug.d/. - I don't want to see udev being forced upon our users if a clear, working and transparent upgrade path is not provided for each new version of udev from now on. When I asked the udev maintainer about this, he replied that he does not believe that it will be an issue in the future. We are not even at the step of requiring udev for everything, only for less than ten packages which require some special hotplug support. It's something which has to happen anyway before etch is frozen, so unless there are really good reasons to postpone it it may be a good idea to start now. If only upstream could be a bit more stable. What are we going to get next month ? Ah yes, usbfs being deprecated in favor of udev and sysfs. udev is just following kernel changes... I understand that /dev/bus/usb/ does not even requires udev. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Aug 24, martin f krafft [EMAIL PROTECTED] wrote: udev has also been the hotplug multiplexer for some time now. Yeah. Horrible. Will udev become an editor and MTA too, maybe after etch? No. But since it had to deal with most events, applying the same process to the others was a natural extension of its design. 2.4 kernels will not be supported in etch, I don't think this is an authoritative statement. At the moment, some architectures do not work with 2.6. It's an educated guess. I consulted some of the interested maintainers and followed the debian-kernel list, and so far there is no sign that 2.4 will be supported (and if 2.6 will not be fixed on architectures like sparc32, too bad for them). and we never tried to support proprietary drivers if doing so harms the rest of the system. Apart from the tg3-and-related stuff, we never took active action to make lives of those in need of proprietary drivers any more difficult than it already is. We are not discussing changes because I am bored, but because there are sound technical reasons which justify them. Some people have reservations, but they appear to be driver more by emotion than by technical reasons. Really? I have technical issues with udev-does-it-all, and I have issues with the upstream decisions. On a technical level, udev is too Gentoo for me, it's far from stable, and thus far from non-optional integration into Debian. This is my two cents. Both SuSE and Red Hat have made udev mandatory, so you will need much better arguments if you want to persuade people that udev has fundamental design problems which make it unsuitable for Debian. -- ciao, Marco signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 01:09:14AM +0200, Marco d'Itri wrote: When I asked the udev maintainer about this, he replied that he does not believe that it will be an issue in the future. We are not even at the step of requiring udev for everything, only for less than ten packages which require some special hotplug support. Aha, so I'll be able to carry sane forks of those. Good to know - Debian userland is nice for kernel work, would be a PITA to be forced to go looking for replacement... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 01:01:10AM +0200, Marco d'Itri wrote: On Aug 24, martin f krafft [EMAIL PROTECTED] wrote: udev has also been the hotplug multiplexer for some time now. Yeah. Horrible. Will udev become an editor and MTA too, maybe after etch? No. But since it had to deal with most events, applying the same process to the others was a natural extension of its design. 2.4 kernels will not be supported in etch, I don't think this is an authoritative statement. At the moment, some architectures do not work with 2.6. It's an educated guess. I consulted some of the interested maintainers and followed the debian-kernel list, and so far there is no sign that 2.4 will be supported (and if 2.6 will not be fixed on architectures like sparc32, too bad for them). Although being able to ship just one kernel for all our ports in etch is everyone's first choice, the release team has not made any decision yet to exclude 2.4 kernels from etch if they're needed for a particular arch or subarch. Given that the kernel team is still rolling new 2.4 updates in unstable, and d-i still defaults to 2.4 on a majority of archs, I think it is premature to drop hotplug support for 2.4 at this point. It would certainly be a big help to the release team in making this decision if the kernel team would begin to drop 2.4 kernels as early as possible in the release cycle for those architectures where they believe they are no longer needed. Together with working out which ports are actually viable for etch under the new requirements (which of course first requires fully specifying those requirements), we should be able to get a clear picture in a couple of months of just what the kernel requirements are for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
Gabor Gombas [EMAIL PROTECTED] wrote: Well, I have a different view: udev is a program to receive kernel events and evaluate/execute different rules based on the event, and it comes with a default ruleset to manage /dev nodes. So can we configure udev to stop managing /dev? This would remove my qualms about making udev mandatory. (I have been quite happy with static /dev and have not found udev ready for prime time yet.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 04:59:01PM -0700, Steve Langasek wrote: On Thu, Aug 25, 2005 at 01:01:10AM +0200, Marco d'Itri wrote: On Aug 24, martin f krafft [EMAIL PROTECTED] wrote: udev has also been the hotplug multiplexer for some time now. Yeah. Horrible. Will udev become an editor and MTA too, maybe after etch? No. But since it had to deal with most events, applying the same process to the others was a natural extension of its design. 2.4 kernels will not be supported in etch, I don't think this is an authoritative statement. At the moment, some architectures do not work with 2.6. It's an educated guess. I consulted some of the interested maintainers and followed the debian-kernel list, and so far there is no sign that 2.4 will be supported (and if 2.6 will not be fixed on architectures like sparc32, too bad for them). Although being able to ship just one kernel for all our ports in etch is everyone's first choice, the release team has not made any decision yet to exclude 2.4 kernels from etch if they're needed for a particular arch or subarch. Given that the kernel team is still rolling new 2.4 updates in unstable, and d-i still defaults to 2.4 on a majority of archs, I think it is premature to drop hotplug support for 2.4 at this point. It would certainly be a big help to the release team in making this decision if the kernel team would begin to drop 2.4 kernels as early as possible in the release cycle for those architectures where they believe they are no longer needed. Together with working out which ports are actually viable for etch under the new requirements (which of course first requires fully specifying those requirements), we should be able to get a clear picture in a couple of months of just what the kernel requirements are for etch. There are some architectures where 2.4 is required, its because of these that it seems that we are stuck with 2.4 for Etch. alpha (installer), m68k (2.6 only works on amiga), s390 (installer), mips, mipsel There are some architectures where 2.4 has been abandonded uptream, and these are being removed from the arcive powerpc (ok, thats one, not some) There are some architectures, like i386, which are pretty well maintained upstream for 2.4, so it seems reasonable to keep them, as we need 2.4 because of the first group, and its not a whole lot of extra effort - if it is lets get rid of them. I'm aware of the udev issue, I'm happy for that to be a catalyst for canning 2.4 where possible. But what about the arches that need 2.4. Does that mean we have to backport udev anyway? I might add, that right now I'm doing the bulk of 2.4 maintenance, and my current plan is to just keep patching 2.4.27, the sarge kernel, and eventually, once all the current teething problems are ironed out with the single-source 2.6 package, use that framework to produce a new 2.4.X, probably .35 or so by then. Also, I only have powerpc (not supported by 2.4) and i386 hardware at my disposal, so it would be very convenient for me to keep 2.4.27 around for i386. Though I'm not really concerend about being able to install 2.4.27, just have something to test, so I guess that doesn't have to be a package that appears in Debian. But if I'm building the things, it seems like it might as well. Finally, the lists above are probably incomplete, please jump in with additional information if you have it. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
