On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote: > On Tue, 12 Jun 2012, Daniel Baumann wrote: > > On 06/12/2012 06:04 PM, Henrique de Moraes Holschuh wrote: > > > I don't care as long as nobody is going to get in the way of an > > > urgency=high upload of firmware-nonfree to stable-proposed-updates or > > > stable-updates. > > > > there have been updates of firmware-* packages in the past and more > > recently for squeeze too, so i don't think that's a problem. > > > > > Well, the amd64-microcode has not cleared NEW yet. How should we proceed? > > > > in my personal opinion, i'd prefere having it integrated into > > firmware-nonfree. but it's not my call but the kernel team to decide. > > Ok, I've looked into firmware-nonfree. > > The intel and amd64 microcode packages are not simple static data-drop > packages (next upload of amd64-microcode will add the required postinst > bits). > > They have to: > > 1. Issue sysfs commands to refresh running microcode With a current kernel, udev will load the firmware just as for any other device. > and update the initramfs when updated/installed. firmware-nonfree can do that (some network drivers need firmware). > 2. Ensure that the microcode module and processor microcode will be added > to the initramfs. Can be done by initramfs-tools. > This doesn't integrate automatically with firmware-nonfree right now, and I > really don't have the time to add support to figure out everything in > firmware-nonfree and add these operations to firmware-nonfree right before > the freeze, [...] Why don't you upload your package somewhere I can look at it? So far I don't see any reason to add a new source package. Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug
Attachment:
signature.asc
Description: This is a digitally signed message part