[gentoo-dev] Lastrite: Firmware cleanup, part #1

[gentoo-dev] Lastrite: Firmware cleanup, part #1

[Samuli Suominen]

# Samuli Suominen <ssuominen@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.)

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Samuli Suominen]

On 10/02/13 10:10, Samuli Suominen wrote:
> # Samuli Suominen <ssuominen@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)

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Sun, 10 Feb 2013 10:10:51 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> # Samuli Suominen <ssuominen@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

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 :/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Maxim Kammerer]

On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos <pacho@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)

[Bruno]

On Sun, 10 February 2013 Maxim Kammerer <mk@dee.su> wrote:
> On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos <pacho@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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Alec Warner]

On Sun, Feb 10, 2013 at 1:06 PM, Bruno <bonbons67@internet.lu> wrote:
> On Sun, 10 February 2013 Maxim Kammerer <mk@dee.su> wrote:
>> On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos <pacho@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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Christopher Head]

On Sun, 10 Feb 2013 14:49:03 -0800
Alec Warner <antarus@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

[gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Duncan]

Christopher Head posted on Tue, 12 Feb 2013 11:39:57 -0800 as excerpted:

> On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner <antarus@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.

I'm a monolithic kernel guy myself, and I simply build-in the firmware I 
need (three radeon firmware files, IIRC, used to be tg3 as well until 
that mobo died).  Obviously there can be issues with distribution, but 
purpose-built monolithic kernels aren't generally practical for 
distribution anyway, and the GPL has always been clear that it doesn't 
interfere with end-user rights in terms of build-combining whatever they 
want, as long as there's no further distribution.

And FWIW, I didn't really know about linux-firmware either, but google 
knew when I asked it about the files the kernel errors spit out. =:^)  
And I didn't actually install it, either.  I simply grabbed the tarball 
and extracted the files I needed, placing them where the kernel could 
find them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Michael Weber]

On 02/12/2013 09:43 PM, Duncan wrote:
> Christopher Head posted on Tue, 12 Feb 2013 11:39:57 -0800 as excerpted:
> 
>> On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner <antarus@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.
or the kernel itself ...
>>
>> 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.
> 
> I'm a monolithic kernel guy myself, and I simply build-in the firmware I 
> need (three radeon firmware files, IIRC, used to be tg3 as well until 
> that mobo died).  
dito.

> And FWIW, I didn't really know about linux-firmware either, but google 
> knew when I asked it about the files the kernel errors spit out. =:^)  
> And I didn't actually install it, either.  I simply grabbed the tarball 
> and extracted the files I needed, placing them where the kernel could 
> find them.
from cross distro source etc.
I wonder how that linux-firmware serves it all will handle different
versions of one firmware-filename with disjunct sets of supported
hardware revisions.
Random files in /lib/firmware out of packet manager space it is (form me).


-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Chí-Thanh Christopher Nguyễn]

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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Dirkjan Ochtman]

On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos <pacho@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)

[Maxim Kammerer]

On Sun, Feb 10, 2013 at 6:49 PM, Dirkjan Ochtman <djc@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)

[Fabio Erculiani]

On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos <pacho@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)

[Dirkjan Ochtman]

On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani <lxnay@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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Christopher Head]

On Sun, 10 Feb 2013 20:43:02 +0100
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani <lxnay@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)

[Fabio Erculiani]

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)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

El mar, 12-02-2013 a las 19:43 +0000, 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 :/)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Fabio Erculiani]

On Tue, Feb 12, 2013 at 7:47 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> El mar, 12-02-2013 a las 19:43 +0000, 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

[gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Duncan]

Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as excerpted:

> On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman <djc@gentoo.org>
> wrote:
> 
>> On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani <lxnay@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?).

>> > For starters, if kernel sources provide /lib/firmware, how do you
>> > deal with file collisions?
> 
> 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.

Not a problem as long as the RDEPEND is under USE=firmware or similar.
No USE=firmware, no rdepend!  =:^)

Kernel sources providing /lib/firmware itself shouldn't be a problem 
either, as that's just a dir, which many packages may own.  The 
individual firmware files would be a problem, but the USE=firmware RDEPEND 
solution should solve that.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Christopher Head]

