Currently the net-wireless/broadcom-sta ebuild checks kernel configuration parameters via CONFIG_CHECK, and generates a warning after installation based upon these results. If LIB80211 is not enabled, it dies as it should. If B43 or SSB are enabled, however, it does not die, but rather simply warns the user after the build. Rather than throwing up a warning, the merge should stop dead in its tracks and refuse to proceed further until B43 and SSB are removed (similar to the way it does if LIB80211 if not enabled). Given the potential problems introduced if either of these options are enabled, if CONFIG_CHECK finds either of these enabled, it should die rather than warn. Suggested change: --- broadcom-sta-5.10.91.9.3-r2.ebuild.orig 2010-01-10 23:02:05.156263382 -0600 +++ broadcom-sta-5.10.91.9.3-r2.ebuild 2010-01-10 22:59:34.102346532 -0600 @@ -29,7 +29,7 @@ pkg_setup() { check_license - CONFIG_CHECK="~!B43 ~!SSB" + CONFIG_CHECK="!B43 !SSB" if kernel_is ge 2 6 31; then CONFIG_CHECK="${CONFIG_CHECK} LIB80211" elif kernel_is ge 2 6 29; then Reproducible: Always Steps to Reproduce: 1.with LIB80211 already enabled, enable SSB or B43 2.emerge broadcom-sta 3.obverse the ebuild generates warnings rather than stopping the build. Actual Results: Package merged successfully despite SSB and/or B43 being enabled within kernel configuration Expected Results: Build should stop upon detecting SSB or B43 are enabled in kernel configuration. Further discussion of this can be found in this thread on the forums - http://forums.gentoo.org/viewtopic-p-6127694.html Apologies in advance if there's a good reason I/we are simply unaware of as to why this is ~!B43 ~!SSB rather than !SSB !B43 - hopefully I'm not wasting anyone's time with this. At worst I figure this gets marked as WONTFIX and an explanation is doc'd in the bug that can be used down the road. My emerge --info is completely irrelevant to this, but in the interest of compliance here goes! emerge --info ================================================================= Portage 2.1.7.16 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.32-zen3 x86_64) ================================================================= System uname: Linux-2.6.32-zen3-x86_64-Pentium-R-_Dual-Core_CPU_T4200_@_2.00GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 08 Jan 2010 02:15:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4, 3.1.1-r1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="CCACHE assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ " LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/arcon /usr/local/portage/layman/devnull /usr/local/portage/layman/enlightenment /usr/local/portage/layman/pentoo /usr/local/portage/layman/zen-sources /usr/local/portage/layman/mozilla /usr/local/portage/layman/sping" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac acl alsa amd64 berkdb branding bzip2 cli cracklib crypt css cups cxx dbus dri dts dvd dvdcss ffmpeg firefox flac flag fortran gdbm gpm hal iconv jpeg kde lame libnotify libv4l2 lvm2 mad matroska mmx modules mp3 mpeg mudflap multilib ncurses nls nonfsv4 nptl nptlonly nsplugin offensive ogg opengl openmp pam pcre perl png pppd python readline reflection rtsp session skins spl sse sse2 ssl ssse3 stream svg sysfs tcpd truetype twolame unicode v4l v4l2 vorbis wxwidgets x264 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Adding myself to this bug.
Created attachment 216558 [details] suggested updated ebuild Unsure of naming conventions for proposed new ebuilds, apologies in advance. It has been changed so that: B43 || SSB == failed build if present WIRELESS_EXT || LIB80211 == failed build if NOT present (compile fails if !WIRELESS_EXT anyway) MAC80211 == warn if this is present, since it is known to cause issues
ack. fixed in r3.
IMHO, can there be check if CONFIG_B43=m and CONFIG_SSB=m, and not die in that case. Since one may just want to compile them as modules and blacklist them in /etc/modprobe.d/blacklist.conf.
(In reply to comment #4) > IMHO, can there be check if CONFIG_B43=m and CONFIG_SSB=m, and not die in that > case. Since one may just want to compile them as modules and blacklist them in > /etc/modprobe.d/blacklist.conf. > Aside from someone whose aim is testing both, there shouldn't be a need to have both available on any system at the same time. If the user wishes to try out B43 && SSB, they can emerge -C broadcom-sta and carry on about their business happily. The ebuild should, IMHO, have priority number one as ensuring that it - the ebuild itself, and the package it installs - function without issue. In an ideal/hypothetical/whatever world, a user who "knows what they're doing" to the extent they know how to operate effectively with both on a system, will know how to circumvent CONFIG_CHECK as needed. To ensure this ebuild works for the lowest common denominator, it should do everything it can to ensure the driver installed by the broadcom-sta package functions without issue; the purpose of emerging this ebuild for the vast majority will be using it to gain a functional wireless setup. Since ensuring a functional wireless setup is beneficial to the majority, and advanced users who know how to operate with both in-kernel and ebuild-provided drivers will have enough of an understanding as to be able to bypass this check (in theory), given the huge level of problem incurred if a non-advanced user merges this without their kernel set as it should be, you will please a greater number of people if you prevent conflicting drivers from being on a system. While you can check a kernel config for =m within an ebuild, you *cannot* ensure that if =m the user has blacklisted modules as they should be. Given this limitation I personally would be opposed to allowing a build to succeed if modules that are known to cause problems are enabled, especially given the limitation of not being able to check which modules a user has blacklisted via the ebuild mechanism.
I just figured there was already a mechanism to make bad .configs cause failure with this driver. Since I know how to correctly set up my .config to use the broadcom-sta properly, I wouldn't have seen a warning. When I found out that wasn't the case, I was personally confused. If the literature and anecdotal evidence points to issues having the SSB module and broadcom-sta working at the same time, it would be assumed that the ebuild would check for that. I fully support cach0rr0 in this, and thank him for fixing an issue I didn't even know existed.
It should not die! Because people can just blacklist modules. This is not the correct behaviour and enforces people to not build their kernels with B43 or SSB, which is clearly incorrect. Please remove the blocking check, a warning is enough.
(In reply to comment #7) > It should not die! Because people can just blacklist modules. This is not the > correct behaviour and enforces people to not build their kernels with B43 or > SSB, which is clearly incorrect. > > Please remove the blocking check, a warning is enough. > If you propose this, can you tell me one good reason you would want both? You cannot drive one device with two separate drivers. That's insane, even on its face, in both the mental and computer senses of the word. I work with people on a daily basis who have issues because of the conflicts between ssb, b43, and broadcom-sta. The death at an INCORRECTLY CONFIGURED KERNEL prevents this from happening. It "fool proofs" the driver, so to speak. As one who works with others who have issues with this driver, I say ebuild death is a needed feature, and has been for some time. Why install conflicting drivers? There is no good reason for such nonsense. If you are personally enamored of using both, you'll have to modify your .config each time you want to switch up, or use different kernel versions for different drivers, like I did when testing the braodcom-sta. The idea of blacklisting has already been proved to be worthless in this situation. Please read above for more details. Of course, this is Gentoo, so if you really can't live with this situation, revert to the old ebuild on your personal system. For the others who use Gentoo, especially the N00B, having the ebuild die insures that the kernel will be PROPERLY set up to work with the broadcom-sta driver.
A warning is enough, there are no restrictions nor conflicts in building both modules and deciding which one to use. I could also mention the fact that we, as gentoo devs, should avoid annoying users, deciding for them what is good and what is not when it's not strictly required. That's our usual standard procedure.
(In reply to comment #9) > A warning is enough, there are no restrictions nor conflicts in building both > modules and deciding which one to use. I could also mention the fact that we, > as gentoo devs, should avoid annoying users, deciding for them what is good and > what is not when it's not strictly required. That's our usual standard > procedure. > No conflicts? Ok, whatever you say. Tell that to someone who's having issues caused by just that.
The fix is NOT blocking the compilation and installation of a module. The issue is in the conflict itself, by any means in the ebuild, that's what I call a "hack". Writing a reliable udev rule is. And what about the rest of the external modules available in Portage? They just don't follow the same rationale, because it's wrong and against the Gentoo spirit (beside being just _wrong_, once again). I'm going to ask the maintainer to not make pkg_setup die in case of wrong settings. You always forget about binpkgs and how these things (done wrong!) break it.
There is a reason CONFIG_CHECK exists. There is a reason the ability to block a merge completely exists with CONFIG_CHECK. CONFIG_SSB is well known to be problematic with broadcom-sta. CONFIG_B43 is well known to be problematic with broadcom-sta. What compelling reason is there to allow the installation of broadcom-sta on a system where you know fully well the user's kernel is going to prevent its stable operation? A real world scenario, rather. Why do you include something in your kernel that you're just going to blacklist anyway? That defeats the purpose of having it in your kernel in the first place - much simpler, if you're not going to use it, don't include it in your kernel. Now having said that, I'd rather introduce a "problem" if you can even call it that, for an advanced user that knows the risks and mitigation steps should they knowingly choose to have conflicting drivers installed, than I would the very vast majority who would bring in broadcom-sta and sit there scratching their heads wondering why their wireless card is non-functional. > And what about the rest of the external modules available in Portage? >They just don't follow the same > rationale, because it's wrong and against the Gentoo spirit (beside being just > _wrong_, once again). Really? Go do a quick "grep -r CONFIG_CHECK /usr/portage" and note the huge sum of packages that do this very same thing - having hard blocks on merges for kernel settings known to be problematic. Seems there are plenty of others who are "against the Gentoo spirit". If this is "against the Gentoo spirit", hell, why don't we completely remove the CONFIG_CHECK function from portage completely? Or at the very least remove the ability to block a merge based on kernel settings, since having this ability is clearly "against the Gentoo spirit". Making every effort to prevent users from harming themselves doesn't seem to be "against the Gentoo spirit". As I said before, if you "know what you're doing" to the extent you know how to operate (b43||ssb)&& broadcom-sta without issues, you're advanced enough to know how to fool the ebuild. Most users do not fall into this category. The only real reason I can see to allow both to coexist is for people who simply want to test both drivers - if you want to test both drivers, a quick # in your .config gets you around this without any need to rebuild your kernel. This is nothing more than "I know it's not going to work, but I want to do it anyway - stop restricting my freedom, don't tase me bro!". This is not a compelling real-world scenario - and to me, reverting this change to please the 2% who know how to get around the block anyway, just seems like a poor ROI.
Perhaps the development paradigm needs to shift. When you've worked with dozens of users having the same problems over and over again, you get to knowing what works and what doesn't. Mixing those modules doesn't work. Starting both at the same time is going to cause issues. Believe it or not, even here in Gentoo Land, most users want their computers to work properly, and with stability. Driver conflicts stop that from happening. They can also stop the computer in its tracks. I've had other ebuilds that failed due to improper kernel settings. Guess what, I reconfigured, recompiled, and reemerged. Aw shucky darns! I am still alive, so I can only surmise the experience didn't kill me. Advanced users are going to do what they want to do. This is as it should be. For instance, if this ebuild gets "fixed" by breaking at again, I'll just tuck it away in my own private overlay. Let's not forget that there are n00bs about as well. If the ebuild dying educates one person in proper kernel configuration, then so much the better for Gentoo.
I think it is reasonable that the ebuild will fail if the check doesn't succeed (although there are many ebuilds out there that just warn you that if you don't do something you computer might explode, and we're used to it) as long as there is some relatively easy way to allow it to continue - since there are valid use cases and there are users who want it (and I will detail it below). An easy way is not 'change .config everytime you merge' or create an overlay ebuild and maitain it every time the original ebuild changes. Rather I would expect a USE flag ('force') or an evironment setting. The valid use case: I have a dell d630 with a broadcom wireless card. The b43 drivers works perfectly at home but only broadcom-sta works at work.
(In reply to comment #14) I would be most definitely supportive of allowing the death of the build to be configurable via USE. This looks to be doable without too much pain, really just need to decide on a name for the USE. I also agree that having to modify your .config to do the merge is less than graceful - no argument there. I'm curious why neither b43 nor sta work at both spots, but that's another discussion for another day (and an anomaly rather than typical usage). Whatever is done, however, I do not think the default should be to allow the presence of both. Let the users who 'know what they're doing' set the USE accordingly. In summary: I agree, I like this suggestion, and think making this configurable via USE is the best solution suggested to date. It is the least hacky method I can see of defaulting to requiring known functional settings for the bulk of users, while allowing the rest a workaround that fits the Gentoo mold. I don't have the time to redo and submit an ebuild, but hopefully someone else can beat me to it. If it looks like nobody else has anything, time permitting I'll chunk one together.
Created attachment 218090 [details] Added "even-with-b43" use flag, to allow expert users to do crazy stuff There ya go...
Created attachment 218181 [details, diff] as a patch
This bug is old. B43 obsolete. IME it doesn't matter (with v6 of the driver) whether you build brcmsmac (as modules, then blacklist) or not. Furthermore i refer to Fabio's comments. So I mark this as WONTFIX until further issues arise.
