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

On Fri, 22 Jun 2012, Ben Hutchings wrote:
> 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.

Yes, it will. At boot. And only if the driver is modular. And only if
something specifically modprobes microcode, because it has no autoloading
support in kernel 3.2 and earlier (I think that support was to land in 3.5,
but it might already have landed in 3.4).

So, Microcode needs to be refreshed when you upgrade the data files, and
also when the driver is not modular (at least last time I tested it in a 3.0
kernel for Intel), and that requires postinst and initramfs specific magic
(quite a lot for Intel, nearly none for AMD).

Backporting the autoload code is not straigthforward. Adding
MODULE_FIRMWARE() to the amd microcode driver is trivial and I think we
should do it anyway. MODULE_FIRMWARE() is currently impossible for Intel
and unless we want to possibly deviate from upstream, there is no way we can
fix that right now.

> > and update the initramfs when updated/installed.
>
> firmware-nonfree can do that (some network drivers need firmware).

Is it amicable to special postinst code? If it is, it can take care of
amd64-microcode.

> > 2. Ensure that the microcode module and processor microcode will be added
> > to the initramfs.
>
> Can be done by initramfs-tools.

Yes, it can. But initramfs-tools has no specific code other than some NFS
stuff, so we would probably benefit from a firmware-cpu-tools or whatever,
which could drop the initramfs helper, dpkg triggers and helper scripts to
get things done for both amd and intel microcode.

I'd rather not duplicate this code for Intel and AMD, so it would need to
end up in a -common/-util package of some sort (or in intramfs-tools
directly, but I don't think that's a good idea): soon we will also need a
new type of hook to piggyback the microcode using a initramfs-like
container, either to the initramfs itself, or to the kernel image (I am not
clear on that detail yet), and the microcode will be loaded on the BSP very
very early, and on other cores BEFORE they're activated.

This functionality has not landed in the kernel yet, but since we do know it
is coming, we better make sure we will be able to take advantage of it
without too much packaging rework. A -common/-util package is probably best
for that, and I intend to upload something to that effort this weekend.

> > 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.

Here:
http://people.debian.org/~hmh/microcode/

as one cannot download from the NEW queue, where it is currently.

The -1 packages are lacking the postinst snippet to refresh microcode, as
that area was in flux over the last few days and I was actively
participating on the thread in LKML to make sure we got something sane for
userspace as the result.

I was going to add the code to -2, now that the new sysfs nodes are set. It
is in my laptop at home, and I can send it in later today.

--
"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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120622190334.GA32380@khazad-dum.debian.net">http://lists.debian.org/20120622190334.GA32380@khazad-dum.debian.net

On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > 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.
>
> Yes, it will. At boot. And only if the driver is modular. And only if
> something specifically modprobes microcode, because it has no autoloading
> support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> but it might already have landed in 3.4).
>
> So, Microcode needs to be refreshed when you upgrade the data files, and
> also when the driver is not modular (at least last time I tested it in a 3.0
> kernel for Intel), and that requires postinst and initramfs specific magic
> (quite a lot for Intel, nearly none for AMD).

> Backporting the autoload code is not straigthforward.

I backported the general support for x86 CPU module autoloading in
3.2.21-1. The rest should be easy, shouldn't it?

> Adding
> MODULE_FIRMWARE() to the amd microcode driver is trivial and I think we
> should do it anyway. MODULE_FIRMWARE() is currently impossible for Intel
> and unless we want to possibly deviate from upstream, there is no way we can
> fix that right now.

OK.

> > > and update the initramfs when updated/installed.
> >
> > firmware-nonfree can do that (some network drivers need firmware).
>
> Is it amicable to special postinst code? If it is, it can take care of
> amd64-microcode.

The package template system currently only supports one optional
postinst action, but it wouldn't be hard to extend to add others.