On Tue, 12 Feb 2013 20:51:15 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as
> excerpted:
> 
> > On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman <djc@gentoo.org>
> > wrote:
> > 
> >> On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani <lxnay@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?).
> 
> >> > For starters, if kernel sources provide /lib/firmware, how do you
> >> > deal with file collisions?
> > 
> > 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.
> 
> Not a problem as long as the RDEPEND is under USE=firmware or similar.
> No USE=firmware, no rdepend!  =:^)
> 
> Kernel sources providing /lib/firmware itself shouldn't be a problem 
> either, as that's just a dir, which many packages may own.  The 
> individual firmware files would be a problem, but the USE=firmware
> RDEPEND solution should solve that.
> 

Yes, of course, I meant please don’t depend unconditionally. A
conditional depend is fine by me, and I don’t care about one random
directory being created—I just don’t want a whole package being pulled
in for nothing.

Chris

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/12/2013 05:30 PM, Christopher Head wrote:
> On Tue, 12 Feb 2013 20:51:15 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as
>> excerpted:
>>
>>> On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman <djc@gentoo.org>
>>> wrote:
>>>
>>>> On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani <lxnay@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?).
>>
>>>>> For starters, if kernel sources provide /lib/firmware, how do you
>>>>> deal with file collisions?
>>>
>>> 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.
>>
>> Not a problem as long as the RDEPEND is under USE=firmware or similar.
>> No USE=firmware, no rdepend!  =:^)
>>
>> Kernel sources providing /lib/firmware itself shouldn't be a problem 
>> either, as that's just a dir, which many packages may own.  The 
>> individual firmware files would be a problem, but the USE=firmware
>> RDEPEND solution should solve that.
>>
> 
> Yes, of course, I meant please don’t depend unconditionally. A
> conditional depend is fine by me, and I don’t care about one random
> directory being created—I just don’t want a whole package being pulled
> in for nothing.
> 
While much of this thread is un-actionable I believe this is a good idea
to do.

What is everyone's opinion of adding a USE=firmware option to pull in
PDEPEND="linux-firmware" in linux-2.eclass?

Thanks,
Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRHyO1AAoJEKXdFCfdEflKV/UQAI3NTvDcGQs7hjzhkecIgxNh
11OLTv43CxLRUg4OeYJppeavxvV//LPIdroVUS2e7GgF3fQ++8HKa5s9xUzi7pmy
FoWgzoTG+IeTu7NF6MVMbyLO1hhH59+TEapBn4IFE4Da7qgK+3JrbF7Lx4cpxgnL
s7pJxQ2Fvm6x8Bz7NUwi4R1xnYKUJhEvxOJVCtWeChjr8c2u0zHahHnmAs9bdyeF
pnE4O7RD4I+lBUNI4kJGVM8EMK31LwFLgfyHkX8mPUyXQ9rA5+ofnxAHRIuV2zEA
g1f59f8b46VUy3mAJ296EXz//GZ+KxMtucAAwNLpEHEKoEj4Ypyb7rfQTlsSxUXu
kXVpB7bcDah5wT4i++UFpzzTx+wLVUxgOf/idRCUqDB8l2VqSSIqq6yJ+YA3eLoY
wCd9wEXR2sHaHxlwYvakMr0na3lAMIopPAM0t/0cwwIJYXlScYw6f5iEUDSo1if6
B+pUw7Hst4XsRWcQpzfjnR3tiKK9U7vTc58blz7pkkZo2cV/+PLlFzQf+WlPaxzU
ZRzcxoZnQFDifu/eXLQdVNzIfAuAzCYXiU2Rv3gowmwXlUuCQiyYcYUioCMRwFwt
7yPEXIGsMCX02sjLammF9ZM2RdyKjt/daKc1vMU29aMF/WB8T1nYUKVY/XZmJ+YR
YrDEf3MaIKbKoXXRuINy
=y/cz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Maxim Kammerer]

On Sat, Feb 16, 2013 at 8:14 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
>>> Kernel sources providing /lib/firmware itself shouldn't be a problem
>>> either, as that's just a dir, which many packages may own.  The
>>> individual firmware files would be a problem, but the USE=firmware
>>> RDEPEND solution should solve that.
>>
> What is everyone's opinion of adding a USE=firmware option to pull in
> PDEPEND="linux-firmware" in linux-2.eclass?

Not exactly an opinion, but a couple of notes:

