4:02 a.m.
Anyone working on a kmod package for the semi-open-source Broadcom
driver?
http://www.broadcom.com/support/802.11/linux_sta.php
I recently acquired some hardware that theoretically will work with it
(though rumor has it ndiswrapper may still work better/allow faster
speeds).
I hacked something together rather quickly this evening. Still need to
figure out exactly what the license really is, and how to get the
LICENSE.txt file into the right package (been a while since I've poked
at any kmods), but it builds and packages the important (to me) piece --
the actual kmod...
http://wilsonet.com/jarod/junk/hybrid_wl-kmod-5.10.27.6-1.fc10.src.rpm
Advice and/or news of someone already working on this welcomed...
--
Jarod Wilson
jarod(a)wilsonet.com
9:47 a.m.
On 26.10.2008 05:02, Jarod Wilson wrote:
Anyone working on a kmod package for the semi-open-source Broadcom
driver?
See the following mails that are just a few days old ;-)
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
Chris CCed.
http://www.broadcom.com/support/802.11/linux_sta.php
I recently acquired some hardware that theoretically will work with it
(though rumor has it ndiswrapper may still work better/allow faster
speeds).
I hacked something together rather quickly this evening. Still need to
figure out exactly what the license really is, and how to get the
LICENSE.txt file into the right package (been a while since I've poked
at any kmods), but it builds and packages the important (to me) piece --
the actual kmod...
http://wilsonet.com/jarod/junk/hybrid_wl-kmod-5.10.27.6-1.fc10.src.rpm
Advice and/or news of someone already working on this welcomed...
CU
knurd
10:12 a.m.
Thorsten Leemhuis wrote:
On 26.10.2008 05:02, Jarod Wilson wrote:
> Anyone working on a kmod package for the semi-open-source Broadcom
> driver?
See the following mails that are just a few days old ;-)
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
Chris CCed.
> http://www.broadcom.com/support/802.11/linux_sta.php
>
> I recently acquired some hardware that theoretically will work with it
> (though rumor has it ndiswrapper may still work better/allow faster
> speeds).
>
> I hacked something together rather quickly this evening. Still need to
> figure out exactly what the license really is, and how to get the
> LICENSE.txt file into the right package (been a while since I've poked
> at any kmods), but it builds and packages the important (to me) piece --
> the actual kmod...
>
> http://wilsonet.com/jarod/junk/hybrid_wl-kmod-5.10.27.6-1.fc10.src.rpm
>
> Advice and/or news of someone already working on this welcomed...
CU
knurd
Hey Jarod, you stole my thunder! ;)
Looks like you've done a nice job with this package - do you care to
maintain it or would you mind being joint maintainers? I'm really keen
to get into packaging and this was to be my little project but looks
like you beat me to it!
One thing missing from the package seems to be the patch to fix the
vlanmode issue.
Best
Chris
6:49 p.m.
On Sun, 2008-10-26 at 10:12 +0000, Chris Nolan wrote:
Thorsten Leemhuis wrote:
> On 26.10.2008 05:02, Jarod Wilson wrote:
>> Anyone working on a kmod package for the semi-open-source Broadcom
>> driver?
>
> See the following mails that are just a few days old ;-)
>
> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
>
> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/00...
>
>
> Chris CCed.
D'oh. I saw those mails, but must admit to not reading particularly
close, thus I missed the part about the broadcom driver... :\
>>
http://wilsonet.com/jarod/junk/hybrid_wl-kmod-5.10.27.6-1.fc10.src.rpm
>>
>> Advice and/or news of someone already working on this welcomed...
>
Hey Jarod, you stole my thunder! ;)
Looks like you've done a nice job with this package - do you care to
maintain it or would you mind being joint maintainers? I'm really keen
to get into packaging and this was to be my little project but looks
like you beat me to it!
Heh, sorry 'bout that... Although to be honest, I dunno that I'd suggest
a kmod as a first package for *anyone*, since they consist of so much
black magic... :)
However, I'd be perfectly happy if you wanted to take this on as its
primary maintainer, with me as a co-maintainer.
One thing missing from the package seems to be the patch to fix the
vlanmode issue.
Wasn't aware there was such a patch, by all means, feel free to wedge it
into the srpm.
Nb: performance with this driver is *miserable* with my particular
setup, for reasons I don't yet know... I bought a Dell Studio Hybrid
refurb w/a discount special applied atop it, and in it was this BCM4321
card... The Dell is set up in a wired location, so I yanked the card
out, and transplanted it into my Mac Mini (which the Dell replaced as my
primary mythtv frontend, and is now going upstairs as a secondary
frontend, but needs n wifi to stream hdtv to it).
Now, note that the Mini only has a single antenna wire in it... The card
that was in there (some Ath5k chip) had two antenna posts, but was using
only the one, so I figured I'd give it a go w/the BCM4321, which also
has two posts. Mac OS X happily transfers data at roughly 4.3MB/s with
the BCM4321 using a single antenna, which is more than enough for HDTV
(~2.4MB/s).
Okay, so back to the Linux side and the hybrid_wl driver... I get no
better than ~350KB/s. I presume the driver isn't handling the
single-antenna very well or something, but a buddy of mine who also got
a Dell w/the same card said hybrid_wl performed pretty badly for him too
(the Dell has two antenna internally), but was having stability issues
with ndiswrapper. I've used ndiswrapper w/the BCM432<something> chip in
my AppleTV with excellent results though, so I'm off to try that next...
--jarod
7:09 p.m.
On Sun, 26 Oct 2008, Jarod Wilson wrote:
Okay, so back to the Linux side and the hybrid_wl driver... I get no
better than ~350KB/s. I presume the driver isn't handling the
single-antenna very well or something [...]
This might be an antenna diversity issue, but I do not think this is
likely if you haven't toggled anything in the driver.
Ping some host on your network, if you're experiencing about 50% packet
loss, you're system is using transmit diversity alternating between each
antenna.
If this is not the case, you're not using diversity at all or just
receiver diversity.
If the connection is miserable in general (snr or signal strength) you
might have swapped the aux and the main antenna.
The wlan driver usually offers a toggle to switch diversity on and off,
usually through some sysctl or /sys interface.
The way you're describing your issue though, it sounds as if the driver is
just crap...
regards,
andreas
7:52 p.m.
On Sun, 2008-10-26 at 20:09 +0100, Andreas Thienemann wrote:
On Sun, 26 Oct 2008, Jarod Wilson wrote:
> Okay, so back to the Linux side and the hybrid_wl driver... I get no
> better than ~350KB/s. I presume the driver isn't handling the
> single-antenna very well or something [...]
This might be an antenna diversity issue, but I do not think this is
likely if you haven't toggled anything in the driver.
Ping some host on your network, if you're experiencing about 50% packet
loss, you're system is using transmit diversity alternating between each
antenna.
No packet loss pinging other hosts, or w/other hosts pinging it.
Possibly of note: when pinging out from the host itself, I get fairly
consistent ping times, ranging from sub-millisecond to ~4ms. Pinging
*to* the host, I see wildly varying round-trip times, ranging from
sub-millisecond to 120ms.
If this is not the case, you're not using diversity at all or
just
receiver diversity.
If the connection is miserable in general (snr or signal strength) you
might have swapped the aux and the main antenna.
Don't think that's the case, since under Mac OS X with the exact same
hardware setup, I get about 12x the throughput.
The wlan driver usually offers a toggle to switch diversity on and
off,
usually through some sysctl or /sys interface.
Nothing in /sys that I can see on brief inspection, haven't looked at
the code itself yet.
The way you're describing your issue though, it sounds as if the
driver is
just crap...
That seems the most likely to me thus far... :)
ndiswrapper testing Coming Soon...
--
Jarod Wilson
jarod(a)wilsonet.com
10:21 p.m.
Jarod Wilson wrote:
Heh, sorry 'bout that... Although to be honest, I dunno that I'd suggest
a kmod as a first package for *anyone*, since they consist of so much
black magic... :)
However, I'd be perfectly happy if you wanted to take this on as its
primary maintainer, with me as a co-maintainer.
Fair point about a kmod not being an ideal place to start! I've tried to
read a fair bit about kmodtool and packaging kmods but clearly my
understanding is still rather limited. However I felt it was important
to start with a package that I actually use on a day-to-day basis so
that I'm in a good position to follow the development and
find/apply/create new patches.
I'd be delighted to have you as a co-maintainer - it would be great to
have someone to learn from and help answer any questions or problems I
come across!
> One thing missing from the package seems to be the patch to fix the
> vlanmode issue.
>
Wasn't aware there was such a patch, by all means, feel free to wedge it
into the srpm.
I'll do that, and once I've taken a look through the spec file and done
some testing I'll submit it for review.
Okay, so back to the Linux side and the hybrid_wl driver... I get no
better than ~350KB/s. I presume the driver isn't handling the
single-antenna very well or something, but a buddy of mine who also got
a Dell w/the same card said hybrid_wl performed pretty badly for him too
(the Dell has two antenna internally), but was having stability issues
with ndiswrapper. I've used ndiswrapper w/the BCM432<something> chip in
my AppleTV with excellent results though, so I'm off to try that next...
Hmmm... I have read very varied reports on this driver - some say it is
fast and others report poor performance - I am guessing that it could be
dependent on the specific chipset but I'm not sure. I'll try to collect
some info and see whether there are any patches in the wild that improve
performance. I am not in a position to really test the speeds since I
only use my wireless for broadband so the speed isn't really an issue.
For me the best thing about this driver is that it works flawlessly with
NetworkManager whereas the ndiswrapper/windows driver combo was badly
broken when used with WPA/WPA2 encryption and NetworkManager even though
it was fine when using wpa_supplicant scripts alone to connect (FWIW
I've got a 4328 chipset on x86_64).
Best
Chris
2:57 a.m.
On Sun, 2008-10-26 at 22:21 +0000, Chris Nolan wrote:
Jarod Wilson wrote:
>
> Heh, sorry 'bout that... Although to be honest, I dunno that I'd suggest
> a kmod as a first package for *anyone*, since they consist of so much
> black magic... :)
>
> However, I'd be perfectly happy if you wanted to take this on as its
> primary maintainer, with me as a co-maintainer.
>
>
Fair point about a kmod not being an ideal place to start! I've tried to
read a fair bit about kmodtool and packaging kmods but clearly my
understanding is still rather limited. However I felt it was important
to start with a package that I actually use on a day-to-day basis so
that I'm in a good position to follow the development and
find/apply/create new patches.
I'd be delighted to have you as a co-maintainer - it would be great to
have someone to learn from and help answer any questions or problems I
come across!
Works for me! :)
> Okay, so back to the Linux side and the hybrid_wl driver... I
get no
> better than ~350KB/s. I presume the driver isn't handling the
> single-antenna very well or something, but a buddy of mine who also got
> a Dell w/the same card said hybrid_wl performed pretty badly for him too
> (the Dell has two antenna internally), but was having stability issues
> with ndiswrapper. I've used ndiswrapper w/the BCM432<something> chip in
> my AppleTV with excellent results though, so I'm off to try that next...
Used what I believe were the same bits I used on the AppleTV, and the
performance was even worse than w/hybrid_wl, and ultimately, the
connection completely died. Need to try with another (newer) driver (the
one Dell actually published for the card).
Hmmm... I have read very varied reports on this driver - some say it
is
fast and others report poor performance - I am guessing that it could be
dependent on the specific chipset but I'm not sure.
I'd lean that way too. Dunno if kernel version could be pertinent
(latest rawhide here).
I'll try to collect
some info and see whether there are any patches in the wild that improve
performance. I am not in a position to really test the speeds since I
only use my wireless for broadband so the speed isn't really an issue.
For me the best thing about this driver is that it works flawlessly with
NetworkManager whereas the ndiswrapper/windows driver combo was badly
broken when used with WPA/WPA2 encryption and NetworkManager even though
it was fine when using wpa_supplicant scripts alone to connect
Huh. ndiswrapper worked just fine with WPA2 and NetworkManager for me,
both on the AppleTV and on the Mini ('tis how I connected before the
connection went belly-up).
(FWIW I've got a 4328 chipset on x86_64).
No you don't. :)
lspci lies, someone screwed up the name for device id 4328. The 4321 and
4322 typically sit behind a bridge that has device id 4328, or something
like that, there isn't actually a BCM4328. I believe the bridge is
what's driven by the ssb driver.
--
Jarod Wilson
jarod(a)wilsonet.com
10:27 a.m.
Jarod Wilson wrote:
Used what I believe were the same bits I used on the AppleTV, and
the
performance was even worse than w/hybrid_wl, and ultimately, the
connection completely died. Need to try with another (newer) driver (the
one Dell actually published for the card).
[...]
I'd lean that way too. Dunno if kernel version could be pertinent
(latest rawhide here).
Using latest F9 stable here but as I said, not really in a position to
test throughput speed, unless you know of any tools that may be of use?
Huh. ndiswrapper worked just fine with WPA2 and NetworkManager for
me,
both on the AppleTV and on the Mini ('tis how I connected before the
connection went belly-up).
This doesn't surprise me, I know of other people that have seemingly the
exact same setup as me and NM/ndiswrapper/WPA works fine for them. But
for me, on both F8 and F9 through all kernel versions and with fresh
installs of everything I could never consistently connect to WPA networks.
> (FWIW I've got a 4328 chipset on x86_64).
>
No you don't. :)
lspci lies, someone screwed up the name for device id 4328. The 4321 and
4322 typically sit behind a bridge that has device id 4328, or something
like that, there isn't actually a BCM4328. I believe the bridge is
what's driven by the ssb driver.
Thanks thats good to know and clears up a lot of confusion! Any idea how
I can probe what the actual chipset is? Apple's System Profiler
unhelpfully refers to it as "Broadcom BCM43xx 1.0 (4.170.46.11)"
Best
Chris
2:44 p.m.
On Mon, 2008-10-27 at 10:27 +0000, Chris Nolan wrote:
>> (FWIW I've got a 4328 chipset on x86_64).
>>
>
> No you don't. :)
>
> lspci lies, someone screwed up the name for device id 4328. The 4321
and
> 4322 typically sit behind a bridge that has device id 4328, or
something
> like that, there isn't actually a BCM4328. I believe the bridge is
> what's driven by the ssb driver.
Thanks thats good to know and clears up a lot of confusion! Any idea
how I can probe what the actual chipset is? Apple's System Profiler
unhelpfully refers to it as "Broadcom BCM43xx 1.0 (4.170.46.11)"
Under linux, I vaguely recall seeing some dmesg spew from the b43 driver
upon loading that it had found an unknown BCM432x chip... Can't recall
if it said anything more specific... Under Mac OS X, I'd look at its
dmesg output, and see if there's anything more telling to be had there.
Otherwise, the only sure-fire way I know of is to crack open the case
and look at the card itself (which is the only way I know absolutely for
sure right now that the card I put into my mini from the dell is a
BCM4321).
--
Jarod Wilson
jarod(a)wilsonet.com
12:22 a.m.
Jarod, Thorsten et al, couple of questions for you guys...
I've got so far as including the required license file in a (required)
-common package, and made a few fixes to make rpmlint happy. I also
included another patch to fix the vlanmode issue. Now I have a couple of
questions:
1) What should the package be called? I'm not thrilled with
"hybrid_wl-kmod" because I don't think it is descriptive to the
end-user. I suggest "broadcom-hybrid-wl-kmod" which keeps in tune with
an unofficial SUSE package and also seems to be more descriptive. Are
there any guidelines for this? Any suggestions?
2) The SRPM builds the following packages:
kmod-broadcom-hybrid-wl-5.10.27.6-2.fc9.x86_64.rpm
kmod-broadcom-hybrid-wl-2.6.26.6-79.fc9.x86_64-5.10.27.6-2.fc9.x86_64.rpm
broadcom-hybrid-wl-kmod-common-5.10.27.6-2.fc9.x86_64.rpm
broadcom-hybrid-wl-kmod-debuginfo-5.10.27.6-2.fc9.x86_64.rpm
I don't fully understand the first two - the second one contains the
actual kernel module but
a) why is the name of the second package formed like it is - I am
supposing that it is because it is built for a specific kernel version?
b) what is the first package for? it is empty!
Thanks
Chris
3:03 a.m.
On Mon, 2008-10-27 at 00:22 +0000, Chris Nolan wrote:
Jarod, Thorsten et al, couple of questions for you guys...
I've got so far as including the required license file in a (required)
-common package, and made a few fixes to make rpmlint happy. I also
included another patch to fix the vlanmode issue.
Cool.
Now I have a couple of questions:
1) What should the package be called? I'm not thrilled with
"hybrid_wl-kmod" because I don't think it is descriptive to the
end-user. I suggest "broadcom-hybrid-wl-kmod" which keeps in tune with
an unofficial SUSE package and also seems to be more descriptive. Are
there any guidelines for this? Any suggestions?
I actually started out calling it that as well, then flipped back and
forth a time or two. I think either one is fine. Shorter is good, but so
is descriptive.
2) The SRPM builds the following packages:
kmod-broadcom-hybrid-wl-5.10.27.6-2.fc9.x86_64.rpm
kmod-broadcom-hybrid-wl-2.6.26.6-79.fc9.x86_64-5.10.27.6-2.fc9.x86_64.rpm
broadcom-hybrid-wl-kmod-common-5.10.27.6-2.fc9.x86_64.rpm
broadcom-hybrid-wl-kmod-debuginfo-5.10.27.6-2.fc9.x86_64.rpm
I don't fully understand the first two - the second one contains the
actual kernel module but
a) why is the name of the second package formed like it is - I am
supposing that it is because it is built for a specific kernel version?
Correct. The first is the base package. People say 'yum install
kmod-broadcom-hybrid_wl', and get that package, and the latest
kernel-specific one, which is what the second package is. The
2.6.26.6-79.fc9.x86_64 in the name is actually the uname -r for the
kernel it was built for.
b) what is the first package for? it is empty!
Virtual package, so people don't have to request the driver including
the kernel version. (The kernel version in there is actually part of the
rpm name, not part of the rpm version).
--
Jarod Wilson
jarod(a)wilsonet.com
9:15 a.m.
On 27.10.2008 04:03, Jarod Wilson wrote:
On Mon, 2008-10-27 at 00:22 +0000, Chris Nolan wrote:
> Jarod, Thorsten et al, couple of questions for you guys...
[...]
> Now I have a couple of questions:
>
> 1) What should the package be called? I'm not thrilled with
> "hybrid_wl-kmod" because I don't think it is descriptive to the
> end-user. I suggest "broadcom-hybrid-wl-kmod" which keeps in tune with
> an unofficial SUSE package and also seems to be more descriptive. Are
> there any guidelines for this? Any suggestions?
I actually started out calling it that as well, then flipped back and
forth a time or two. I think either one is fine. Shorter is good, but so
is descriptive.
+1
Just a note: Most kmods just are called like the kernel-module (which
iirc is called wl in this case). Maybe doing exactly that here as well
might be wise -- especially as "hybrid" will be meaningless for most people.
> 2) The SRPM builds the following packages:
>
> kmod-broadcom-hybrid-wl-5.10.27.6-2.fc9.x86_64.rpm
> kmod-broadcom-hybrid-wl-2.6.26.6-79.fc9.x86_64-5.10.27.6-2.fc9.x86_64.rpm
> broadcom-hybrid-wl-kmod-common-5.10.27.6-2.fc9.x86_64.rpm
Please don't use the term "-kmod-common" in the package name; just call
it "broadcom-hybrid-wl" and add
Provides: broadcom-hybrid-wl-kmod-common = %{version}-%{release}
Thinking about it some more: Maybe the best scheme for both packages
might be:
"kmod-wl" for the kmod package
"broadcom-hybrid-wl" for the second "userland" package (which then
needs
to provide wl-kmod-common = %{version}-%{release})
Opinions?
> broadcom-hybrid-wl-kmod-debuginfo-5.10.27.6-2.fc9.x86_64.rpm
>
> I don't fully understand the first two - the second one contains the
> actual kernel module but
>
> a) why is the name of the second package formed like it is - I am
> supposing that it is because it is built for a specific kernel version?
Correct. The first is the base package. People say 'yum install
kmod-broadcom-hybrid_wl', and get that package, and the latest
kernel-specific one, which is what the second package is. The
2.6.26.6-79.fc9.x86_64 in the name is actually the uname -r for the
kernel it was built for.
> b) what is the first package for? it is empty!
Virtual package, so people don't have to request the driver including
the kernel version. (The kernel version in there is actually part of the
rpm name, not part of the rpm version).
More important: that empty package always tracks in the latest kmod
package (the one with the modules in it) automatically on update; that
would not happen otherwise due to the "uname -r" in the name of the
package which holds the modules.
CU
knurd
11:15 a.m.
Thorsten Leemhuis wrote:
Please don't use the term "-kmod-common" in the package name; just
call it "broadcom-hybrid-wl" and add
Provides: broadcom-hybrid-wl-kmod-common = %{version}-%{release}
Thinking about it some more: Maybe the best scheme for both packages
might be:
"kmod-wl" for the kmod package
"broadcom-hybrid-wl" for the second "userland" package (which then
needs to provide wl-kmod-common = %{version}-%{release})
Opinions?
As an end user I find that slightly confusing to have so many different
permutations. I would find it less confusing to do your original way and
drop the "hybrid" altogether:
"kmod-wl" for the kmod package
"broadcom-wl" for the "userland" package which provides
broadcom-wl-common = %{version}-%{release}
Thoughts?
>> broadcom-hybrid-wl-kmod-debuginfo-5.10.27.6-2.fc9.x86_64.rpm
>>
>> I don't fully understand the first two - the second one contains the
>> actual kernel module but
>>
>> a) why is the name of the second package formed like it is - I am
>> supposing that it is because it is built for a specific kernel version?
>
> Correct. The first is the base package. People say 'yum install
> kmod-broadcom-hybrid_wl', and get that package, and the latest
> kernel-specific one, which is what the second package is. The
> 2.6.26.6-79.fc9.x86_64 in the name is actually the uname -r for the
> kernel it was built for.
>
>> b) what is the first package for? it is empty!
>
> Virtual package, so people don't have to request the driver including
> the kernel version. (The kernel version in there is actually part of the
> rpm name, not part of the rpm version).
More important: that empty package always tracks in the latest kmod
package (the one with the modules in it) automatically on update; that
would not happen otherwise due to the "uname -r" in the name of the
package which holds the modules.
CU
knurd
Thanks for this info guys, makes perfect sense now. I kinda mostly
figured this out but got too tired last night to respond.
Cheers
Chris
11:51 a.m.
On 27.10.2008 12:15, Chris Nolan wrote:
Thorsten Leemhuis wrote:
> Please don't use the term "-kmod-common" in the package name; just
> call it "broadcom-hybrid-wl" and add
>
> Provides: broadcom-hybrid-wl-kmod-common = %{version}-%{release}
>
> Thinking about it some more: Maybe the best scheme for both packages
> might be:
>
> "kmod-wl" for the kmod package
> "broadcom-hybrid-wl" for the second "userland" package (which
then
> needs to provide wl-kmod-common = %{version}-%{release})
>
> Opinions?
As an end user I find that slightly confusing to have so many different
permutations. I would find it less confusing to do your original way and
drop the "hybrid" altogether:
"kmod-wl" for the kmod package
"broadcom-wl" for the "userland" package
Sounds good.
which provides broadcom-wl-common = %{version}-%{release}
That nevertheless needs to provide "wl-kmod-common =
%{version}-%{release}" to satisfy the dep that automatically (by the
dark magic from kmodtool) gets added to each kmod package; but the user
normally won't see that.
[...]
Cu
knurd
8:48 p.m.
Thorsten Leemhuis wrote:
On 27.10.2008 12:15, Chris Nolan wrote:
>
> As an end user I find that slightly confusing to have so many
> different permutations. I would find it less confusing to do your
> original way and drop the "hybrid" altogether:
>
> "kmod-wl" for the kmod package
> "broadcom-wl" for the "userland" package
Sounds good.
> which provides broadcom-wl-common = %{version}-%{release}
That nevertheless needs to provide "wl-kmod-common =
%{version}-%{release}" to satisfy the dep that automatically (by the
dark magic from kmodtool) gets added to each kmod package; but the
user normally won't see that.
Hi Thorsten
I have done this, but just to be clear, does this mean that
xxx-kmod-common is automatically added as a dependency to any xxx-kmod
package, and if so, is it safe to remove
Requires: %{name}-common = %{version}-%{release}
from the spec file? Also, if that is the case, what if there was no
xxx-kmod-common package actually required? (this package only needs one
because of the requirement to bundle the license.txt)
Regardless, I've made some changes and put a review request in:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=96
Best
Chris
5:48 a.m.
On 27.10.2008 21:48, Chris Nolan wrote:
Thorsten Leemhuis wrote:
> On 27.10.2008 12:15, Chris Nolan wrote:
>> As an end user I find that slightly confusing to have so many
>> different permutations. I would find it less confusing to do your
>> original way and drop the "hybrid" altogether:
>>
>> "kmod-wl" for the kmod package
>> "broadcom-wl" for the "userland" package
> Sounds good.
>
>> which provides broadcom-wl-common = %{version}-%{release}
> That nevertheless needs to provide "wl-kmod-common =
> %{version}-%{release}" to satisfy the dep that automatically (by the
> dark magic from kmodtool) gets added to each kmod package; but the
> user normally won't see that.
I have done this, but just to be clear, does this mean that
xxx-kmod-common is automatically added as a dependency to any xxx-kmod
package,
Yes.
and if so, is it safe to remove
Requires: %{name}-common = %{version}-%{release}
from the spec file?
Yes.
Also, if that is the case, what if there was no
xxx-kmod-common package actually required? (this package only needs one
because of the requirement to bundle the license.txt)
It was decided ages ago that a userland package (that provides that
-common stuff) is mandatory, as every module has docs or other things
that need to be shipped somewhere.
CU
knurd
5657
days inactive
5659
days old
rpmfusion-developers@lists.rpmfusion.org
16 comments
4 participants
participants (4)
-
Andreas Thienemann -
Chris Nolan -
Jarod Wilson -
Thorsten Leemhuis