Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sun, 24 Jun 2012, Ben Hutchings wrote:
> On Sun, 2012-06-24 at 12:21 -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > > > The package template system currently only supports one optional
> > > > > postinst action, but it wouldn't be hard to extend to add others.
> >
> > Ok, I tried to ship the microcode for amd processors using firmware-nonfree.
> > There are a few problems:
> >
> > 1. firmware-nonfree seems to be very tightly tied to module names. We'd
> > need to join all microcode upstream packages under "microcode" which is the
> > module name. This is not a good thing IMO.
>
> No such tying is required.
Uh? I failed at attempting it, it aborts complaining that it cannot find
something in (base, microcode), (base, cpu-x86-amd), etc. And it only runs
after I install the -support package, as it wants python modules that are in
there.
> > 2. firmware-nonfree simply doesn't want to work without MODULE_FIRMWARE
> > support in the official kernel-image, that somehow migrates to magic binary
> > dumps in the -support package for that image, that gets used by
> > firmware-nonfree to generate its own metadata. Yikes!
>
> I don't know where you get this idea, as there is no such information in
> linux-support-<version>. The set of files to be included in
> firmware-foo is specified by foo/defines.
It was not enough to get it to run, but maybe I did something wrong. Help
is appreciated (or a pointer to the documentation for how to work with
firmware-nonfree).
> > 3. firmware-nonfree _really_ needs a README.source :-)
>
> Yeah.
>
> > So, I am stumped. Assuming it is simply not a matter of me not groking how
> > to shoehorn firmware-nonfree to do what I need, at this point, it either
> > means we need some changes to firmware-nonfree so that it can ALSO work as a
> > generic multi-upstream dumping ground for stuff that does not benefit from
> > (or actively gets harmed by) the automation it currently does, or that we
> > should have separate source packages for such stuff, and leave
> > firmware-nonfree for regular firmware that fits well with the automation it
> > currently implements.
> >
> > Any ideas?
>
> I think it might be better in the long term to split up firmware-nonfree
> and provide a dh_firmware used by multiple source packages.
>
> But I think you are seeing obstacles that don't exist.
Other than the lack of a README.source to avoid it? Maybe. But at the end
of the day, the fact is that I still don't know how to get firmware-nonfree
to do what I need it to :-(
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: