Bug 383271 - Review Request: b43-firmware - V4 firmware for Broadcom wireless devices
Review Request: b43-firmware - V4 firmware for Broadcom wireless devices
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-Legal RussianFedoraRemix
  Show dependency treegraph
 
Reported: 2007-11-14 14:56 EST by John W. Linville
Modified: 2014-03-16 23:11 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 08:49:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
wlano1 error (628 bytes, text/plain)
2008-05-18 13:36 EDT, Frank Murphy
no flags Details
/var/log/messages (snipped) (1.34 KB, text/plain)
2008-05-18 13:37 EDT, Frank Murphy
no flags Details

  None (edit)
Description John W. Linville 2007-11-14 14:56:20 EST
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.
Comment 1 John W. Linville 2007-11-14 15:14:54 EST
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
Comment 2 Ville Skyttä 2007-11-14 15:46:30 EST
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
Comment 3 Bill Nottingham 2007-11-14 16:18:43 EST
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.
Comment 5 Bill Nottingham 2007-11-14 16:28:44 EST
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?
Comment 7 John W. Linville 2007-11-14 16:59:03 EST
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.
Comment 8 Bill Nottingham 2007-11-14 17:07:57 EST
(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.
Comment 9 Peter Lemenkov 2007-12-12 06:25:39 EST
Any news?
Comment 10 Jima 2007-12-12 14:42:56 EST
(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...)
Comment 11 Henry Kroll 2008-04-17 15:24:37 EDT
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?
Comment 12 Henning Norén 2008-04-19 17:32:10 EDT
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.
Comment 13 Frank Murphy 2008-05-18 13:36:45 EDT
Created attachment 305865 [details]
wlano1 error

Am getting a few errors with this rpm -qa b43\*
b43-fwcutter-011-3.fc9.i386
Comment 14 Frank Murphy 2008-05-18 13:37:58 EDT
Created attachment 305866 [details]
/var/log/messages (snipped)
Comment 15 John W. Linville 2008-05-19 08:49:24 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.