> > > 2. Ensure that the microcode module and processor microcode will be added
> > > to the initramfs.
> >
> > Can be done by initramfs-tools.
>
> Yes, it can. But initramfs-tools has no specific code other than some NFS
> stuff, so we would probably benefit from a firmware-cpu-tools or whatever,
> which could drop the initramfs helper, dpkg triggers and helper scripts to
> get things done for both amd and intel microcode.
>
> I'd rather not duplicate this code for Intel and AMD, so it would need to
> end up in a -common/-util package of some sort (or in intramfs-tools
> directly, but I don't think that's a good idea): soon we will also need a
> new type of hook to piggyback the microcode using a initramfs-like
> container, either to the initramfs itself, or to the kernel image (I am not
> clear on that detail yet), and the microcode will be loaded on the BSP very
> very early, and on other cores BEFORE they're activated.

Why is this 'needed'; are future processors expected to be particularly
buggy?

Named firmware files can generally be included in the kernel image, but
of course we won't do that in official Debian packages.

> This functionality has not landed in the kernel yet, but since we do know it
> is coming, we better make sure we will be able to take advantage of it
> without too much packaging rework. A -common/-util package is probably best
> for that, and I intend to upload something to that effort this weekend.
>
> > > 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.
>
> Here:
> http://people.debian.org/~hmh/microcode/
>
> as one cannot download from the NEW queue, where it is currently.

I know, that's why I asked. Thanks.

Ben.

> The -1 packages are lacking the postinst snippet to refresh microcode, as
> that area was in flux over the last few days and I was actively
> participating on the thread in LKML to make sure we got something sane for
> userspace as the result.
>
> I was going to add the code to -2, now that the new sysfs nodes are set. It
> is in my laptop at home, and I can send it in later today.


--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

On Sat, 23 Jun 2012, Ben Hutchings wrote:
> On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > > > 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.
> >
> > Yes, it will. At boot. And only if the driver is modular. And only if
> > something specifically modprobes microcode, because it has no autoloading
> > support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> > but it might already have landed in 3.4).
> >
> > So, Microcode needs to be refreshed when you upgrade the data files, and
> > also when the driver is not modular (at least last time I tested it in a 3.0
> > kernel for Intel), and that requires postinst and initramfs specific magic
> > (quite a lot for Intel, nearly none for AMD).
>
> > Backporting the autoload code is not straigthforward.
>
> I backported the general support for x86 CPU module autoloading in
> 3.2.21-1. The rest should be easy, shouldn't it?

Probably yes.

However, the microcode core also went through a large code change
because it was ported from half-braindead sysdev to a full blown device.
I am not sure if you can do the autoloading properly without that
conversion, it depends on whether the code in 3.2 generates the required
uevents and sysfs attributes, or not.

Do we have a git tree with the Debian kernel somewhere?

> > > > and update the initramfs when updated/installed.
> > >
> > > firmware-nonfree can do that (some network drivers need firmware).
> >
> > Is it amicable to special postinst code? If it is, it can take care of
> > amd64-microcode.
>
> The package template system currently only supports one optional
> postinst action, but it wouldn't be hard to extend to add others.

Let's see if I can get that to work over the weekend. I will be unable to
do any Debian work next week, which is rather unfortunate given the freeze
deadline.

> > > > 2. Ensure that the microcode module and processor microcode will be added
> > > > to the initramfs.
> > >
> > > Can be done by initramfs-tools.
> >
> > Yes, it can. But initramfs-tools has no specific code other than some NFS
> > stuff, so we would probably benefit from a firmware-cpu-tools or whatever,
> > which could drop the initramfs helper, dpkg triggers and helper scripts to
> > get things done for both amd and intel microcode.
> >
> > I'd rather not duplicate this code for Intel and AMD, so it would need to
> > end up in a -common/-util package of some sort (or in intramfs-tools
> > directly, but I don't think that's a good idea): soon we will also need a
> > new type of hook to piggyback the microcode using a initramfs-like
> > container, either to the initramfs itself, or to the kernel image (I am not
> > clear on that detail yet), and the microcode will be loaded on the BSP very
> > very early, and on other cores BEFORE they're activated.
>
> Why is this 'needed'; are future processors expected to be particularly
> buggy?

