Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 16/02/2013 07:08, Rick Zero_Chaos Farina wrote: What happens why a user runs --depclean and has a masked package installed? Oh that's right, it uninstalls. My systems do that automatically, but you are welcome to assume stupid user didn't read messages if that is easier. That's not right. It doesn't. emerge -avuDN blah-blah-blah !!! The following installed packages are masked: - media-gfx/blender-2.64a::gentoo (masked by: package.mask) /var/cache/portage/tree/profiles/package.mask: # Diego Elio Pettenò flamee...@gentoo.org (05 Feb 2013) # Needs a complete ebuild rewrite to use CMake, and a new patchset to # unbundle the bundled libraries. Use at your own risk; don't ask for # a bump unless you can provide the two needed items. emerge --depclean These are the packages that would be unmerged: x11-misc/makedepend selected: 1.0.4 protected: none omitted: none All selected packages: x11-misc/makedepend-1.0.4 So, I'm afraid you're exaggerating a little bit. Yes, we should look better in which firmware packages to remove (because they are merged in linux-firmware or the driver is gone), but that does not mean we should not ever consider touching ever a single one of them. And I mean, we've had quick-stable updates that were much more destructive than just removing the firmware of the nic (which is most likely still available to emerge if the user is not using eclean-dist). udev-197 anyone? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Sat, Feb 16, 2013 at 5:52 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 16/02/2013 07:08, Rick Zero_Chaos Farina wrote: What happens why a user runs --depclean and has a masked package installed? Oh that's right, it uninstalls. My systems do that automatically, but you are welcome to assume stupid user didn't read messages if that is easier. That's not right. It doesn't. emerge -avuDN blah-blah-blah !!! The following installed packages are masked: - media-gfx/blender-2.64a::gentoo (masked by: package.mask) /var/cache/portage/tree/profiles/package.mask: # Diego Elio Pettenò flamee...@gentoo.org (05 Feb 2013) # Needs a complete ebuild rewrite to use CMake, and a new patchset to # unbundle the bundled libraries. Use at your own risk; don't ask for # a bump unless you can provide the two needed items. emerge --depclean These are the packages that would be unmerged: x11-misc/makedepend selected: 1.0.4 protected: none omitted: none All selected packages: x11-misc/makedepend-1.0.4 So, I'm afraid you're exaggerating a little bit. Yes, we should look better in which firmware packages to remove (because they are merged in linux-firmware or the driver is gone), but that does not mean we should not ever consider touching ever a single one of them. And I mean, we've had quick-stable updates that were much more destructive than just removing the firmware of the nic (which is most likely still available to emerge if the user is not using eclean-dist). udev-197 anyone? So because we did things badly in the past, that is an excuse to do things badly in the future? :) I do not necessarily encourage developers to make mistakes. Mistakes will happen (as we are all human) but we should probably strive to put some effort into not screwing up. -A -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 16/02/2013 20:18, Alec Warner wrote: So because we did things badly in the past, that is an excuse to do things badly in the future? :) No. I still argue that this is NOT doing things badly. Masking a package will NOT cause it to get unmerged by default. The whole line of thought that Rick is bringing here is based on the assumption that masked package == removed package, which is false, so the whole point is moot. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Diego Elio Pettenò wrote: So because we did things badly in the past, that is an excuse to do things badly in the future? :) No. I still argue that this is NOT doing things badly. Masking a package will NOT cause it to get unmerged by default. Hm, can you expand on by default ? When will it get unmerged then? //Peter
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 16 February 2013 19:31, Peter Stuge pe...@stuge.se wrote: Diego Elio Pettenò wrote: So because we did things badly in the past, that is an excuse to do things badly in the future? :) No. I still argue that this is NOT doing things badly. Masking a package will NOT cause it to get unmerged by default. Hm, can you expand on by default ? When will it get unmerged then? //Peter I guess when nothing else depends on it or it is not in your world file -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2013 05:39 PM, Samuli Suominen wrote: On 15/02/13 00:27, Rick Zero_Chaos Farina wrote: Remove firmware from users systems with no upgrade path and then ask users to file a bug? That's pretty awesome, how can those people file a You have very broken definition of removing/breaking users systems. Masking is not breaking. The message was very careful. Don't over dramatize this. What happens why a user runs --depclean and has a masked package installed? Oh that's right, it uninstalls. My systems do that automatically, but you are welcome to assume stupid user didn't read messages if that is easier. About the others, losing them is not too dramatic. This was worked out between ssuominen and myself on irc nearly a week ago. I believe we were both happy when we were done. Sorry for not updating the list but the issue hasn't been dire for a while. If you mean working out it by you doing unnecessary yelling on public IRC channel and me ignoring it, then sure. ;-) I'm sorry you feel that way. My intent was to work with you to solve the problem in the fastest way possible to avoid users cleaning firmware from their only network card. It was not my intent to demean you in any way. Multiple lines in that mask were an issue, not only that but you said you would mask firmware that was in linux-firmware and/or didn't install properly in /lib/firmware then proceeded to mask firmware that didn't fit either category. If you would like to continue pretending you didn't make a mistake that is fine, but please don't pretend I was unreasonably attacking you as I was not unreasonable nor attacking you. - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHyJrAAoJEKXdFCfdEflKCA8P/1w0t8gLROkFg8+ioPrTHX3g y9sKwKa5Sw0zxnTPYAZ75hoI6xP3H6WzhTPfMRpaOHR24PRMgmRTumelHShhf76z S4XxP8HUjnysjuPS70lBTU/cFi93sut+C/s4//k6wni3SzS7xq/BlkD4rwAYYBaI SSOxEeys5M5ghkPG0Wrj1x7m9j/ud0h6CTCbRBaxK7W1uMdRqXzaZmyYPcJ3lsZ3 Q+gHWOJZdAymput0CZ61CjpcAdmU+hsQk5A3L1dXxKCuxaEt/GgiNkm82UKjZyg2 o2hactvPQFH9VUyFGm96tG+L3E1o05uvXQEf0MUFDxcH7iG6HFdiyCC5pcsACo0z Z+FB+nb9y/AE6AWxfx5jiuizo+KWFkOH/RhyE91MbqEnRRSWoyBExQQu3tqfrfAr RCgKbKOZXLCEKeIoFAzsprNcwcullnDr4g3a0Fdjouz9b4nNEoojJjX3IU086bkp 3nwNFbguWBwIWB+YJ6KSZ42Kw08FZYQRIccV/khXmfFYyWgXj1twOE3CqDKWDr4N gvZauSfsoHgQkXIn02+eiDnZW60QYONfKTnDmJ68BdXpoFAi0/h0sQg7OS5+E2KN d+5/2vHINR/pphVbVK2Ku44c7h3J7Qj1xMiNa8CxL9AtCkqMKhliykOSpD6bsyUJ IlTiv2rnuYCNuKd56nKt =RM+e -END PGP SIGNATURE-
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On 14/02/13 09:26, Michael Weber wrote: non-multilib/x86 installs to /lib, multilib is linked to /lib. So please, stop using dramatizing this and use it as alibi for your otherwise justified plans. There is no guarantee multilib is linked to /lib whatsoever. Where did you get that idea?
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/2013 08:08 AM, Chí-Thanh Christopher Nguyễn wrote: Rick Zero_Chaos Farina schrieb: atmel-firmware ipw2100-firmware ipw2200-firmware b43-firmware b43legacy-firmware rtl8192su-firmware zd1201-firmware zd1211-firmware None of these are blockers on linux-firmware, none of these are included in linux firmware, none of these should be masked with no replacement as we are breaking approximately 90% of wifi cards on laptops built in the last 5 years. I think your 90% figure is unsubstantiated and likely too high. Many budget laptops nowadays use Realtek, Ralink or Atheros chipsets which have firmware in linux-firmware.git Firmware for iwlwifi is in linux-firmware.git too (Intel 3945ABG was introduced in 2006) For new Broadcom chipsets (following the launch of the brcmsmac/brcmfmac drivers in 2010) the same is true. Users of older chipsets can still use b43-fwcutter. I meant the older devices, I know a lot of people using ipw2200 and b43legacy/b43 cards from long before ralink was fancy. Only the following acctually show masked when I update: -net-wireless/rtl8192su That firmware is not useful with modern kernels. Yup, fixed Due to the damage this will cause I am removing the mask on these NOW, I will cleanup the ebuilds today but this is bad, really really bad. If we are cleaning up linux-firmware that's great, but someone needs to check that the things we are masking/removing are actually in linux-firmware... You were asked to file a bug report in the mask message if you want to keep them. I agree that the following should stay: atmel-firmware ipw2100-firmware ipw2200-firmware zd1201-firmware zd1211-firmware Remove firmware from users systems with no upgrade path and then ask users to file a bug? That's pretty awesome, how can those people file a bug when you break their network connections? I agree, my reaction was a bit strong, but the non-chalance about breaking people's systems isn't cool. Far more thought needs to go into masking things like firmware in the future. A mail should be put on the list and experts should be consulted. I have 200 wifi cards myself, if you want to know for sure what is required and what isn't, you only have to ask me to test... I'm sure others are happy to test things in their respective areas rather than see things masked because if users need it they will complain. About the others, losing them is not too dramatic. This was worked out between ssuominen and myself on irc nearly a week ago. I believe we were both happy when we were done. Sorry for not updating the list but the issue hasn't been dire for a while. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHWTMAAoJEKXdFCfdEflKZMIQAKPeoUsQaf2Cf/R7PIeP44lI lKE6csmyE++8wJtVejMzYyp61a1m5gKxRDO1KGJcMAV39XXxsVHjqVTll/CaqhX6 edGWRK93/WdctGf4iOMR+HqZcDy+sdFXJ/hSoL049gw48yf5C1ROTrLz4XaEtff2 p0iywJxqEh8RsUzlOv7jCEe9fRCgPsK+L81wL+GsFzrKUTpKG3xF+begi2lnIDv8 ei+k6DzVyzpUq/jV4ml5HYyssubqgXUD/0Fxaf9YPRn+LedQTFBwn3kqu64fs2ds hgR4SqfFCdklqVIwKeTzJSJCahEeU+UCcBxml/Rs+NLj/OJSS8tgxm3aiQ9zmEcR ehCooUGqq/mrljB8ltrSjogSlhAMxNjTtO2zft35F00zORxErNXSVtzaiBbrTE7R WK5pRIfsDlPzooE46xA+osP5qtqeSmoF8GRCJdncUMGKl1/9werAn1yX/YstKDVk peZHDqlf/DdsrW2CgVBatrBgcT1ULvNgkw2NM+mSHj9hgYmf+R5UVoDBF3rdDgMQ 2iz53OzcUlTgVbUmwrLyxYIw3kL8pemTHR5aYMcmHGy9dtwy7+BWJURDuNOLGSy3 0QiqaXdscWko9O9ChFOB11yAbSu6IF4y/LK4pE59dh1ia9SdJMidM9Xm2xzPmY9f nxAccTmeQPDNOKijgOa6 =hKXW -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/2013 08:39 AM, Chí-Thanh Christopher Nguyễn wrote: Rick Zero_Chaos Farina schrieb: Having 300 -firmware packages is silly. I can't help but noticing that some of the recently introduced iwlwifi firmware packages came from Chromium OS. So there seems to be interest in individual packages from downstreams over the linux-firmware package. I think we all agree savedconfig isn't an ideal implementation, if we were able to offer something better I don't think downstream would be clamoring to add more packages to maintain. Not that I personally have any idea how to improve the situation. I like the idea of use_expand but that seems to get ugly really fast. - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHWVhAAoJEKXdFCfdEflKwOsP/0sN6yzi1e/yCfAfkEyVd4Z8 VcUIF6YiRlg605jqAmUtBiD8HQtgQC4XokyIt8EThV6ppco98D7LY5s2NPWUZrJu SWukKLPuwiNmf+SKM7GkJfKygHTptyaxJy6KG1YnhaOgZz1KjnoatH7jMmevasOa TX7y91BH1EqDDvQgFtkYPtR/9+Ex48ykqb5kayBHGfm9ntFoGIcOaLBnwE8+zIS1 oh9OEsyz2PxsgzAdrfW6wAV8zM1Ytx4hjo20H+Skslb6qDcB2eOAqWb7XmVuB8jF 2Qle/WeDluj9Ly0aogMpZM5TV524eHvxR/hwNMnV9KZIwd/EOCVt0EJAL5e2GhtJ 28r25Zrwib8t2rBUzwGLKtunaNhGZbCM+HYgOpD0P0NgoMpCFX/q6GvNj3CP3uyd MGp/X3BHBjyzTpOat8d22S6cpjlkjAgVQMCVnBvW1ZhAF7SuHvetZn7xm6v+85ci iIsb57RwHgBFEIdq72INQv6TXGt3E95DAxxFxDoxexdv487qSAYJQaqY0calKLGk IdrQZgvE3wAKFSwfpKBPCZSx+3zZKSHooQUJALwr5eHFkwnbMec49W7XDYba7/qt Sw1ihOz4eb+njR0N2oFGb1N9pYshABIF7+TtNSQcYYeagHZkTFpiK8JEC2BkV3Oq mPsmzVkPWcgjCJ7s2CdU =FknU -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 15/02/13 00:27, Rick Zero_Chaos Farina wrote: Remove firmware from users systems with no upgrade path and then ask users to file a bug? That's pretty awesome, how can those people file a You have very broken definition of removing/breaking users systems. Masking is not breaking. The message was very careful. Don't over dramatize this. About the others, losing them is not too dramatic. This was worked out between ssuominen and myself on irc nearly a week ago. I believe we were both happy when we were done. Sorry for not updating the list but the issue hasn't been dire for a while. If you mean working out it by you doing unnecessary yelling on public IRC channel and me ignoring it, then sure. ;-) - Samuli
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Christopher Head schrieb: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. That is not fully correct. It is true that certain drivers or certain configurations (e.g. CONFIG_IP_PNP) may require firmware to be present during early boot. But unlike the Intel wifi driver which used to stop working and detach from the device when firmware loading failed, most other drivers will reattempt to load firmware every time on bringing up the interface. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Rick Zero_Chaos Farina schrieb: atmel-firmware ipw2100-firmware ipw2200-firmware b43-firmware b43legacy-firmware rtl8192su-firmware zd1201-firmware zd1211-firmware None of these are blockers on linux-firmware, none of these are included in linux firmware, none of these should be masked with no replacement as we are breaking approximately 90% of wifi cards on laptops built in the last 5 years. I think your 90% figure is unsubstantiated and likely too high. Many budget laptops nowadays use Realtek, Ralink or Atheros chipsets which have firmware in linux-firmware.git Firmware for iwlwifi is in linux-firmware.git too (Intel 3945ABG was introduced in 2006) For new Broadcom chipsets (following the launch of the brcmsmac/brcmfmac drivers in 2010) the same is true. Users of older chipsets can still use b43-fwcutter. Only the following acctually show masked when I update: -net-wireless/rtl8192su That firmware is not useful with modern kernels. Due to the damage this will cause I am removing the mask on these NOW, I will cleanup the ebuilds today but this is bad, really really bad. If we are cleaning up linux-firmware that's great, but someone needs to check that the things we are masking/removing are actually in linux-firmware... You were asked to file a bug report in the mask message if you want to keep them. I agree that the following should stay: atmel-firmware ipw2100-firmware ipw2200-firmware zd1201-firmware zd1211-firmware About the others, losing them is not too dramatic. Best regards, Chí-Thanh Christopher Nguyễn
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Sergei Trofimovich schrieb: The source of confusion was non-working device by default. Maybe 'IUSE=+firmware; RDEPEND=firmware? ( sys-kernel/linux-firmware )' for virtual/linux-sources would help user experience a bit. +1 https://bugs.gentoo.org/457082 Instead of USE defaults, this could be turned on in the desktop profile as wifi, radeon cards etc. are less likely to be present on non-desktop systems. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Maxim Kammerer schrieb: Having 300 -firmware packages is silly. I agree, but think that the process can be more user-friendly than a savedconfig — perhaps a variable as was suggested already. As the developer who came up with the savedconfig implementation, I am the first one to admit that it is not user-friendly. USE_EXPAND would be possible, but much work for not much gain. How to name the flags, after the firmware filenames? After the kernel modules that use them (what if there are multiple kernel modules for the same firmware file as with b43/brcmsmac)? And every time new firmware is added this would have to be updated. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Rick Zero_Chaos Farina schrieb: Having 300 -firmware packages is silly. I can't help but noticing that some of the recently introduced iwlwifi firmware packages came from Chromium OS. So there seems to be interest in individual packages from downstreams over the linux-firmware package. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 13/02/2013 14:39, Chí-Thanh Christopher Nguyễn wrote: I can't help but noticing that some of the recently introduced iwlwifi firmware packages came from Chromium OS. So there seems to be interest in individual packages from downstreams over the linux-firmware package. I would suppose the problem is they are needed before they enter linux-firmware — I also introduced one of the iwl firmwares for one of my laptops (the other had it already), and I wonder if I should just drop it now as it SHOULD be available in linux-firmware (guess I'll check today). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On 13/02/2013 14:38, Chí-Thanh Christopher Nguyễn wrote: https://bugs.gentoo.org/457082 Instead of USE defaults, this could be turned on in the desktop profile as wifi, radeon cards etc. are less likely to be present on non-desktop systems. IIRC some server systems need ethernet cards' firmware though, so IUSE defaults sounds better... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Diego Elio Pettenò schrieb: On 13/02/2013 14:38, Chí-Thanh Christopher Nguyễn wrote: https://bugs.gentoo.org/457082 Instead of USE defaults, this could be turned on in the desktop profile as wifi, radeon cards etc. are less likely to be present on non-desktop systems. IIRC some server systems need ethernet cards' firmware though, so IUSE defaults sounds better... Indeed. Firmware is also needed for some RAID controllers. I imagine that users of the default profile are more likely to not need hand-holding here and more likely to want a lean system by default. But I have no strong opinion either way. Best regards, Chí-Thanh Christopher Nguyễn
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On 13/02/2013 15:50, Chí-Thanh Christopher Nguyễn wrote: Indeed. Firmware is also needed for some RAID controllers. I imagine that users of the default profile are more likely to not need hand-holding here and more likely to want a lean system by default. But I have no strong opinion either way. My point is mostly why make it different if there is no need to make it different?. People who don't need the firmware can deal with disabling it themselves. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Wed, Feb 13, 2013 at 5:39 AM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Rick Zero_Chaos Farina schrieb: Having 300 -firmware packages is silly. I can't help but noticing that some of the recently introduced iwlwifi firmware packages came from Chromium OS. So there seems to be interest in individual packages from downstreams over the linux-firmware package. At least two chromeos developers are on this list..so you could chat with them ;) -A Best regards, Chí-Thanh Christopher Nguyễn
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Diego Elio Pettenò wrote: People who don't need the firmware can deal with disabling it themselves. I don't like the binary distribution argument of include everything to cover as many possible use cases as possible in one go. I very much like the high resolution of Gentoo packages. I'd hate to enter a slippery slope toward lower resolution. //Peter
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On 13/02/2013 18:33, Peter Stuge wrote: I don't like the binary distribution argument of include everything to cover as many possible use cases as possible in one go. I very much like the high resolution of Gentoo packages. I'd hate to enter a slippery slope toward lower resolution. Are you really that _lazy_ to not accept the option to just do cat - /etc/portage/package.use EOF sys-kernel/gentoo-sources -firmware EOF and be done with it? Chr(ome) on a bike, you're getting on my nerves (and I'd bet not just mine). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Diego Elio Pettenò wrote: I don't like the binary distribution argument of include everything to cover as many possible use cases as possible in one go. I very much like the high resolution of Gentoo packages. I'd hate to enter a slippery slope toward lower resolution. Are you really that _lazy_ to not accept the option to just do cat - /etc/portage/package.use EOF sys-kernel/gentoo-sources -firmware EOF and be done with it? Kernel -sources USE is a handy way to install linux-firmware wholesale, but AIUI the standalone firmware packages would be removed too, effectively making the USE flag non-optional, and removing the possibility of having managed firmware packages. (People would have to download single firmware files on their own.) I think the objection is against a solution that will replace what is there at the moment and cause more firmware files to always be installed, if only some specific ones are actually needed. Also: Is this only for gentoo-sources? What about the other -sources? //Peter
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Peter Stuge schrieb: Kernel -sources USE is a handy way to install linux-firmware wholesale, but AIUI the standalone firmware packages would be removed too, effectively making the USE flag non-optional, and removing the possibility of having managed firmware packages. (People would have to download single firmware files on their own.) I see that there exists some preference for individual firmware packages for certain users or use cases. This is why the mask message told you to report a bug if a particular firmware package is important to you. I think the objection is against a solution that will replace what is there at the moment and cause more firmware files to always be installed, if only some specific ones are actually needed. USE=savedconfig can prevent installation of undesired firmware files. I admit that this is not very user friendly though. And some of the flexibility in mixing linux-firmware[savedconfig] and individual packages has been destroyed by adding blocker against linux-firmware in the individual packages (bug 456746 comment 4) Also: Is this only for gentoo-sources? What about the other -sources? The suggestion is to have it for virtual/linux-sources. Best regards, Chí-Thanh Christopher Nguyễn
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Peter Stuge pe...@stuge.se writes: Kernel -sources USE is a handy way to install linux-firmware wholesale, but AIUI the standalone firmware packages would be removed too, effectively making the USE flag non-optional, and removing the possibility of having managed firmware packages. (People would have to download single firmware files on their own.) What would perhaps be nice would be to patch 'make firmware_install' to have it call a utility which scans .config and fetches and installs any firmware required for a configured device.
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
U folks are aware of the fact that installed sources is rather vaguely coupled with running kernel, right? No, I'm not running archkernel on gentoo, but it would be possible. It's also fine to poke around in linus' sources and cross compile w/o ever running the damn thing or needing firmware from /lib/firmware. Anyway, please do not force-reinstall of about 400k kernel source files to just fix any USE flag constellation. I'm not saying --newuse, just people forgetting to set the flag. Last thought, we have maintainer-needed in bugzilla to handle unmaintained packages (and I'm looking at these from time to time, maybe I should start a maintainer-needed herd). /$(get_libdir) vs /lib is the wrong method without effect, non-multilib/x86 installs to /lib, multilib is linked to /lib. So please, stop using dramatizing this and use it as alibi for your otherwise justified plans. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Sorry this is not threaded properly; I accidentally deleted the e-mail I intended to reply to. Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Don't force me to install a package that provides me with a grand total of zero benefit, just so you can hand-hold people. It's unfortunate that people were caught by the firmware being removed from the kernel and breaking their hardware. This sounds like an application for a news message telling people to install firmware if needed, but IMO it doesn't call for a dependency. Chris
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner anta...@gentoo.org wrote: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. Chris
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
El mar, 12-02-2013 a las 19:43 +, Fabio Erculiani escribió: I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. I think shouldn't have any problems on providing them also as an alternative, the problem is who would maintain that builds (as I guess Sabayon is using different sources than gentoo and, then, probably not all chosen options for Sabayon will work on Gentoo :/) signature.asc Description: This is a digitally signed message part
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Tue, Feb 12, 2013 at 7:47 PM, Pacho Ramos pa...@gentoo.org wrote: El mar, 12-02-2013 a las 19:43 +, Fabio Erculiani escribió: I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. I think shouldn't have any problems on providing them also as an alternative, the problem is who would maintain that builds (as I guess Sabayon is using different sources than gentoo and, then, probably not all chosen options for Sabayon will work on Gentoo :/) If the goal is providing a general purpose kernel that's based on genpatches (plus BFQ and aufs3) and could be used in official live images, the current sabayon kernels could work just fine for Gentoo. They are coming directly from Linus' (or gregkh for stable releases) git repo. Upstreaming sabayon-kernel.eclass and kernel binary ebuilds is something I'd be interested in, as long as other devs here are willing to help me out as well. But I don't want to go off-topic too much. -- Fabio Erculiani
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 10/02/13 10:10, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013) # The firmware cleanup, part #1. Can be unmasked after # cleaning up the package if it's still needed. # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: # emerge -av linux-firmware # If you still have a reason to keep the package, please # let us know by filing a bug report. net-wireless/ipw2100-firmware net-wireless/ipw2200-firmware These two got unmasked after cleaning up the ebuilds. net-wireless/prism54-firmware This one doesn't have license, moved to it's own mask. And new masked package because it's in linux-firmware: net-wireless/i2400m-fw
RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 10:10:51 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013) # The firmware cleanup, part #1. Can be unmasked after # cleaning up the package if it's still needed. # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: # emerge -av linux-firmware # If you still have a reason to keep the package, please # let us know by filing a bug report. net-wireless/ar9271-firmware I didn't know linux-firmware exists at all when added that to the tree (SRC_URI=http://linuxwireless.org). Fine by me. The source of confusion was non-working device by default. Maybe 'IUSE=+firmware; RDEPEND=firmware? ( sys-kernel/linux-firmware )' for virtual/linux-sources would help user experience a bit. Sometimes firmware loader does not even write fw file it expects to be present on FS in dmesg (like certain broadcom drivers) thus it's nontrivial for user to figure out needed package to be installed. Thanks! -- Sergei signature.asc Description: PGP signature
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
El dom, 10-02-2013 a las 17:46 +0300, Sergei Trofimovich escribió: [...] The source of confusion was non-working device by default. Maybe 'IUSE=+firmware; RDEPEND=firmware? ( sys-kernel/linux-firmware )' for virtual/linux-sources would help user experience a bit. Sometimes firmware loader does not even write fw file it expects to be present on FS in dmesg (like certain broadcom drivers) thus it's nontrivial for user to figure out needed package to be installed. Thanks! I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: net-wireless/b43-firmware net-wireless/b43legacy-firmware These are neither of the above. I also don't understand masking packages because the firmware is in linux-firmware. Is this an official policy? Sometimes firmware packages are slotted, and it's also easier to install a package than list and update a changing set of firmware files in /etc/portage/savedconfig/sys-kernel/linux-firmware (referring to ar9271, rt2860, rt2870, i2400m). On the other hand, firmware is often very stable, so why mask a package just because it has no maintainer? Who wins by having atmel, or zd1201/zd1211 masked? There are no open bugs, so what's the point? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 03:10 AM, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (10 Feb 2013) # The firmware cleanup, part #1. Can be unmasked after # cleaning up the package if it's still needed. # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: # emerge -av linux-firmware # If you still have a reason to keep the package, please # let us know by filing a bug report. net-wireless/ar9271-firmware net-wireless/atmel-firmware net-wireless/b43-firmware net-wireless/b43legacy-firmware net-wireless/ipw2100-firmware net-wireless/ipw2200-firmware net-wireless/libertas-firmware net-wireless/prism54-firmware net-wireless/rt2860-firmware net-wireless/rt2870-firmware net-wireless/rt61-firmware net-wireless/rt73-firmware net-wireless/rtl8192su-firmware net-wireless/zd1201-firmware net-wireless/zd1211-firmware (I hope I didn't step on anyones toes here. It was certainly not the intention.) atmel-firmware ipw2100-firmware ipw2200-firmware b43-firmware b43legacy-firmware rtl8192su-firmware zd1201-firmware zd1211-firmware None of these are blockers on linux-firmware, none of these are included in linux firmware, none of these should be masked with no replacement as we are breaking approximately 90% of wifi cards on laptops built in the last 5 years. Only the following acctually show masked when I update: - -net-wireless/atmel-firmware - -net-wireless/b43-firmware - -net-wireless/b43legacy-firmware - -net-wireless/rtl8192su Due to the damage this will cause I am removing the mask on these NOW, I will cleanup the ebuilds today but this is bad, really really bad. If we are cleaning up linux-firmware that's great, but someone needs to check that the things we are masking/removing are actually in linux-firmware... Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRF8i0AAoJEKXdFCfdEflKtbEP/1juLtMGpSw7inSnDLJQx5+a aEFASrcmt9tK3aiYHfdOV09sNHAbiDWUNEM82OLH+yDbZwsiVQTgYnUutQelCo4g B6Zdn9PoFoloAP0TbSfE24NI+BO9Z9rvM9NwHKTmejbKlihhzyhLINkrZM/qzM7j yLSTrTyR2BKilC5bdSmJBgFrYOaWrsexNVZaB00x7eXNSIfBIZtR3LnVqFmMMsaO ZiWFCGHTCRcm7MYbRcNxtS6cA4c/PeiKDbbfEqp8izMSux0ESLZtOPaE5O54uCyi Bc8Th7gd6q4x/FxqYWj8Uq40oiEe1nRArgEbj9gHTvPTur9pvdTfCzIHh+qfV3TW KnEyBJh1cUORnnNpxhJa3dkhT2Zx8s4ebsN6sfsXn3U8iJ9NE5vjz+gF6f4FJ8aH NOuCj5y4LsgUwqoz4T/wpXvN1AlKCueyQ8w6P+RYtfTxZY8yWCnqmux0IFmyCLVj nxhz/Ib9RAUjivdqd4PfcVtZhl42OU4jcNxPCJrpw6Ss07RBEw9+u0kE/kfkSRGT Jn5WFa4vJyLqb7lg0FDDm6ijL5o811CQ7kaDcc1h9RjmgrW3nIusokNMkZnP+dE6 BIVgTlX564rcWsKeU9gmP7C68DSVCVr7zyEbSm9/DajJny4dbHSNUUvBNEQUde6j /iVU0w4Af3YwKJ10KEjo =D6qM -END PGP SIGNATURE-
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
I agree as I have also needed to google and search in forums to get
proper firmware installed in the past in some machines :/
for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
-n 's/^firmware=//p' | sort -u); do
if [ ! -e /lib/firmware/${fw} ]; then
echo ${fw}
fi
done
I guess you can do something similar with vmlinux.bin if compiling
modules into kernel. Looking into kernel sources is more robust, but
gets annoying fast. Full script I am using is here:
https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares
You can encounter superfluous warnings with modules that support
multiple firmware subversions (e.g., iwlwifi).
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote: I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). Cheers, Dirkjan
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 6:49 PM, Dirkjan Ochtman d...@gentoo.org wrote: (I guess older kernel sources came with the firmware?) See e.g. https://bugzilla.kernel.org/show_bug.cgi?id=42689#c5 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote: I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Cheers, Dirkjan -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? I'm sorry, I have no clue about any of this; I was just signalling that I've run into problems twice now, where I: - had an old kernel working fine - upgraded it using the usual mechanism - then the network wouldn't come up on rebooting (bnx2 or tg3, not sure) - with an obscure error message that was really quite hard to connect to missing firmware, and - it turned out to work fine after installing linux-firmware. So it would be great to prevent other users from running into these kinds of trouble. Cheers, Dirkjan
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 10:55 AM, Maxim Kammerer wrote: On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: net-wireless/b43-firmware net-wireless/b43legacy-firmware These are neither of the above. I also don't understand masking packages because the firmware is in linux-firmware. Is this an official policy? Sometimes firmware packages are slotted, and it's also easier to install a package than list and update a changing set of firmware files in /etc/portage/savedconfig/sys-kernel/linux-firmware (referring to ar9271, rt2860, rt2870, i2400m). On the other hand, firmware is often very stable, so why mask a package just because it has no maintainer? Who wins by having atmel, or zd1201/zd1211 masked? There are no open bugs, so what's the point? Honestly while I agree this could have been handled a little more carefully we all win by having ONE place for firmware. The firmware package is like 20MB, if you don't have that much free harddrive space then you can use the savedconfig option to tune for just your hardware but honestly this package is rather critical for any system that does wifi or video capture and a few other things. I don't want to have to hunt and find firmware packages, the ones that are seperate due to license issues (read: Broadcom) will stay seperate, the rest I'll be poking upstream about including in the firmware tree then killing. Having 300 -firmware packages is silly. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGAXwAAoJEKXdFCfdEflK+xgP/A0F+XHiZLXo5D6rqvavyocE cKJh/E3fSMB5QcqVhK/kWXhcjDiRz+5niMR30oMX05uwvbx6Fo8Kicne6XHw9fhv UHo5E/k5e6lwaPOeI2nr59XaQ7Pj8PbhL9xrGA+CF1Yx7tJ2DqvEzYzOsuHlZG+B /yrFFKQ2TGeftXpKVYY9iQH3pHCzOR5P40PURwW0onvx5Q2LunAVpOmUO520jL3h dGoPWhjxK8RxpCOp/KbzxR27SD8kSWjgROmXpoIG0cfmohk/wfSwHyqg+i3pYDu8 b9Fs0OeOMnu2AxVeBCWHGFITeDz/0XVxlBThbzPj2KTnyQXoWfOHvOmGY9RxhJwh Cye/vWepdzUa7Vsdj37JiGfaHh9F68UwT50OelR1HJYjJHvaMbZZAfvsbENWSzn4 +esRhFxEyF7bk70+n6RXAFTx/mMPCwoADSgIqqwy/Bv5R/Z0b3hWlF3GWVeR3nRc Kd6kqifjYf8uVoUPAe1G5k5J+lQyyEva0Y93ML20y3pR0Ya3kJRioYxY1i2UdfVx reB1R3t/5O62dEXcyHyJeNfKYUef3fTjz4ieNhbvvmn/VueklyNJL0wmGwLCwMJn 92uYVpU0hdQFPxNZc5rHavnB6MOl49y/68/rNEaRhUe5Y38DNKEE5zL94sMXF4pf f4wQkVOOpYFdvaTRLQRR =Pn47 -END PGP SIGNATURE-
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 11:54 AM, Fabio Erculiani wrote: On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote: I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? The number of collisions has been reduced drastically in the last ~year, I don't believe there are actually any left now. I think the kernel has almost entirely stopped shipping firmware. It may be time to make linux-firmware an RDEPEND of *-sources - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGAahAAoJEKXdFCfdEflKz2cP/2BbuvVsYgMUHGwuD8Xs5/Iw 70Q1QyXY4SIQGh5p/YZ0XX6Z1uzGGUAwAm2tWbsFUT6VFZWyb0p/Wl5Rf3Vtn9eO 4DXx4JoKPI12bFEbJuhCMe67e01A3h88j/lp0fE372MTDUcutl3FF+i34zz/DckU NGEVw9+IxPxxuohTT+llzPE+3gd1j1LOSL+msv5nFwcKn940iOujLpDvpiscGD68 HBb5lcyxuKcV5XBlG3oRZ8+rP1A0vW2qyMm4/IXHMEehro1N3JxMpYQq+NcUrGT8 tlAHYW4C6+Z7b8zr9kEUbuDVI1dx+AM/MXbd8bdfpSWjnrk9NCnV5Y9mTBaNJB61 kn+CEQIaGi3aNBOzVBfo02ZGONZh7c178uIa7+Lh0deyENdlptU/UdD8wNf1PCK4 MCxsLzuJ6zb0XzaxJaY5snoZ+r8pHPrMUZFv8F0ls3y4maiGQMc48MOy4mJ90hYd 52HF3tjM2H0q7KNasKgP/u4DKylRiAWEvCS7uLF/6mUA74Ph9OVac+BJeUQSVsKh 4606UogOgk03IlBmNiyj41t3auX/MfqGYa3kBdftmFHURMOx1GPL5wqibRdzQ1T6 G8ojPdKxARHowkC9oAYljO6kUoQFD/mBN53KhvoCcu83n1rfvJ2hNBlkais8jEw6 PT7FeADuNUixau15F5jm =rqzh -END PGP SIGNATURE-
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 February 2013 Maxim Kammerer m...@dee.su wrote:
On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
I agree as I have also needed to google and search in forums to get
proper firmware installed in the past in some machines :/
for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
-n 's/^firmware=//p' | sort -u); do
if [ ! -e /lib/firmware/${fw} ]; then
echo ${fw}
fi
done
I guess you can do something similar with vmlinux.bin if compiling
modules into kernel.
Last I looked into that the list of firmwares needed by built-in drivers
is not available as is the case for modules (and in addition those
built-in drivers may need the firmware long before /lib/firmware/ is
available)
Bruno
Looking into kernel sources is more robust, but
gets annoying fast. Full script I am using is here:
https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares
You can encounter superfluous warnings with modules that support
multiple firmware subversions (e.g., iwlwifi).
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Sun, Feb 10, 2013 at 10:41 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Honestly while I agree this could have been handled a little more carefully we all win by having ONE place for firmware. The firmware package is like 20MB, if you don't have that much free harddrive space then you can use the savedconfig option to tune for just your hardware It's ~45MB when extracted, but the issue is not just with space, since on a proper Gentoo system firmware is about the only thing that's not compiled from source (besides less significant stuff like fonts, many of which can be optionally compiled anyway). Combined with various less-than-free licenses, installing one huge blob of firmware is problematic for many users, also from a security point of view. Having 300 -firmware packages is silly. I agree, but think that the process can be more user-friendly than a savedconfig — perhaps a variable as was suggested already. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 1:06 PM, Bruno bonbon...@internet.lu wrote:
On Sun, 10 February 2013 Maxim Kammerer m...@dee.su wrote:
On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
I agree as I have also needed to google and search in forums to get
proper firmware installed in the past in some machines :/
for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
-n 's/^firmware=//p' | sort -u); do
if [ ! -e /lib/firmware/${fw} ]; then
echo ${fw}
fi
done
I guess you can do something similar with vmlinux.bin if compiling
modules into kernel.
Last I looked into that the list of firmwares needed by built-in drivers
is not available as is the case for modules (and in addition those
built-in drivers may need the firmware long before /lib/firmware/ is
available)
Most external firmware is not needed to boot. If you need it to boot,
you will have to stow it in the initramfs.
-A
Bruno
Looking into kernel sources is more robust, but
gets annoying fast. Full script I am using is here:
https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares
You can encounter superfluous warnings with modules that support
multiple firmware subversions (e.g., iwlwifi).
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Combined with various less-than-free licenses, installing one huge blob of firmware is problematic for many users, also from a security point of view. How does having additional firmware installed affect security at all? Firmware is only loaded when specifically requested by a loaded driver that needs to use it, and only if that driver is actually in use. That's like saying a file that can only be written to by root, only normally read when it's specifically needed, and if for some stupid reason is executed by an unprivileged process will just result in a crash, affects security (hint: I just described firmware). -Doug
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 04:45 PM, Maxim Kammerer wrote: On Sun, Feb 10, 2013 at 10:41 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Honestly while I agree this could have been handled a little more carefully we all win by having ONE place for firmware. The firmware package is like 20MB, if you don't have that much free harddrive space then you can use the savedconfig option to tune for just your hardware It's ~45MB when extracted, but the issue is not just with space, since on a proper Gentoo system firmware is about the only thing that's not compiled from source (besides less significant stuff like fonts, many of which can be optionally compiled anyway). Combined with various less-than-free licenses, installing one huge blob of firmware is problematic for many users, also from a security point of view. Licenses are licenses, we all feel the same about non-free things. I whole heartedly disagree about the firmware, having a firmware on your system doesn't affect security, sorry, it just doesn't. Having 300 -firmware packages is silly. I agree, but think that the process can be more user-friendly than a savedconfig — perhaps a variable as was suggested already. I am marked maintainer of linux-firmware due to my desire to make sure wifi related things work. I have no desire at all to implement use expand for this, HOWEVER, I am willing to accept a patch for that if it comes out even close to sane. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGDKiAAoJEKXdFCfdEflKBYkQAItoT8QdhnP4V0Nu+BkUqozP fPzDQjPbIXh0JMuVJ56zmXZ5oeiClFdcysf7vZ2sLFl4d2UPsz5EC+5Bk9ryJvjg YrLRmT5cHuZYacW7hNTgfW7Z3gg9oqJU73dn6rUvu3dGUlN3w/Z9UGXeIj+yzmzR w65pD9DLcQ4kPN5ekOhhznaCLANW7cVVQ4FgNDPZwAGpeUd/+OMlltNFrCcF4p4Z /cleFDfZmw01iO86oXKkAoevD7M1Twa9aHqNwxb6xcdagmPSnXhD+TsIFAvZgsdU +5xHL3sD6v5GJHf17lZvkHQxzKFVBqMJmuBW4lx599RDh5QgHK/RMC9bti9+adAu JNEQfC6VBQ48azrhc8BF/5bqZ5E0Rghppr7SRpjM5no0FDeGLo6Um47WTAY15CWj e2xqDJw1S7tWfPjqzz0IEUGHNCHfhm3s+kEQ6uYOuMqRXlJREhZ44PjxLsHBSOQs e+WHj23LujoJ5XqmtTQlMwTa+hzSUR+a8tUmrEu15uwiZWV4wsyoLhdNEPE5cAU5 s4/E10eVmuN65Lz7hYFTBy+irA5r3ugP43m4TzegrkclroCPbSbf65GcDk32hlTO qpw3xjEdcXu+ltUJgaNFueC57N0fPaZBNdPuyQKa1pSxHgfJvl6GiO8EWFqtM66s t2rv7REVyIgt8zPYRb08 =9fk8 -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Mon, Feb 11, 2013 at 1:12 AM, Douglas Freed dwfr...@mtu.edu wrote: How does having additional firmware installed affect security at all? Firmware is only loaded when specifically requested by a loaded driver that needs to use it, and only if that driver is actually in use. That's like saying a file that can only be written to by root, only normally read when it's specifically needed, and if for some stupid reason is executed by an unprivileged process will just result in a crash, affects security (hint: I just described firmware). I can play captain obvious, too. Regardless, having to explicitly enable firmware based on need (e.g., after installing a wireless card) provides for more security. For instance, the user can opt to not enable the firmware and not use the card, if he doesn't trust manufacturer's software development process. If only the firmware that is actually used is installed, it is easier to go over it and review its security. Some firmware has multiple subversions, with the kernel being able to use any of them; some may be more trusted than others. Some firmware may be unnecessary for correct functioning of hardware, but is still loaded when available. All of these are valid reasons for not installing all possible firmware. Don't assume that your use case is identical to everyone else's. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Mon, Feb 11, 2013 at 1:52 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I am marked maintainer of linux-firmware due to my desire to make sure wifi related things work. I have no desire at all to implement use expand for this, HOWEVER, I am willing to accept a patch for that if it comes out even close to sane. It is possible to start with something much simpler but still very useful: savedconfig in rsync include format, for glob patterns support. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 07:18 PM, Maxim Kammerer wrote: On Mon, Feb 11, 2013 at 1:52 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I am marked maintainer of linux-firmware due to my desire to make sure wifi related things work. I have no desire at all to implement use expand for this, HOWEVER, I am willing to accept a patch for that if it comes out even close to sane. It is possible to start with something much simpler but still very useful: savedconfig in rsync include format, for glob patterns support. Again, I don't have the time (or desire) to implement this at this time. If you have an idea which you think will be sane and an improvement then by all means, please submit it to me when you are ready. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGD6JAAoJEKXdFCfdEflKnJYQAKsW3Mqk9/ru47FekY6DEqYZ 3ebMgPSAe99Pqdm2XhDknlZnAxL5/yAdQnls5TWEFqAx7GynaJ3fwpHBtoOa0pp+ tVmS3a/J86McaNQfisMekFnY70fJBw8hT+w343UKIx51RLuQGPTiWK26dku4MnCc hkVjFQCzxPeayxXslWKblo8Fi3nD2XQxgejeXsXcEddli5WRXgVhO+GPea6KgeTW qnpj7x1dqEAqFWewx0Os843GK6hwmdWo3O0y9GcAjyyI8H9+age2A6qDaqevs2dK L7qBr13moyeENnVoJSDFr9KZ0y9u3dI/+8Ap8MUn8yI1hB92bRuH9CldN2rOgNir /a1zcDs4NNwzimZ1P8/NyD71mP9SJhQkKPdnDeMj+Ck6iUB9bpEqXERAhckmamzt 0O8udf88++5MiuFNW6ju3/VOpS+MV0rFXLztDgVOXoUvE/e2O6MgUnlo0+Mr9EHJ tribU2UlvkkLyfnw44pfkv1zuo/gFkImjlZTOGzfW5iBwdi47dXh7447CoKUHFs+ OWnCAy9c/461uAUD6rizgKXO9tYfxZPBKdEpmJJiBmUz07q86lylKvzCSC0eAcTh ZOjKS5nbxlqjzstEpcDBrFYrPamFzJHg1q3VeN0+WrA6bhZxXm0RMWpfr2L0aztc kS2EoEhpdBjDUj7RmMZk =pPeq -END PGP SIGNATURE-
