It would be nice for the `firmware-b43-installer` package to include a
utility for producing a "proper" firmware package, instead of installing
the files into /lib/firmware.  I'm thinking something along the lines of
the ancient "qmail-src" (and other *-src packages), where you installed
that package and it would invoke the build and packaging tools for you.

This is better if you're installing onto lots of machines.  Rather than
having to download zillions of times and rely on your Internet
connection; you download once, build the package and then install THAT
onto your target machines.  This is also less of a headache during
upgrades.

Might also be handy to have an install script in /usr/sbin, instead of
needing to invoke the postinst script out of /var/lib/dpkg/info.

tags 819136 + patch
quit

I managed to create a series of changes to implement this, so sending to
you in the hope of getting them adopted into Debian.  Note, these are
against version 018-2 since you haven't pushed 019-2 out to your public
git server.

In the process of attacking #819136, several other bugs get fixed since
they're rather desireable to have fixed, notably:

756664
760813 (partial workaround only)
810161
819129

Hopefully this is broken into a sufficient number of smaller patches to
suit your taste.  A few notes:

Patch #0002 is attacking a very minor unreported bug, mainly the removal
of the temporary directory is problematic when the process is in it.
Patch #0003 is attacking the issue I was wondering whether or not to have
a report separate from #756664.  Simply these commands are unchecked and
you can have poor results without warnings.
Patch #0004 fixes bug #756664, nothing else needs to be said (SHA512).
Patch #0007 fixes bug #819136 (this report).  With the pieces in place,
there is a firmware-b43-buildpackage script that generates a package that
can be installed by `dpkg`.  The one concern is the resultant package
gets broken by firmware-b43-installer up to 019-2.  This is part of the
reason for #0006, it allows the two to play nicely.
Patch #0008 partially fixes #760813 by including "4716" in the detected
chips.  The 802.11 isn't on that chip, but should always appear on an
internal PCI bus.  The other part is to simply update all the spots where
the chips are detected.
Patch #0009 is bug #810161, nothing else to say.  Patch #0001 makes this
(and future updates) simpler though.
Patch #0010 is a minor script optimization that was staring me in the
face and I couldn't ignore it.

Updating the patches I'd submitted to bug #819136.  What had been patch
0005 is now part of bug #819705 as patch 0001, and is attached to that
bug.  I'm attaching 0002-0010 to this message/bug.

Just found I'd goofed in the last revision.  Updated patches
demonstrating my request attached.

I just skimmed through the patches that the submitter sent and they seem
like a huge improvement over what we have in the current version, while
fixing many bugs and updating the firmware for other cards.

Generating a debian package is the main goal, but the rest of the patches
look very nice and it would be great to have them integrated.

Can we have a new upload of firmware-b43-installer with these changes?


Thanks,

Rogério.

I just skimmed through the patches that the submitter sent and they seem
like a huge improvement over what we have in the current version, while
fixing many bugs and updating the firmware for other cards.

Generating a debian package is the main goal, but the rest of the patches
look very nice and it would be great to have them integrated.

Can we have a new upload of firmware-b43-installer with these changes?


Thanks,

Rogério.

Guess I should give at least a partial list of the extra bugfixes
included in the #819136 patch series:

#668613 part of patch #0008, simply including a much longer list of the
chips known to successfully driven by this firmware.

#760813 part of patch #0008, doesn't really solve the issue, but provides
a reasonable workaround.  Look for the Ids on the known internal bus.

#756664 part of patch #0005, this requires the package author to
successfully get a clean copy of the tarball, but this greatly increases
the odds of someone else noticing something going wrong.

#810161 part of patch #0009, simply update the appropriate magic value.
The precursor is patch #0002 which moves all the magic values to one
section.

#819129 part of patch #0002, simply unpack only the required file and
the use of /tmp is heavily reduced.

Hello,

I was looking at bugs with patchs and saw this one. I believe most of the
patches are obsolete, the only thing that should remain is the part where
you try to generate a separate .deb.

Are we actually allowed to build a .deb and distribute the firmware
directly in a .deb? I haven't checked but I guess that it's "no",
otherwise we would likely ship the firmware ourselves in non-free...

I saw you contributed regularly to the package. What about getting a salsa
account and taking over package maintenance?

In any case, an update on this bug would be appreciated.

Cheers,

Just for the record, this package is now orphaned and in need of
someone to adapt it.  Perhaps it is the way to fix this issue?