Spec URL: http://www.tuxdriver.com/download/b43-firmware.spec SRPM URL: http://www.tuxdriver.com/download/b43-firmware-351.126-3.src.rpm Description: This package contains the V4 firmware required to use the b43 driver with most wireless cores from Broadcom.
Please use these links (once the big stuff gets uploaded): http://linville.fedorapeople.org/b43-firmware.spec http://linville.fedorapeople.org/b43-firmware-351.126-3.src.rpm
Shipping a 200+MB SRPM for this doesn't sound too good to me; including a link to the full tarball along with a SourceX script in it that extracts and repackages only the needed bits from the tarball and shipping its result would be better, for example: http://scop.fedorapeople.org/patches/b43/b43-firmware.spec.patch http://scop.fedorapeople.org/patches/b43/b43-firmware-repackage.sh
The included COPYING file says: ... The source archive was specifically provided by Linksys in order to fulfill obligations arising from distribution of software licensed under the GPL and other open source licenses. Given that fact, it is reasonable to infer that redistribution of the archive itself and the contents of that archive is accepted by Linksys, Broadcom, and any other copyright holders. ... That being said, the files used by this package *aren't* source files; they are binary objects. Hence, I'm not sure we can make the argument that they're releasing these binary objects on these terms, as releasing binary objects to satisfy the GPL doesn't really make sense. Marking as blocking FE-LEGAL.
MUST: - Package meets naming and packaging guidelines - OK - Spec file matches base package name. - OK - Spec has consistant macro usage. - OK - Meets Packaging Guidelines. - *** *** The 'version' used is odd, and I don't see where it's coming from. - License - *** *** If FE-Legal is OK, I suppose it's OK. We're sort of inferring the terms, though. - License field in spec matches - OK - License file included in package - OK - Spec in American English - OK - Spec is legible. - OK - Sources match upstream md5sum: ... download timed out. - Package needs ExcludeArch - *** *** Might need Exclude/ExclusiveArch to match where driver is built. Is this built on all arches? - BuildRequires correct - OK - Spec handles locales/find_lang - N/A - Package has %defattr and permissions on files is good. - OK - Package has a correct %clean section. - OK - Package has correct buildroot - OK - Package is code or permissible content. - OK - Doc subpackage needed/used. - N/A - Packages %doc files don't affect runtime. - OK - Package compiles and builds on at least one arch. - OK (noarch) - Package has no duplicate files in %files. - OK - Package doesn't own any directories other packages own.- OK - Package owns all the directories it creates. - OK - No rpmlint output. - OK - final provides and requires are sane: SHOULD Items: - Should build in mock. - OK (tested i386) - Should build on all supported archs - OK (noarch) - Should function as described. - didn't test, no hardware - Should have sane scriptlets. - N/A - Should have dist tag - N/A - Should package latest version - ... what is latest?
The firmware version is reported by b43 when the driver loads it. Is ExclusiveArch appropriate for a noarch package? Re: latest -- the driver needs a specific version of the firmware.
(In reply to comment #7) > The firmware version is reported by b43legacy when the driver loads it. OK. Any way to determine that from the outside? strings? > Is ExclusiveArch appropriate for a noarch package? We use ExcludeArch to avoid shipping firmware packages on arches where they don't make sense. For example, iwl3945-firmware has: # This is so that the noarch packages don't appear for these archs ExcludeArch: ppc ppc64 > Re: latest -- the driver needs a specific version of the firmware. OK.
Any news?
(In reply to comment #8) > (In reply to comment #7) > > Is ExclusiveArch appropriate for a noarch package? > > We use ExcludeArch to avoid shipping firmware packages on arches where they > don't make sense. For example, iwl3945-firmware has: > > # This is so that the noarch packages don't appear for these archs > ExcludeArch: ppc ppc64 The b43{,legacy} driver is available for ppc, ppc64, sparc64, alpha...you can get a Broadcom chipset into anything with PCI. Why should we limit where this package is available? With hardlinks it's not really any more burden to mirrors. (Great, now I need to go see if it actually works in any of those...)
Well it builds on x86_64, passes rpmlint. Looking at what it does, I have no reason to believe it won't work on my laptop. I tend to like Ville's solution better than distributing a 200MB src rpm. Too bad modification is not permitted, or we could just redistribute the 805KB wl_apsta.o firmware. Have you contacted Linksys about this?
Tested and confirmed working on Fedora 9 i686 Preview Live (USB). I booted, installed the rpm and reloaded the b43 module. Checked with WPA2 PSK on HP/Compaq nc6320 with Broadcom WLAN.
Created attachment 305865 [details] wlano1 error Am getting a few errors with this rpm -qa b43\* b43-fwcutter-011-3.fc9.i386
Created attachment 305866 [details] /var/log/messages (snipped)
Frank, this isn't really the right bug for that. This has to do with a completely different package. In fact this one should probably just be closed, as this package is not likely to ever be accepted into Fedora... It looks like do not have a successful firmware extraction on your box. Where did you get the firmware you are using?