1. Kernel's "make modules_install" triggers "make firmware_install",
which installs a strict subset of linux-firmware (for enabled modules
— e.g., "3com/typhoon.bin"). A way to work around that is to supply
INSTALL_FW_PATH=... to make.
2. CONFIG_PREVENT_FIRMWARE_BUILD=y does not prevent installing
firmware by "make modules_install".
3. Trough all this firmware discussion, everyone is acting as if it's
obvious that linux-firmware was always preferred to individual
packages. This is not the case — some Gentoo developers didn't even
know about linux-firmware when creating individual packages, as is
evident from messages in discussion. I tried to figure which to use
some time ago, and came to conclusion that more often than not,
individual packages are preferable, because they are versioned/slotted
and go through a proper stabilization process (e.g., iwlwifi). Perhaps
that conclusion was incorrect, but the point is that information on
the subject was scarce, to say the least.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/16/2013 10:29 AM, Maxim Kammerer wrote:
> On Sat, Feb 16, 2013 at 8:14 AM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>>>> Kernel sources providing /lib/firmware itself shouldn't be a problem
>>>> either, as that's just a dir, which many packages may own.  The
>>>> individual firmware files would be a problem, but the USE=firmware
>>>> RDEPEND solution should solve that.
>>>
>> What is everyone's opinion of adding a USE=firmware option to pull in
>> PDEPEND="linux-firmware" in linux-2.eclass?
> 
> Not exactly an opinion, but a couple of notes:
> 
> 1. Kernel's "make modules_install" triggers "make firmware_install",
> which installs a strict subset of linux-firmware (for enabled modules
> — e.g., "3com/typhoon.bin"). A way to work around that is to supply
> INSTALL_FW_PATH=... to make.
> 2. CONFIG_PREVENT_FIRMWARE_BUILD=y does not prevent installing
> firmware by "make modules_install".
> 3. Trough all this firmware discussion, everyone is acting as if it's
> obvious that linux-firmware was always preferred to individual
> packages. This is not the case — some Gentoo developers didn't even
> know about linux-firmware when creating individual packages, as is
> evident from messages in discussion. I tried to figure which to use
> some time ago, and came to conclusion that more often than not,
> individual packages are preferable, because they are versioned/slotted
> and go through a proper stabilization process (e.g., iwlwifi). Perhaps
> that conclusion was incorrect, but the point is that information on
> the subject was scarce, to say the least.
> 

1.) No new firmware is being added to the linux kernel anymore, so this
doesn't apply at all.
2.) Fun fact but I don't see how that make much difference to anyone or
this thread.
3.) I'm sorry if it is not yet obvious to people that this is a package
upstream has been moving slowly towards requiring, but, they have.  My
email was SPECIFICALLY addressing this by suggesting that we add it as a
pdep (optionally) to show people just how important it is.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIGXGAAoJEKXdFCfdEflKIuEQAIrB+R3ADrgdG5Q7aqUTy3+H
o1K0eEpBKMg6Fi8q9um0b2mxw0lqUAgeob+RdKzkaFATueFmLB8DU8BUBr3RTSxe
XxQ2KcAsfJxWqBcHx/wFwqXyVkink+AhXg/956hUa0I3TpSjsc7BkPHjIaJw3QBb
AjwpUpr9T0CVpovTQ8LcFaNfxIH1kHcXku0cX8ZC72vXEDZN9My9QBGPsH6HTYPE
TA6PSviBQimODookyaAYgkOzBlqDA98ClZb7sY7zmo4Ca/e0wC3eSVexwNxo7Nfr
+4mMzTy8TPwv7hckAgZiOzDQ7RQKC+s7f2/gHXNENb9ittd8aBc982tfxlF6wTgc
PHXsn+owgA/VQsVlyMw6ctUFgW3lDeQBuc9/WPgGXvfTvSUQ1ROhg7DmBH7Iyr1C
8l04sL3kmZ9PqAw2j13Kf56mxFaFA+L/uwhV6cAw2rEpLpIfvwV9trR+BmO69Hem
tph58uh6cGXfWOXtUM+kEacXswvWpLi0yD8/g3WH8jbkGBIobKf6deYcbkPjZWyQ
STm/Qq6xHyibpBBBZWgungvSG5gvf+73crq+femjKUgB7yCVnXaMrTODSXVKhkX0
sZ+K+Bp5XqexVGlcbLvtXmIW7OJB4L7Yiml5zzx6Vqu/hMld/CSdLo/3rLf2TCSW
IhfHQl5LKrFt0MGyFLR/
=n36q
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

