Bug #: 2549
Summary: Review request: broadcom-wl-bcm43142 - Common files
for Broadcom 802.11 STA driver for BCM43142 devices
Product: Package Reviews
Component: Review Request
This package contains the license, copyright and configuration files for the
Broadcom 802.11 Linux STA Driver for WiFi, a Linux device driver for use with
Broadcom's BCM43142-based hardware also known as Broadcom bcm4365 or Dell 1704
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Package not eligible to be included in Fedora as it contains some
As the maintainer of the actual broadcom-wl package for rpmfusion, a user asked
me if I could provide the last broadcom wireless drivers for BCM43142-based
hardware, because this chipset is not driven by the actual package. He pointed
me to the actual maintainer site of this package for Debian, and these packages
(wl-bcm43142-kmod review request will follow) are largely inspired from this
The original package was shipped with Ubuntu's Dell laptop, but as far as I
know (digging the Web for 2 days) neither Broadcom or Dell provided on their
websites any sources for this driver. The only source cited by the Debian
packager is actually this site:
According to message #60 in this thread
, Broadcom will not
update the official Broadcom STA driver (aka 220.127.116.11) as the new one was a
Dell/Ubuntu specific only.
While preparing these packages, I had to make some choices and I wonder if
someone could review and comment them if needed:
These new package are x86_64 architecture only. Broadcom/Dell didn't provided
any binary library for i386 (32 bits) platform. I had to make these packages
x86_64 platform only by adding a "ExclusiveArch: x86_64" directive in the SPEC
file, and adding checking in the %prep section of this file too. Is this
As this new driver doesn't work with some older Broadcom chipset (mine is
bcm4313 and doesn't work with it for example) that still work correctly with
18.104.22.168 driver, I didn't choice to use conflict directive in the SPEC
file. If one has a new chipset in his laptop and plug-in an old one via USB
port the problem will be unsolvable. I preferred to rename the new build module
with a different name to let users deal with there configuration more smoothly
(I hope that modifying some udev rules might be necessary to get them working).
So the new build module was rename from wl.ko to wl_bcm43142.ko at build time.
Is this correct, or am I wrong?
As stated by all the users owning such laptop and wanting to upgrade their
original Ubuntu 11.10 to the last 12.04 or 12.10, this chipset is hybrid but
actually no bluetooth is working. Some efforts are made by Ubuntu developers to
get it working, but for the moment this part of the chipset is not supported
What is the best thing to do to inform users of such a limitation in this
After all, is it worth packaging this driver?
I can provide rawhide SPEC and SRPMS files if needed.
I plan to make it available for F-17 if accepted.
Same request made for the wl-bcm43142-kmod package.
As I do not own myself such a device, I would not be able to test new packages
as they would be build. Are there any volunteers to achieve this task?
Last question: as I'm already a rpmfusion packager, but not so experienced, do
I need a sponsor?
Thanks in advance for your comments.
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.