A few current ones already are, and there is no reason to believe it
won't happen again in the future. "buggy" here means something the
kernel wants (or cannot afford not to) to test for only once, and
disable functionality if the relevant microcode update is not already
installed in the processor.

Anyway, we will need to update the userspace microcode facilities for
new kernels, as early-init microcode update support should land in 3.6
or 3.7 and will require changes on how it interacts with the initramfs.
I'd rather this was something simple to do for wheezy-stable through
either a stable update, or a backport or a single simple package.

> Named firmware files can generally be included in the kernel image, but
> of course we won't do that in official Debian packages.

It won't go through the firmware interface, that thing is not available
early enough... the microcode update needs to be available during the
bootstrap processor init. So far, it looks like it will be something
initramfs-like that gets either added to the real initramfs or to the
kernel image (I am not sure of the details), and has files with specific
names inside with the relevant data blobs.

Anyway, it will require updated userland to be used to its full
functionality, so I'd prefer to have all userland logic in a single
place that we can update and backport, instead of at least two copies of
it.

I suggest we add a new firmware-x86-cpu-helpers package to handle this.
It can provide an update-processor-microcode script, which
firmware-x86-amd64 and intel-microcode/firmware-x86-intel will call on
postinst.

firmware-x86-cpu-helpers (or whatever we name it) will have initramfs
helpers and any relevant scripts (we need at least one,
"update-processor-microcode").

--
"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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120623024951.GC22572@khazad-dum.debian.net">http://lists.debian.org/20120623024951.GC22572@khazad-dum.debian.net

On Fri, 2012-06-22 at 23:49 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > > On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > > > > 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.
> > >
> > > Yes, it will. At boot. And only if the driver is modular. And only if
> > > something specifically modprobes microcode, because it has no autoloading
> > > support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> > > but it might already have landed in 3.4).
> > >
> > > So, Microcode needs to be refreshed when you upgrade the data files, and
> > > also when the driver is not modular (at least last time I tested it in a 3.0
> > > kernel for Intel), and that requires postinst and initramfs specific magic
> > > (quite a lot for Intel, nearly none for AMD).
> >
> > > Backporting the autoload code is not straigthforward.
> >
> > I backported the general support for x86 CPU module autoloading in
> > 3.2.21-1. The rest should be easy, shouldn't it?
>
> Probably yes.
>
> However, the microcode core also went through a large code change
> because it was ported from half-braindead sysdev to a full blown device.
> I am not sure if you can do the autoloading properly without that
> conversion, it depends on whether the code in 3.2 generates the required
> uevents and sysfs attributes, or not.
>
> Do we have a git tree with the Debian kernel somewhere?

The source package is currently still in svn, but there is a git mirror
of the patched source at
<http://anonscm.debian.org/gitweb/?p=kernel/linux.git>.

> > > > > and update the initramfs when updated/installed.
> > > >
> > > > firmware-nonfree can do that (some network drivers need firmware).
> > >
> > > Is it amicable to special postinst code? If it is, it can take care of
> > > amd64-microcode.
> >
> > The package template system currently only supports one optional
> > postinst action, but it wouldn't be hard to extend to add others.
>
> Let's see if I can get that to work over the weekend. I will be unable to
> do any Debian work next week, which is rather unfortunate given the freeze
> deadline.

It's not a hard deadline for package updates.

[...]
> > Why is this 'needed'; are future processors expected to be particularly
> > buggy?
>
> A few current ones already are, and there is no reason to believe it
> won't happen again in the future. "buggy" here means something the
> kernel wants (or cannot afford not to) to test for only once, and
> disable functionality if the relevant microcode update is not already
> installed in the processor.

Right, good point.