Regarding licensing issues, maybe we could take fedora package as
reference for clarifying firmware licenses and so:
http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Maxim Kammerer]

On Sun, Feb 17, 2013 at 7:08 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> 1.) No new firmware is being added to the linux kernel anymore, so this
> doesn't apply at all.

Of course it applies — interaction of "make modules_install" with
emerging linux-firmware can result in collisions. And before you write
yet another dismissive email — yes, I know that for users not using
savedconfig there will most likely be no collisions due to kernel's
modules_install overwriting existing files.

> 2.) Fun fact but I don't see how that make much difference to anyone or
> this thread.

It is relevant in the sense that it is not straightforward to prevent
the kernel from installing firmware in /lib/firmware, which might
result in collisions.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Chí-Thanh Christopher Nguyễn]

Maxim Kammerer schrieb:
> On Sat, Feb 16, 2013 at 8:14 AM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>>>> Kernel sources providing /lib/firmware itself shouldn't be a problem
>>>> either, as that's just a dir, which many packages may own.  The
>>>> individual firmware files would be a problem, but the USE=firmware
>>>> RDEPEND solution should solve that.
>> What is everyone's opinion of adding a USE=firmware option to pull in
>> PDEPEND="linux-firmware" in linux-2.eclass?
> Not exactly an opinion, but a couple of notes:
>
> 1. Kernel's "make modules_install" triggers "make firmware_install",
> which installs a strict subset of linux-firmware (for enabled modules
> — e.g., "3com/typhoon.bin"). A way to work around that is to supply
> INSTALL_FW_PATH=... to make.

Most if not all such conflicts can be avoided by USE="deblob"

Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)

[Chí-Thanh Christopher Nguyễn]

Rick "Zero_Chaos" Farina schrieb:
> What is everyone's opinion of adding a USE=firmware option to pull in
> PDEPEND="linux-firmware" in linux-2.eclass?

No, USE flags that trigger only dependencies and do not change the
package should be restricted to virtuals or metapackages, with as few
exceptions as possible.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Rick "Zero_Chaos" Farina]

-----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 <djc@gentoo.org> wrote:
>> On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos <pacho@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)

[Chí-Thanh Christopher Nguyễn]

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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Chí-Thanh Christopher Nguyễn]

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)

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Peter Stuge]

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)

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Peter Stuge]

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)

[Chí-Thanh Christopher Nguyễn]

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)

[Graham Murray]

Peter Stuge <peter@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)

[Michael Weber]

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 <xmw@gentoo.org>

Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)

[Samuli Suominen]

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

[Maxim Kammerer]

On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen <ssuominen@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

[Rick "Zero_Chaos" Farina]

-----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 <ssuominen@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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Maxim Kammerer]

On Sun, Feb 10, 2013 at 10:41 PM, Rick "Zero_Chaos" Farina
<zerochaos@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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Douglas Freed]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 710 bytes --]

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Maxim Kammerer]

On Mon, Feb 11, 2013 at 1:12 AM, Douglas Freed <dwfreed@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

[Rick "Zero_Chaos" Farina]

-----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
> <zerochaos@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

[Maxim Kammerer]

On Mon, Feb 11, 2013 at 1:52 AM, Rick "Zero_Chaos" Farina
<zerochaos@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

[Rick "Zero_Chaos" Farina]

-----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
> <zerochaos@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-----

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Chí-Thanh Christopher Nguyễn]

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

[Chí-Thanh Christopher Nguyễn]

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

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Alec Warner]

On Wed, Feb 13, 2013 at 5:39 AM, Chí-Thanh Christopher Nguyễn
<chithanh@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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Rick "Zero_Chaos" Farina]

-----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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/2013 03:10 AM, Samuli Suominen wrote:
> # Samuli Suominen <ssuominen@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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Chí-Thanh Christopher Nguyễn]

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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Rick "Zero_Chaos" Farina]

-----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

[Samuli Suominen]

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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Rick "Zero_Chaos" Farina]

-----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: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

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ò <flameeyes@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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Alec Warner]

On Sat, Feb 16, 2013 at 5:52 AM, Diego Elio Pettenò
<flameeyes@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ò <flameeyes@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
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
>

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1

[Peter Stuge]

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

[Markos Chandras]

On 16 February 2013 19:31, Peter Stuge <peter@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