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/
Attachment:
signature.asc
Description: This is a digitally signed message part.