> Anyway, we will need to update the userspace microcode facilities for
> new kernels, as early-init microcode update support should land in 3.6
> or 3.7 and will require changes on how it interacts with the initramfs.
> I'd rather this was something simple to do for wheezy-stable through
> either a stable update, or a backport or a single simple package.
[...]

I don't see why that should be included in wheezy.

Ben.

--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

On Sat, 23 Jun 2012, Ben Hutchings wrote:
> On Fri, 2012-06-22 at 23:49 -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 23 Jun 2012, Ben Hutchings wrote:
> > > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote:
> > > > On Fri, 22 Jun 2012, Ben Hutchings wrote:
> > > > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > > > > > 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.
> > > >
> > > > Yes, it will. At boot. And only if the driver is modular. And only if
> > > > something specifically modprobes microcode, because it has no autoloading
> > > > support in kernel 3.2 and earlier (I think that support was to land in 3.5,
> > > > but it might already have landed in 3.4).
> > > >
> > > > So, Microcode needs to be refreshed when you upgrade the data files, and
> > > > also when the driver is not modular (at least last time I tested it in a 3.0
> > > > kernel for Intel), and that requires postinst and initramfs specific magic
> > > > (quite a lot for Intel, nearly none for AMD).
> > >
> > > > Backporting the autoload code is not straigthforward.
> > >
> > > I backported the general support for x86 CPU module autoloading in
> > > 3.2.21-1. The rest should be easy, shouldn't it?
> >
> > Probably yes.
> >
> > However, the microcode core also went through a large code change
> > because it was ported from half-braindead sysdev to a full blown device.
> > I am not sure if you can do the autoloading properly without that
> > conversion, it depends on whether the code in 3.2 generates the required
> > uevents and sysfs attributes, or not.
> >
> > Do we have a git tree with the Debian kernel somewhere?
>
> The source package is currently still in svn, but there is a git mirror
> of the patched source at
> <http://anonscm.debian.org/gitweb/?p=kernel/linux.git>.
>
> > > > > > and update the initramfs when updated/installed.
> > > > >
> > > > > firmware-nonfree can do that (some network drivers need firmware).
> > > >
> > > > Is it amicable to special postinst code? If it is, it can take care of
> > > > amd64-microcode.
> > >
> > > The package template system currently only supports one optional
> > > postinst action, but it wouldn't be hard to extend to add others.
> >
> > Let's see if I can get that to work over the weekend. I will be unable to
> > do any Debian work next week, which is rather unfortunate given the freeze
> > deadline.
>
> It's not a hard deadline for package updates.
>
> [...]
> > > Why is this 'needed'; are future processors expected to be particularly
> > > buggy?
> >
> > A few current ones already are, and there is no reason to believe it
> > won't happen again in the future. "buggy" here means something the
> > kernel wants (or cannot afford not to) to test for only once, and
> > disable functionality if the relevant microcode update is not already
> > installed in the processor.
>
> Right, good point.
>
> > Anyway, we will need to update the userspace microcode facilities for
> > new kernels, as early-init microcode update support should land in 3.6
> > or 3.7 and will require changes on how it interacts with the initramfs.
> > I'd rather this was something simple to do for wheezy-stable through
> > either a stable update, or a backport or a single simple package.
> [...]
>
> I don't see why that should be included in wheezy.

Maybe as a backport at first. People do like to use more recent kernels
than the stable one with stable userspace... and it would be useful for
wheezy-and-a-half if it comes to happen.

--
"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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120623160840.GB9891@khazad-dum.debian.net">http://lists.debian.org/20120623160840.GB9891@khazad-dum.debian.net

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.

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!

3. firmware-nonfree _really_ needs a README.source :-)

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?

--
"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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624152154.GE24236@khazad-dum.debian.net">http://lists.debian.org/20120624152154.GE24236@khazad-dum.debian.net

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.

> 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.

> 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.

Ben.

--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624160531.GA3093@khazad-dum.debian.net">http://lists.debian.org/20120624160531.GA3093@khazad-dum.debian.net