retitle 513973 RFP: b43-asm -- assembler and disassembler for Broadcom BCM43xx firmware retitle 513974 RFP: openfwwf -- Open Firmware for Broadcom b43 wlan devices thanks
Hi
On Wednesday 16 February 2011, xavier wrote:
> Since last time, is there any news about openfwwf in debian? With the
> new squeeze, will it be included in sid? A free package should be
> better than nnon-free broadcom-sta, don't you think?
[ Most of the talk below is about OpenFWWF and doesn't apply to
b43-asm, but the only reason to upload b43-asm is in order to build
OpenFWWF - so it's closely related ]
The big problem I see with OpenFWWF, is upstream maintenance, which
appears to be almost dead. One of the main reasons why I didn't push
for getting it uploaded to Debian yet, is "We received reports about
firmware problems with PCMCIA 4306/18 based cards. We are working to
support them." [1], [2], which was acknowledged as a bug at 2009-05-08,
but nothing has happened since... (and no, the Maranello firmware
release is not a solution and doesn't work for "normal" IEEE802.11
operations and is neither usable by an unpatched linux kernel). While
I personally haven't noticed these issues on my BCM4306/3 based
devices (also in actual use as an access point) in practice and have
gotten good feedback for bcm4311/1 (just like with some light testing
on BCM4318/2), there have been according bugreports on the b43 mailing
list and b43 upstream still doesn't accept bugreports in combination
with OpenFWWF because of these known bugs.
This means for uploading OpenFWWF to Debian, that the potential
maintainer has to effectively become upstream in order to react to
inevitable bugreports, which is everything but simple for OpenFWWF.
Yes, OpenFWWF really is "the preferred form of modification" and it's
commented exceptionally well. Yes, there are high level design
specifications on [1] and in depth reverse engineering specifications
at [3]. But the problem remains that actually changing this firmware is
everything but easy and requires an intimate familiarity with those
specifications and access to spectrum analyzers and related gear, to
retain a minium of conformance testing - which is rather important for
transmitting devices.
At this moment, I unfortunately don't feel qualified to take that
burden without an active upstream, who could take a look at eventual
(and known buggy) issues. Therefore I can't be a responsible maintainer
for OpenFWWF in Debian. b43-asm is actively maintained, but my only
reason for maintaining b43-asm is in order to build OpenFWWF, so it
doesn't make a lot of sense to upload it without OpenFWWF on the
horizon.
The packaging for both b43-asm [4] and OpenFWWF [5] themselves should
be in a good state. OpenFWWF is up to date and the packaging should be
basically complete, b43-asm just needs a few minutes of work to add a
"get-orig-source" target (it's maintained solely in git and there are
no upstream tarballs or formal releases) and to update it to current
git HEAD. Given that I'm successfully using OpenFWWF myself, I will
continue to maintain the packaging for both packages and would be
willing to co-maintain both in Debian, but I simply can't effectively
provide upstream maintenance for OpenFWWF - which prevents me from
being a responsible maintainer for it in Debian. It's a pity, but I
can't upload anything with known bugs - even if I've never noticed them
myself - to Debian.
Regards
Stefan Lippers-Hollmann
[1] http://www.ing.unibs.it/~openfwwf/
[2] http://www.spinics.net/lists/linux-wireless/msg57293.html
[3] http://bcm-v4.sipsolutions.net
[4] Vcs-Svn: svn://svn.berlios.de/fullstory/b43-asm/trunk
Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/b43-asm/trunk
[5] Vcs-Svn: svn://svn.berlios.de/fullstory/openfwwf/trunk
Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/openfwwf/trunk/
signature.asc
Description: This is a digitally signed message part.
