Hello, On Mon, Sep 25, 2006 at 02:15:54PM -0400, Nathanael Nerode wrote: > Change this policy. You really must make two exceptions: > (1) Removal of material which Debian cannot legally distribute, if > upstream insists on keeping it. > (2) Removal of material which does not satisfy the DFSG, if > upstream insists on keeping it. Indeed, this should be another topic for the next kernel-team meeting. > One piece of "broken functionality" is loading firmware before the > root partition is mounted -- the lack of this breaks netbooting on the > boards which need the firmware. However, I can't do anything about this: > it requires running udev in the initramfs. This problem is not specific > to this driver. the needed functionality is provided by the initramfs-hook in the firmware-nonfree package, which makes sure the firmware.agent from udev is present in the initramfs too. > A second piece of "broken functionality" is the functionality provided > by the firmware: if the firmware isn't there and isn't loaded, the > functionality isn't there. Duh. I also can't do anything about this. Which functionality? TSO? > > Then, firmware-loading support in d-i is still missing, this issue > > should be be fixed too before we consider the patch. > > Firmware loading support patches are being refused in d-i until after etch > is released. Therefore, this amounts to a "We will not accept any firmware > loading patches until after we release etch" policy. Good to know. I can > still queue them up for you to commit afterwards, though. if we want to release in time, we should indeed collect the patches for post-etch. 2.6.20 should be the target for the first patches, as the merge window for 2.6.19 will not be open long enough anymore, except for the dgrs removal. Best regards Frederik Schueler -- ENOSIG
Attachment:
signature.asc
Description: Digital signature