Re: 2.6.14 kernel udebs and d-i
On Tue, Nov 15, 2005 at 05:17:42PM -0500, Joey Hess wrote: Thought I'd document the process of updating d-i's kernel udebs from 2.6.12 to 2.6.14, since there's been various speculation about how automatable this is. Just a little addition from a porter's perspective. I uploaded the powerpc .udebs yesterday, and had to do : 1) removed the now gone tcic module from pcmcia-modules. 2) removed the nls_base module from fs-common-modules. 3) removed both unix and af_packet from socket-modules, removed the socket-modules .udeb altogether. These have been builtin since 2.6.12 i hear, altough maybe not for powerpc. 4) added the mii module to nic-shared-modules, as it was included by dependency in both nic-modules and nic-extra-modules and the build complained. 5) added a dependency from pcmcia-modules to firmware-modules as pcmcia-modules pulled in firmware_class and thus there where duplicated modules again. That's it, and only nls_base and tcic are even remotely porter related, and they where the most trivial fixes, and could easily have been automated if kernel-wedge knew how to ignore a no more provided module (i guess the ? symbol does this, right. Is there a reason not to make it automatic for each module ? Do we expect to catch modules that dissapeared this way ? And if we catch such, what should we do ?). The three other issues where issues that have undoubtly been fixed in some way in the i386 package, and should really have been added to kernel-wedge, right ? These where the ones which involve deeper knowledge of how kernel-wedge works, and will cause most trouble to porters which have only limited interaction with d-i, and should i believe really be the job of the d-i team. And Frans, no, insulting porters and complaining they don't do their job is no way to get this solved, and i find joeyh remark that only 6 d-i architectures support 2.6 kernels, while thanks to the common architecture, all debian official architectures now have 2.6 kernels since a couple of months quite illustrative of the problem faced by d-i here. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 kernel udebs and d-i
On Friday 25 November 2005 09:11, Sven Luther wrote: And Frans, no, insulting porters and complaining they don't do their job is no way to get this solved, and i find joeyh remark that only 6 d-i architectures support 2.6 kernels, while thanks to the common architecture, all debian official architectures now have 2.6 kernels since a couple of months quite illustrative of the problem faced by d-i here. No, I would say it is very much illustrative of the lack of porter interest and involvement in d-i. Note that having a working installer is a release requirement. If porters don't get their acts together and start work on getting and/or maintaining 2.6 support in d-i, we (the d-i release managers) may well be forced to exclude the arch from future releases and inform the Debian release managers that the arch no longer has a working installer. This would possibly result in disqualification for Etch (unless of course the arch can persuade the release managers that there is a valid alternative to install Debian). The d-i team has plenty of work to keep the general functionality in d-i in good shape. Asking them to also shoulder the minimal involvement we ask of porters is a totally unacceptable viewpoint. pgpoLeXYSbbPp.pgp Description: PGP signature
Re: 2.6.14 kernel udebs and d-i
On Fri, Nov 25, 2005 at 09:43:07AM +0100, Frans Pop wrote: On Friday 25 November 2005 09:11, Sven Luther wrote: And Frans, no, insulting porters and complaining they don't do their job is no way to get this solved, and i find joeyh remark that only 6 d-i architectures support 2.6 kernels, while thanks to the common architecture, all debian official architectures now have 2.6 kernels since a couple of months quite illustrative of the problem faced by d-i here. No, I would say it is very much illustrative of the lack of porter interest and involvement in d-i. There is *NO* porter work involved, only stupid book-keeping stuff needed to repackage the modules and kernel in .udebs, most of it could easily be automated or at least the part you want porters to do could easily be automated. I know i know, nobody feels it is worth to do this automation, as i have been rebuked for even suggesting this since april or so, but i have also been clamoring for a common kernel package since then, and see where we are now. Note that having a working installer is a release requirement. If porters don't get their acts together and start work on getting and/or maintaining 2.6 support in d-i, we (the d-i release managers) may well be forced to exclude the arch from future releases and inform the Debian release managers that the arch no longer has a working installer. This would possibly result in disqualification for Etch (unless of course the arch can persuade the release managers that there is a valid alternative to install Debian). Yeah, and thanks for the d-i team for making it more difficult for the porters who have to lose time in stupid repackaging work. We already did all the porting work in providing you a working ans suitable kernel from the common kernel package. The d-i team has plenty of work to keep the general functionality in d-i in good shape. Asking them to also shoulder the minimal involvement we ask of porters is a totally unacceptable viewpoint. Yeah, and the porters and kernel team have plenty of work to do without needing to additionally do the easily automatable drudge work of repackaging the modules in .udebs, especially as the d-i team has repeteadly said in the paste that they don't want this to be done from the common kernel package, as ubuntu does with success i would point out. But what else could i expect from you, anything which is not following your ideas you respond with abuse and insults. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 kernel udebs and d-i
16. Looked at the sun cassini nic card .. not quite sure why it's in the i386 kernel since some docs I find online seems to suggest it only works with Sun HW, but assumed the kernel team has a reason and added it to list. it's just a normal pci card, although afaik not shipped with anything but sparc hardware. as long as there's no additional work required it makes sense to support it on all architectures with PCI busses. 18. Looked at the new drivers/net/phy/ stuff, trying to decide whether to include the non-generic phy drivers (deps will pull in the generic phy support). Unsure, but left it out for now, since AFAIK nothing in d-i would load these modules. right now only plattforms for obscure ppc embedded boards use the framework. long-term all drivers with external PHYs should use this framework and we'll need to support these. I hope by that time a framework for autoloading the right PHY driver will be in place. 24. megaraid is removed (renamed to megaraid_mbox), so made kernel-wedge aware of that. Also, added megaraid_sas. actually there's two very old cards support only be megaraid and not megaraid_mbox. Where's trying to sort out the mess about this on the linux-scsi list. 26. Looked at raid_class's documentation which is in its entirity, Provides RAID. Blinked in puzzlement. Asked on irc. Went on to the next module. it's an embyonic generic raid managment framework. not useful on d-i yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6.14 kernel udebs and d-i
Thought I'd document the process of updating d-i's kernel udebs from 2.6.12 to 2.6.14, since there's been various speculation about how automatable this is. 1. Installed 2.6.14 kernel deb. 2. Ran find in the old and new kernel modules directories and diffed the list to find added/removed modules. 3. New crypto, acpi hotkey, drm, char, watchdog modules generally not relevant to d-i, skipped. 4. Two new firmware modules, dcdbas and dell_rbu. Looked at the source to see what the firmware was used by, looks not relevant for d-i. 5. Skipped new hwmon set of drivers after verifying they weren't useful in installation. 6. Skipped i2c changes, since noone has asked for any i2c stuff in d-i yet. 7. ide/pci/it821x is new, it's a new pci ide controller. Added to list in kernel-wedge. Verified that hw-detect will find and load it. 8. Skipped infiniband changes, since nooone has asked for that in d-i yet. 9. Skipped gameport driver removal, not relevant. 10. md.ko is renamed to md-mod.ko. Updated kernel-wedge to include whichever is available. Checked d-i tree for instances of modprobe md and fixed them to try both. Cursed the %$(#)@(# gratuitous module renaming squad some more. 11. Skipped media/dvb, media/video, not relevant for d-i. 12. Reviewed the new split mpt* modules. Got pretty confused and chatted with hch to sort it out. Added all three new modules. 13. Skipped mtd changes since d-i doesn't need it. 14. de600/de620 nic drivers are gone from binary kernel package (but not source), made them optional in linux-kernel-di-i386-2.6 modules list. 15. atp nic driver is also removed, but d-i didn't include it before for some reason, so no change needed. 16. Looked at the sun cassini nic card .. not quite sure why it's in the i386 kernel since some docs I find online seems to suggest it only works with Sun HW, but assumed the kernel team has a reason and added it to list. 17. Looked at new cxgb and added to nic-extra-modules. 18. Looked at the new drivers/net/phy/ stuff, trying to decide whether to include the non-generic phy drivers (deps will pull in the generic phy support). Unsure, but left it out for now, since AFAIK nothing in d-i would load these modules. 19. Added sis190, skge, uli526x nic modules. 20. Hostap is in this version of the kernel.. Left out for now even though I love this driver, since AFAIK other existing drivers should suffice for installation. Double-checked this in modules.pcimap, and indeed no pci ids are uniquely supported by hostap. 21. Skipped adding ipw2100 and ipw2200 since they appear to need firmware that is not included. 22. Skipped the orinoco_nortel module, seems very edge case. 23. Skipped the spectrum_cs module since it needs firmware and special utilities. 24. megaraid is removed (renamed to megaraid_mbox), so made kernel-wedge aware of that. Also, added megaraid_sas. 26. Looked at raid_class's documentation which is in its entirity, Provides RAID. Blinked in puzzlement. Asked on irc. Went on to the next module. 27. Added sata_mv, yay, more sata. 28. Skipped new serial board drivers. 29. Skipped usb atm, audio, misc, and input changes, none appicable. 30. Skipped new usb/host/isp116x-hcd module, for now, since I don't know if it's common enough to include and d-i doesn't try to load it with te other hcd module. 31. Skipped all the usb nic modules since once of d-i's blind spots is support for any usb network hardware. 32. Noticed that this kernel drops support for modular vesafb and might break d-i. Oh well.. 33. Skipped 1-wire bus stuff 34. Skipped plan 9 filesystem support, we'll get bug reports if someone needs it. 35. Skipped fuse, not applicable (for now?) 36. Skipped relayfs, no applicable. 37. Looked over new kernel lib modules and etc, including the new generic ieee80211 modules. 38. Skipped netfilter and other tcp stuff. 39. Skipped sound, security, and schedulers, d-i needs none of them. 40. Committed the changes, built and installed new kernel-wedge. 41. Did a test build of linux-kernel-di-i386-2.6. Got a successful build after four tries. Had to adjust the dependencies of pcmcia-modules to include firmwre-modules and make some other changes I'd missed. 42. Copied udebs to loacaludebs, updated config/i386.cfg to use the new kernel and ran a make all_rebuild to make sure d-i still built. -- see shy jo signature.asc Description: Digital signature
