[gentoo-dev] Packages up for grabs due lack of time

[gentoo-dev] Packages up for grabs due lack of time

[Pacho Ramos]

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

Due pva lack of time the following packages are now up for grabs:
app-dicts/stardict-freedict-eng-rus
app-doc/gimp-help
app-emulation/e-uae
app-emulation/uae
app-text/cuneiform (proxy maintained)
app-text/mathtex
app-text/yagf
dev-db/gigabase
dev-libs/guiloader-c++
dev-libs/guiloader
dev-libs/judy
dev-libs/xmlrpc-c (proxy maintained)
dev-perl/SpeedyCGI
dev-util/crow-designer
dev-util/oprofile
dev-vcs/monotone (proxy maintained)
gnome-extra/gpointing-device-settings
media-gfx/aewan
media-gfx/transfig
media-gfx/xfig
net-analyzer/smokeping
net-firewall/ufw-frontends (proxy maintained)
net-firewall/xtables-addons (proxy maintained)
net-libs/libmnl
net-libs/udns
net-misc/ipv6calc
net-misc/l7-protocols
net-misc/netkit-telnetd
net-misc/udpxy
net-nds/shelldap (proxy maintained)
net-p2p/eiskaltdcpp (proxy maintained)
sys-devel/qconf
sys-firmware/iwl3945-ucode
sys-firmware/iwl4965-ucode
sys-kernel/linuxwacom-module (proxy maintained)
www-misc/fcgiwrap (proxy maintained)
x11-libs/gtkdatabox


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

Re: [gentoo-dev] Packages up for grabs due lack of time

[Tom Wijsman]

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

On Sat, 16 Feb 2013 14:08:06 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> dev-util/oprofile

Took this one, bumped the version and did some small fixes.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address : TomWij@gentoo.org
GPG Public Key : 6D34E57D

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

Re: [gentoo-dev] Packages up for grabs due lack of time

[Aaron Bauman]

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

On Saturday 16 February 2013 14:08:06 Pacho Ramos wrote:
> Due pva lack of time the following packages are now up for grabs:
> app-dicts/stardict-freedict-eng-rus
> app-doc/gimp-help
> app-emulation/e-uae
> app-emulation/uae
> app-text/cuneiform (proxy maintained)
> app-text/mathtex
> app-text/yagf
> dev-db/gigabase
> dev-libs/guiloader-c++
> dev-libs/guiloader
> dev-libs/judy
> dev-libs/xmlrpc-c (proxy maintained)
> dev-perl/SpeedyCGI
> dev-util/crow-designer
> dev-util/oprofile
> dev-vcs/monotone (proxy maintained)
> gnome-extra/gpointing-device-settings
> media-gfx/aewan
> media-gfx/transfig
> media-gfx/xfig
> net-analyzer/smokeping
> net-firewall/ufw-frontends (proxy maintained)
> net-firewall/xtables-addons (proxy maintained)
> net-libs/libmnl
> net-libs/udns
> net-misc/ipv6calc
> net-misc/l7-protocols
> net-misc/netkit-telnetd
> net-misc/udpxy
> net-nds/shelldap (proxy maintained)
> net-p2p/eiskaltdcpp (proxy maintained)
> sys-devel/qconf
> sys-firmware/iwl3945-ucode
> sys-firmware/iwl4965-ucode
> sys-kernel/linuxwacom-module (proxy maintained)
> www-misc/fcgiwrap (proxy maintained)
> x11-libs/gtkdatabox

May I proxy net-misc/ipv6calc ?

Thank you,
Aaron

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

Re: [gentoo-dev] Packages up for grabs due lack of time

[Diego Elio Pettenò]

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

On 16/02/2013 14:08, Pacho Ramos wrote:
> sys-firmware/iwl3945-ucode
> sys-firmware/iwl4965-ucode

Are these included in linux-firmware (i.e. could we just remove them) or
not?

-- 
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] Packages up for grabs due lack of time

[Peter Stuge]

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

Diego Elio Pettenò wrote:
> > sys-firmware/iwl3945-ucode

I want this installed on my system.


> > sys-firmware/iwl4965-ucode

But not this.


> could we just remove them

Please don't. I think it would suck to lose the higher resolution.

On the plus side it seems that these particular packages would
require very limited effort to maintain. :)


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Packages up for grabs due lack of time

[Samuli Suominen]

On 16/02/13 15:59, Peter Stuge wrote:
> Diego Elio Pettenò wrote:
>>> sys-firmware/iwl3945-ucode
>
> I want this installed on my system.
>
>
>>> sys-firmware/iwl4965-ucode
>
> But not this.
>
>
>> could we just remove them
>
> Please don't. I think it would suck to lose the higher resolution.

Having separate ebuild for every possible firmware is not the way to go 
anyway.

Re: [gentoo-dev] Packages up for grabs due lack of time

[Diego Elio Pettenò]

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

On 16/02/2013 14:59, Peter Stuge wrote:
> Please don't. I think it would suck to lose the higher resolution.

Use savedconfig and stop wasting our collective time for your personal
lazyness.

-- 
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] Packages up for grabs due lack of time

[Rick "Zero_Chaos" Farina]

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

On 02/16/2013 08:44 AM, Diego Elio Pettenò wrote:
> On 16/02/2013 14:08, Pacho Ramos wrote:
>> sys-firmware/iwl3945-ucode
>> sys-firmware/iwl4965-ucode
> 
> Are these included in linux-firmware (i.e. could we just remove them) or
> not?
> 

ozzie firmware # qfile iwlwifi-3945-2.ucode iwlwifi-4965-2.ucode
sys-kernel/linux-firmware (/lib/firmware/iwlwifi-4965-2.ucode)
sys-kernel/linux-firmware (/lib/firmware/iwlwifi-3945-2.ucode)


Yup, we sure can remove them, and if no one beat me to it I will do that
now.

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

iQIcBAEBAgAGBQJRH5qfAAoJEKXdFCfdEflKjiQP/0Ha0GTKy82j7Ce3Wk5Vw/F8
rWOg6SNmpra4VktXnCVLD4Ctm5Zhv+DT1I0LBzEmm6LcUmz/S/QpBI5+H+WiiOrB
ig0Vhbq6GNAO/8iAWOIXYD/hl4xlGX5YfAAix4T7IG50pkbqJp/XcktWrhw+Jgin
FrsHI88JNB5dN+yYs6xle0DiXon9ZFlEOeF1OjCQTe1ynK2+Eam9VQ65x1kZXxvr
zWH02tJvcI+MtCGbvT/IpjXRkh4gDM4jYfvCodpRrQu3lpunV5RNvE91NcxGQuck
jWvDdJvrzYzJqb+tEAImoParRk3fZij5imI9IXaRe9w0Qy0XIeB8icqZa8uahRJy
Peiup4r74SzrbhbCAsj+HwtoZlazblTgLZoc57RsJScJHovVVE5yGpmZbA694zLj
D6phDeqid6C2LLbK0lyB5HTj7/vZhB35QYPVLC6evFNhION/Ixb3AGi8r732fxOu
9Qaogk9mZizZejW9lh8r1eNhB1ZCrTQlrer8GbOBsRe9EDsqQov1rX5t6/Z5vZ1x
Nh6ePhqAk4wxsLdakwJy9q+lHt2Z/rzYlQhccnP4yVNLjrFcEWfP6xKsY7qnnwK9
nvzed0C/4nkgVtclKY438Tje3Ptujnt9xCXYLKxeWt841P2vnrRHl9Cmh74HgDQ0
a50wMFPwOpSkeOBHrC3h
=gyW9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Packages up for grabs due lack of time

[Diego Elio Pettenò]

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

On 16/02/2013 15:41, Rick "Zero_Chaos" Farina wrote:
> 
> Yup, we sure can remove them, and if no one beat me to it I will do that
> now.

Go for it.

-- 
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] Packages up for grabs due lack of time

[Ulrich Mueller]

>>>>> On Sat, 16 Feb 2013, Diego Elio Pettenò wrote:

>> Please don't. I think it would suck to lose the higher resolution.

> Use savedconfig and stop wasting our collective time for your
> personal lazyness.

Huh? Savedconfig isn't a solution for the license issue.

Ulrich

Re: [gentoo-dev] Packages up for grabs due lack of time

[Ulrich Mueller]

>>>>> On Sat, 16 Feb 2013, Diego Elio Pettenò wrote:

> On 16/02/2013 15:41, Rick "Zero_Chaos" Farina wrote:
>> 
>> Yup, we sure can remove them, and if no one beat me to it I will do
>> that now.

> Go for it.

Please don't.

Can we please stop removing individual firmware packages until
sys-kernel/linux-firmware has proper license labels, and allows for
selective installation?

Ulrich

Re: [gentoo-dev] Packages up for grabs due lack of time

[Rick "Zero_Chaos" Farina]

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

On 02/16/2013 10:08 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 16 Feb 2013, Diego Elio Petten￲ wrote:
> 
>>> Please don't. I think it would suck to lose the higher resolution.
> 
>> Use savedconfig and stop wasting our collective time for your
>> personal lazyness.
> 
> Huh? Savedconfig isn't a solution for the license issue.

If he doesn't agree to the license he can use savedconfig to not install
those firmware packages.

Or am I missing your point?

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

iQIcBAEBAgAGBQJRH6JJAAoJEKXdFCfdEflKGUUP/j7VoLpd90VWaiDJLZIrjFeF
544wYvutiau5sqLE2Q7cv8QyuNz/QEjmBANMKNpwl6YQpAichsXOUeeDfzL3KV1U
WG+ntr3xTC/QK1ZoNCRyTg2i5LPEVZvm4kVxVlEpTnNJuYbxYfw+iygq03vL1NqD
iYEdl9Ykp8uOxSP5vykWG8nXYzeXmC/y6h4qTmyeBbtsAsg4ZC5U7bQ/b5au5W+5
quzk+tkWSZabYb/6K/gmTYswcT8Zjs23GLw+8lcqhIm0iTyUl2Ppm4S/1BPBtzPR
posXUTEdJO7+vELQhShSK5JEPZLZZ3d8YF3WM5dP7lnLmf+Qat0nQRTvg53PP/E0
dl4Va6QYa3VXLOTrhSwIB13sVq9JOyH6ZXZ3urQdYJobjGK4b53KF6KhCCwshcBK
TGlKoq+KuQQPy6hTrytsF2/0nGtSsezZ6gneu7LHFm+IzN/tz9Qz0QcEdgEneynG
exReg3M7UKcY/zY/nLBUBWuu27mXCfnM7aJ0NEIXNOsq12Qt3ZCtLyfLeI0eTvWb
LzNELHGmjDTipdPsDLvqqt39nJZ8Gn+dR0W35waP3hVMHXMK3RPNtUHLvpxqhqxy
PIzDki4Anfb793Tm5eCTfHMWiB3eUA5+q0sEZnrGgjxA4AXR1+5Em6ixFD4XdW9u
0oacFahvXMOIT3DlWtC7
=ejGq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Packages up for grabs due lack of time

[Diego Elio Pettenò]

On 16/02/2013 16:08, Ulrich Mueller wrote:
> Huh? Savedconfig isn't a solution for the license issue.

Which Peter's remark is not about.

I do feel we need to fix the license issue, but I don't think this is
compounding anything to clear up the tree first.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Packages up for grabs due lack of time

[Peter Stuge]

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

Diego Elio Pettenò wrote:
> > Please don't. I think it would suck to lose the higher resolution.
> 
> Use savedconfig

linux-firmware is okey but not great. The high resolution is there,
which was my main concern, but it's not so easy to know how to create
a savedconfig without installing the package.

Of course it does save packaging effort, even if just one-time. I'll
get back to you if I have some idea for improving UX.


> <negative words>

I don't know why you think that it's OK to behave any way you like.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Packages up for grabs due lack of time

[Ulrich Mueller]

>>>>> On Sat, 16 Feb 2013, Rick \"Zero Chaos\" Farina wrote:

>> Huh? Savedconfig isn't a solution for the license issue.

> If he doesn't agree to the license he can use savedconfig to not
> install those firmware packages.

Yes, but ACCEPT_LICENSE wouldn't work. It would still be necessary to
include all licenses, even for firmware packages that are not
installed.

Ulrich

Re: [gentoo-dev] Packages up for grabs due lack of time

[Mike Gilbert]

On Sat, Feb 16, 2013 at 11:13 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sat, 16 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>
>>> Huh? Savedconfig isn't a solution for the license issue.
>
>> If he doesn't agree to the license he can use savedconfig to not
>> install those firmware packages.
>
> Yes, but ACCEPT_LICENSE wouldn't work. It would still be necessary to
> include all licenses, even for firmware packages that are not
> installed.
>

I'm sure I'm not the only one who really doesn't care about having
ACCEPT_LICENSE work properly for a package full of binary blobs. It
seems like a rather insignificant reason to split the package up.

If some of the licenses involved are particularly offensive to a large
number of people, then it might be worth while to split those
particular files out.

Re: [gentoo-dev] Packages up for grabs due lack of time

[Ulrich Mueller]

>>>>> On Sat, 16 Feb 2013, Mike Gilbert wrote:

> I'm sure I'm not the only one who really doesn't care about having
> ACCEPT_LICENSE work properly for a package full of binary blobs. It
> seems like a rather insignificant reason to split the package up.

Nobody has suggested to split it up. But until this is sorted out,
we should maybe keep the existing individual packages, unless there's
a good reason to remove them.

> If some of the licenses involved are particularly offensive to a
> large number of people, then it might be worth while to split those
> particular files out.

Look into the WHENCE file and be horrified. Taking just the first ten
items (of a total 114):

   Unknown license (3 times)
   GPL, but without source (3 times)
   "All rights reserved"
   BSD, without source
   Right for redistribution not granted
   "Permission is hereby granted for the distribution [...] as part of
       a Linux or other Open Source operating system kernel"

With one exception, we are not even allowed to redistribute these.

Ulrich

Re: [gentoo-dev] Packages up for grabs due lack of time

[Mike Gilbert]

On Sat, Feb 16, 2013 at 12:35 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Look into the WHENCE file and be horrified. Taking just the first ten
> items (of a total 114):
>
>    Unknown license (3 times)
>    GPL, but without source (3 times)
>    "All rights reserved"
>    BSD, without source
>    Right for redistribution not granted
>    "Permission is hereby granted for the distribution [...] as part of
>        a Linux or other Open Source operating system kernel"
>
> With one exception, we are not even allowed to redistribute these.
>

Heh, point taken.
>

Re: [gentoo-dev] Packages up for grabs due lack of time

[Tim Harder]

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

On 2013-02-16 Sat 05:08, Pacho Ramos wrote:
>Due pva lack of time the following packages are now up for grabs:
>net-libs/libmnl

Added to netmon herd.

Tim

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Packages up for grabs due lack of time

[Rick "Zero_Chaos" Farina]

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

On 02/16/2013 10:11 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 16 Feb 2013, Diego Elio Petten￲ wrote:
> 
>> On 16/02/2013 15:41, Rick "Zero_Chaos" Farina wrote:
>>>
>>> Yup, we sure can remove them, and if no one beat me to it I will do
>>> that now.
> 
>> Go for it.
> 
> Please don't.

Sorry, it was done before this email and I just saw it now.
> 
> Can we please stop removing individual firmware packages until
> sys-kernel/linux-firmware has proper license labels, and allows for
> selective installation?

I would be very happy to have the licensing issues fixed, it looks like
it won't be fun, however I was originally told that redist was a
required right for things to be added to linux-firmware at all so I fear
a lot of things may be out of sync in the upstream package.

Please though, can we all stop pretending savedconfig doesn't exist?  We
allow for selective installation already, AND you can install none of it
if you want, no one is forcing files on anyone that doesn't want them.

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

iQIcBAEBAgAGBQJRIGVLAAoJEKXdFCfdEflKqDkP/AskECyNydR91/JeKm9gwrSW
bNbDmkkj5LbN3rqBDj5oMhHauKrTHnYr5K6Cd7oh/trcuM7Njo0AsAGbTpq2KdYv
QZyFKg5gKHXDDA2ASWhDnlNyvOwBgUKONdMdnQS8GTu7e9XtfbVUq7sHSHaXxXng
9055/kHHwpAxV24I7lIfGe/P4AT02cTW21NsHm0YYTi1IA2uMSQ2c3laqpfRDJie
vq0/6JK8rvDOnS1cIFi9TQSYmN1jR6Qf/QGinxLkZfeiVUEf/msWaQGFtT9XXsDC
Y1aIBJxqc1AoeK844dGRkww1oTo3wzhXNCX7Z9uZP5wHUKLD4o/E8alB79p/wvQt
+dUmCj6Q49cku9r0fb8gFiwNjy1AdxuAg20DOA/isNTOO78tdN+rQ5ow/uThZX23
lsS4ZOFRA216+Is0LtPVbcM7PrlR0x3PUE9+qvNV2D/VlfAJPEtZOSBCqkpILfue
wycbKNOi4tLBh3RmtEV23y9SUPNmjYsazD2sOy+MpkPhbTZOZAT46M7HM3F+mwfh
6K5+/5HXSKXhS75E1KRvTgXfVwaehLVGzUBfHdosfKFLffFY6DXzA6roo+RCKJ7J
EvrrLwpNzd3tCHHAefm5Wi32n4k1GG5izY9PLnDeDs+JVgc03gX/zuuZmbi1s8lb
bVHJ1IJjendYHqyLLqpN
=CCk5
-----END PGP SIGNATURE-----

[gentoo-dev] linux-firmware (was: Re: Packages up for grabs due lack of time)

[Ulrich Mueller]

>>>>> On Sun, 17 Feb 2013, Rick \"Zero Chaos\" Farina wrote:

> I would be very happy to have the licensing issues fixed, it looks
> like it won't be fun, however I was originally told that redist was
> a required right for things to be added to linux-firmware at all so
> I fear a lot of things may be out of sync in the upstream package.

IIUC, they require new additions to be redistributable, but don't
remove old images if they're not. Which doesn't make sense.

You should consider mirror restriction for this package.

Ulrich

Re: [gentoo-dev] Packages up for grabs due lack of time

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, 17 Feb 2013 00:06:19 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/16/2013 10:11 AM, Ulrich Mueller wrote:
> > Can we please stop removing individual firmware packages until
> > sys-kernel/linux-firmware has proper license labels, and allows for
> > selective installation?
> 
> I would be very happy to have the licensing issues fixed, it looks like
> it won't be fun, however I was originally told that redist was a
> required right for things to be added to linux-firmware at all so I fear
> a lot of things may be out of sync in the upstream package.
> 
> Please though, can we all stop pretending savedconfig doesn't exist?  We
> allow for selective installation already, AND you can install none of it
> if you want, no one is forcing files on anyone that doesn't want them.

savedconfig is a cheap hack. It lacks all the features USE flags have.
Really. We're talking here about replacing well-organized packages with
one cheap hack for the laziness of a few developers. But that's how
Gentoo worked for a long time.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iJwEAQEIAAYFAlEgq4IACgkQfXuS5UK5QB1t3AQAkIzPTeQNhqUTbKWc5PakR5sJ
HYGBwYUi4j6Ljl7pQN/dDJaNmBy5rfRF3vyoIeglSt9IoHsNsDp+2bEY+easUx/W
fAJPMgdGWg8u3/Sr/SgMzqFrJayiMZjqHKy6tPQFnCh9Kxx0HuP8/XBT1eyJkByY
DfmO8DI/ps1rUKYpJcg=
=X/fN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Packages up for grabs due lack of time

[Samuli Suominen]

On 17/02/13 12:05, Michał Górny wrote:
> savedconfig is a cheap hack. It lacks all the features USE flags have.
> Really. We're talking here about replacing well-organized packages with
> one cheap hack for the laziness of a few developers. But that's how
> Gentoo worked for a long time.

This is how you would justify adding separate ebuild for every firmware 
from the linux-firmware bundle?
Please

Re: [gentoo-dev] Packages up for grabs due lack of time

[Michał Górny]

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

On Sun, 17 Feb 2013 12:09:22 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 17/02/13 12:05, Michał Górny wrote:
> > savedconfig is a cheap hack. It lacks all the features USE flags have.
> > Really. We're talking here about replacing well-organized packages with
> > one cheap hack for the laziness of a few developers. But that's how
> > Gentoo worked for a long time.
> 
> This is how you would justify adding separate ebuild for every firmware 
> from the linux-firmware bundle?

I would justify it through keeping things split and bit-exact clean,
instead of tightly integrated.

Separate ebuilds mean that:

- each firmware has proper license,

- each firmware can be installed separately and it is _clean_ which
  firmwares are actually installed (think of binpkgs),

- each firmware can be upgraded when it needs to be (alternatively: all
  firmwares are re-installed over and over again when new firmware is
  added).

And I wouldn't mind having even 200 sys-firmware/ packages. And don't
tell me that firmwares change every month, these are particularly
maintenance-free packages.

And I don't mind having meta-packages for lazy people.

Although I believe that having a few 'group' packages for firmwares
will be 'acceptable'. Assuming those firmwares share a common license.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Packages up for grabs due lack of time

[Chí-Thanh Christopher Nguyễn]

Diego Elio Pettenò schrieb:
> On 16/02/2013 14:08, Pacho Ramos wrote:
>> sys-firmware/iwl3945-ucode
>> sys-firmware/iwl4965-ucode
>
> Are these included in linux-firmware (i.e. could we just remove them) or
> not?

These are included in linux-firmware. And because Intel has EOL'ed the
chipsets, it is unlikely that the firmware will ever be updated again.
So technically there is no necessity to keep them.

On the non-technical side, there are users who prefer them over the
linux-firmware package and will be upset if we remove them.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Packages up for grabs due lack of time

[Chí-Thanh Christopher Nguyễn]

Peter Stuge schrieb:
> linux-firmware is okey but not great. The high resolution is there, which was my main concern, but
it's not so easy to know how to create a savedconfig without installing
the package.

Just create a text file
/etc/portage/savedconfig/sys-kernel/linux-firmware with the desired
filename(s) and emerge linux-firmware with USE="savedconfig" enabled.


Best regards,

Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Packages up for grabs due lack of time

[Ryan Hill]

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

On Sun, 17 Feb 2013 18:40:10 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Peter Stuge schrieb:
> > linux-firmware is okey but not great. The high resolution is there, which
> > was my main concern, but
> it's not so easy to know how to create a savedconfig without installing
> the package.
> 
> Just create a text file
> /etc/portage/savedconfig/sys-kernel/linux-firmware with the desired
> filename(s) and emerge linux-firmware with USE="savedconfig" enabled.

He means that until you install the package with all firmware enabled you don't
know what lines you need to put into the savedconfig file.

Even after you do that it's hard to figure out what firmware files you actually
need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
linux-firmware contains:

iwlwifi-6000-4.ucode
iwlwifi-6000g2a-5.ucode
iwlwifi-6000g2a-6.ucode
iwlwifi-6000g2b-5.ucode
iwlwifi-6000g2b-6.ucode

Are these different versions?  Different cards?  Which do I need?  I had to
go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
right one.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

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

[gentoo-dev] Re: Packages up for grabs due lack of time

[Ryan Hill]

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

On Sun, 17 Feb 2013 12:42:11 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> I would justify it through keeping things split and bit-exact clean,
> instead of tightly integrated.
> 
> Separate ebuilds mean that:
> 
> - each firmware has proper license,
> 
> - each firmware can be installed separately and it is _clean_ which
>   firmwares are actually installed (think of binpkgs),
> 
> - each firmware can be upgraded when it needs to be (alternatively: all
>   firmwares are re-installed over and over again when new firmware is
>   added).
> 
> And I wouldn't mind having even 200 sys-firmware/ packages. And don't
> tell me that firmwares change every month, these are particularly
> maintenance-free packages.
> 
> And I don't mind having meta-packages for lazy people.
> 
> Although I believe that having a few 'group' packages for firmwares
> will be 'acceptable'. Assuming those firmwares share a common license.

I very much agree with all of this.  It would be nice if we could keep the
individual firmware packages but just have them be a wrapper that depends on
linux-firmware and ensures that the required files get installed (maybe by
adding them to the savedconfig if it finds they aren't there).  Yes, there are
several problems with that idea, I know.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

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

Re: [gentoo-dev] Packages up for grabs due lack of time

[Sven Eden]

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

Am Samstag, 16. Februar 2013, 14:08:06 schrieb Pacho Ramos:
> Due pva lack of time the following packages are now up for grabs:
> app-emulation/e-uae
> app-emulation/uae

AFAIK both are long dead. The current actively developed uae variant is PUAE, 
but I'd say it is not ready for a wider audience right now. It syncs regularly 
with WinUAE, but its GUIs are in a bad shape. The configuration documentation 
is ... well ... lacking at best.

The PUAE maintainer, GnoStiC, has only a Mac to develop on. All linux stuff is 
currently done by me. And I am busy cleaning up code and getting to a state 
where I can bring the front-ends back into a working state.

PUAE: https://github.com/GnoStiC/PUAE
My cleanup-branch: https://github.com/Yamakuzure/PUAE
Note: We cross-merge. regularly.

Most people use an Amiga emulator for some nostalgic gaming only anyway. 
Therefore it might be a good idea to add fs-uae (gamerlay-stable) to the tree, 
if there is any need for it.

However, if there is a need to keep uae and e-uae, I could proxy maintain 
both. The code base I am working on is the same after all. And I have plenty 
of Amiga stuff lying around to test p-uae (Dragons Megademo anyone? ;)) anyway.

Cheers

Sven

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

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Maxim Kammerer]

On Mon, Feb 18, 2013 at 6:47 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> He means that until you install the package with all firmware enabled you don't
> know what lines you need to put into the savedconfig file.

I have posted a snippet previously — you basically search for
"firmware=..." in kernel modules. It's doesn't always work, though —
e.g., it won't with DVB firmware, I think.

> Even after you do that it's hard to figure out what firmware files you actually
> need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
> linux-firmware contains:
>
> iwlwifi-6000-4.ucode
> iwlwifi-6000g2a-5.ucode
> iwlwifi-6000g2a-6.ucode
> iwlwifi-6000g2b-5.ucode
> iwlwifi-6000g2b-6.ucode
>
> Are these different versions?  Different cards?  Which do I need?  I had to
> go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
> right one.

iwlwifi is somewhat special, with its multiple versions and
subversions. In this case, 6000{,g2{a,b}} are different cards, and
-[456] are different firmware APIs, with multiple APIs supported by a
given kernel. See, e.g.,
/usr/src/linux/drivers/net/wireless/iwlwifi/iwl-6000.c.

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

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Chí-Thanh Christopher Nguyễn]

Ryan Hill schrieb:
> He means that until you install the package with all firmware enabled you don't
> know what lines you need to put into the savedconfig file.
>
> Even after you do that it's hard to figure out what firmware files you actually
> need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
> linux-firmware contains:

Sometimes it can be inferred from dmesg output, where the driver outputs
which firmware it requested.

> Are these different versions?  Different cards?  Which do I need?  I had to
> go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
> right one.

Which exact firmware file you need also depends on your kernel version.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Packages up for grabs due lack of time

[Anthony G. Basile]

On 02/16/2013 08:08 AM, Pacho Ramos wrote:
> Due pva lack of time the following packages are now up for grabs:
>
> net-firewall/xtables-addons (proxy maintained)
> net-misc/ipv6calc

I can take care of these two.  I use both.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Rémi Cardona]

Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit :
> Even after you do that it's hard to figure out what firmware files you actually
> need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
> linux-firmware contains:
> 
> iwlwifi-6000-4.ucode
> iwlwifi-6000g2a-5.ucode
> iwlwifi-6000g2a-6.ucode
> iwlwifi-6000g2b-5.ucode
> iwlwifi-6000g2b-6.ucode
> 
> Are these different versions?  Different cards?  Which do I need?

Good kernel modules *should* export needed firmwares as module
parameters. You *should* then be able to query it with modinfo:

    modinfo <module> -F firmware

Note however that *lots* of modules (especially DVB, in my experience)
don't properly set those parameters and you're left grepping the source
code or dmesg to find which firmware you'll need...

Cheers,

Rémi

Re: [gentoo-dev] linux-firmware

[Rick "Zero_Chaos" Farina]

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

On 02/17/2013 05:04 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 17 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
> 
>> I would be very happy to have the licensing issues fixed, it looks
>> like it won't be fun, however I was originally told that redist was
>> a required right for things to be added to linux-firmware at all so
>> I fear a lot of things may be out of sync in the upstream package.
> 
> IIUC, they require new additions to be redistributable, but don't
> remove old images if they're not. Which doesn't make sense.
> 
> You should consider mirror restriction for this package.

I semi-agree with you except for one issue, we are the ones creating
this package. Upstream offers a git repo but no tarball.  So if we stop
distributing it then that kinda kills the package.

Maybe a bug for which firmware are not-redistributable and I can remove
them from our package?  I want people to have working systems but
following the law is a bit more important.

- -Zero

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

iQIcBAEBAgAGBQJRI4m/AAoJEKXdFCfdEflKhaAP/0unuFNO7jXVkdrcaIHCKUsK
IzMqxhmBKP677NcBDZAUCqagvMy1k+KFwWip7wnv7U9iT0FBLIQHtMg262gjfy2g
Hs4+pIO969Ki4UrB+LySbrk8uUDJjMS8r/z4pOMawOnK2CTSdfADG0RV9bdRnwtw
f8uxepe3qKrQYyT1ZZVyjv0BTX5zFVCIOd/D5/45dqHWL4ZpCji+bUiQUUA7RIlC
3nmgeuQMP3eVuaO9qfPo/orUXYyhQPown8jIfp2mkYyUhyGPRqmB4eKi8sZDT+Qx
xaWgJ14WRyUYe4ViHKtCZAQmQRn6N6b08XMWgxDuyeMRWjDywRCnlvZ1W31fGWzP
fS+QgQ8AN1vPYmmbvma4n1lbTolS1q5ZvHeb9ph4/tJH9dmC0+Way4jfbzL0zWz2
Eurogs1aKLM+pk/l3PcX5yeKppyMcoyHrOl5nI7ljt5HJ2fUmm9znV/BBd/txVNj
+deI5CYZs3BDinC7Y4VICdI6BZvti6z0ygdtTTipU1FhMVaVcij8Kq4Jy3UKuR7p
+L22mXgmxpIYyA3aYNyX0N/OTWuaBfCV3KS3ZVr0Tn5/X3UuZbB76Nl390FBt+6u
muXfGKQXN5PNuIZ1n6FsVaQtxQbWU8lJHRZ5PVRrt3In3ppjl0pVtJ+O+lY2PAhM
OP0Jn027y5VTwYvMZMoL
=GcLu
-----END PGP SIGNATURE-----

[gentoo-dev] Re: linux-firmware

[Duncan]

Rick \"Zero_Chaos\" Farina posted on Tue, 19 Feb 2013 09:18:39 -0500 as
excerpted:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/17/2013 05:04 AM, Ulrich Mueller wrote:
>>>>>>> On Sun, 17 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>> 
>>> I would be very happy to have the licensing issues fixed, it looks
>>> like it won't be fun, however I was originally told that redist was a
>>> required right for things to be added to linux-firmware at all so I
>>> fear a lot of things may be out of sync in the upstream package.
>> 
>> IIUC, they require new additions to be redistributable, but don't
>> remove old images if they're not. Which doesn't make sense.
>> 
>> You should consider mirror restriction for this package.
> 
> I semi-agree with you except for one issue, we are the ones creating
> this package. Upstream offers a git repo but no tarball.  So if we stop
> distributing it then that kinda kills the package.
> 
> Maybe a bug for which firmware are not-redistributable and I can remove
> them from our package?  I want people to have working systems but
> following the law is a bit more important.

If all upstream has is a git tarball, what about git-snapshot builds?  
Use the git2 eclass and set a commit number, thus allowing testing and 
stabilization of a specific commit, but the checkout would be directly 
from upstream, so (for the general case, live-image case discussed below) 
gentoo wouldn't be distributing anything but the ebuild.

That /would/ add git as a dep of linux-firmware, however.  And if linux-
firmware is to be an rdep of the kernel...

Also, some people might not want even the git-pak-files containing 
firmware with some licenses on their system.  Is it possible to tell git 
to only clone/pull specific files in a repo?  Of course, if upstream has 
the repo modularized enough, that may not be an issue either, but I'd 
guess it'd still be rather complex to setup and test and ebuild designed 
to work that way.


Of course, we'd still be distributing any firmware included in the live-
images, but I'm not sure if we include any there or not.  If so, then 
certainly someone would have to go thru that and verify the 
redistributability of each bit of included firmware.  But that's a rather 
limited special case.


But regardless, no upstream tarballs, only a git repo, shouldn't be a 
problem for mirror-restrict.  git2.eclass is already enough to deal with 
that bit.

-- 
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: linux-firmware

[Alec Warner]

On Tue, Feb 19, 2013 at 8:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rick \"Zero_Chaos\" Farina posted on Tue, 19 Feb 2013 09:18:39 -0500 as
> excerpted:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 02/17/2013 05:04 AM, Ulrich Mueller wrote:
>>>>>>>> On Sun, 17 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>>>
>>>> I would be very happy to have the licensing issues fixed, it looks
>>>> like it won't be fun, however I was originally told that redist was a
>>>> required right for things to be added to linux-firmware at all so I
>>>> fear a lot of things may be out of sync in the upstream package.
>>>
>>> IIUC, they require new additions to be redistributable, but don't
>>> remove old images if they're not. Which doesn't make sense.
>>>
>>> You should consider mirror restriction for this package.
>>
>> I semi-agree with you except for one issue, we are the ones creating
>> this package. Upstream offers a git repo but no tarball.  So if we stop
>> distributing it then that kinda kills the package.
>>
>> Maybe a bug for which firmware are not-redistributable and I can remove
>> them from our package?  I want people to have working systems but
>> following the law is a bit more important.
>
> If all upstream has is a git tarball, what about git-snapshot builds?
> Use the git2 eclass and set a commit number, thus allowing testing and
> stabilization of a specific commit, but the checkout would be directly
> from upstream, so (for the general case, live-image case discussed below)
> gentoo wouldn't be distributing anything but the ebuild.
>
> That /would/ add git as a dep of linux-firmware, however.  And if linux-
> firmware is to be an rdep of the kernel...
>
> Also, some people might not want even the git-pak-files containing
> firmware with some licenses on their system.  Is it possible to tell git
> to only clone/pull specific files in a repo?  Of course, if upstream has
> the repo modularized enough, that may not be an issue either, but I'd
> guess it'd still be rather complex to setup and test and ebuild designed
> to work that way.

Lets not re-invent the wheel here:

Debian has free and non-free packages.
http://packages.debian.org/sid/firmware-linux

# free copyright
http://packages.debian.org/changelogs/pool/main/f/firmware-free/firmware-free_3.2/firmware-linux-free.copyright

# nonfree copyright
http://packages.debian.org/changelogs/pool/non-free/f/firmware-nonfree/firmware-nonfree_0.36+wheezy.1/firmware-linux-nonfree.copyright

http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec
Specifically:
License:	GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted

It looks like OpenSuse has split packages. Most distros are debian or
redhat based these days.

We can easily have a firmware package that is USE="nonfree" and only
install the libre firmware, ala debian. This also fixes 'the license
issue' because if people want ACCEPT_LICENSE=@OSI-APPROVED they just
need to turn the nonfree flag off.

None of this is rocket science, and the work has likely already been
done by others, so just take it and go.

-A

>
>
> Of course, we'd still be distributing any firmware included in the live-
> images, but I'm not sure if we include any there or not.  If so, then
> certainly someone would have to go thru that and verify the
> redistributability of each bit of included firmware.  But that's a rather
> limited special case.
>
>
> But regardless, no upstream tarballs, only a git repo, shouldn't be a
> problem for mirror-restrict.  git2.eclass is already enough to deal with
> that bit.
>
> --
> 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: linux-firmware

[Ulrich Mueller]

>>>>> On Tue, 19 Feb 2013, Alec Warner wrote:

> Lets not re-invent the wheel here:

> Debian has free and non-free packages.
> http://packages.debian.org/sid/firmware-linux

> # free copyright
> http://packages.debian.org/changelogs/pool/main/f/firmware-free/firmware-free_3.2/firmware-linux-free.copyright

> # nonfree copyright
> http://packages.debian.org/changelogs/pool/non-free/f/firmware-nonfree/firmware-nonfree_0.36+wheezy.1/firmware-linux-nonfree.copyright

> http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec
> Specifically:
> License:	GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted

> It looks like OpenSuse has split packages. Most distros are debian or
> redhat based these days.

> We can easily have a firmware package that is USE="nonfree" and only
> install the libre firmware, ala debian. This also fixes 'the license
> issue' because if people want ACCEPT_LICENSE=@OSI-APPROVED they just
> need to turn the nonfree flag off.

> None of this is rocket science, and the work has likely already been
> done by others, so just take it and go.

I mostly agree. However, there are not two, but three classes of
licenses for firmware images:

  1. Free software
  2. Non-free, but can be redistributed
  3. Cannot be redistributed

The split between 2 and 3 is the more important one, because we cannot
mirror things under 3.

Ulrich

Re: [gentoo-dev] Re: linux-firmware

[Alec Warner]

On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 19 Feb 2013, Alec Warner wrote:
>
>> Lets not re-invent the wheel here:
>
>> Debian has free and non-free packages.
>> http://packages.debian.org/sid/firmware-linux
>
>> # free copyright
>> http://packages.debian.org/changelogs/pool/main/f/firmware-free/firmware-free_3.2/firmware-linux-free.copyright
>
>> # nonfree copyright
>> http://packages.debian.org/changelogs/pool/non-free/f/firmware-nonfree/firmware-nonfree_0.36+wheezy.1/firmware-linux-nonfree.copyright
>
>> http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec
>> Specifically:
>> License:      GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted
>
>> It looks like OpenSuse has split packages. Most distros are debian or
>> redhat based these days.
>
>> We can easily have a firmware package that is USE="nonfree" and only
>> install the libre firmware, ala debian. This also fixes 'the license
>> issue' because if people want ACCEPT_LICENSE=@OSI-APPROVED they just
>> need to turn the nonfree flag off.
>
>> None of this is rocket science, and the work has likely already been
>> done by others, so just take it and go.
>
> I mostly agree. However, there are not two, but three classes of
> licenses for firmware images:
>
>   1. Free software
>   2. Non-free, but can be redistributed
>   3. Cannot be redistributed
>
> The split between 2 and 3 is the more important one, because we cannot
> mirror things under 3.

Have we talked to debian then? Nominally if we can't dist it, they
can't dist it (and vice versa.)

-A

>
> Ulrich
>

Re: [gentoo-dev] Re: linux-firmware

[Peter Stuge]

Duncan wrote:
> Is it possible to tell git to only clone/pull specific files in a repo?

No.


//Peter

Re: [gentoo-dev] Re: linux-firmware

[Ulrich Mueller]

>>>>> On Wed, 20 Feb 2013, Alec Warner wrote:

> On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> I mostly agree. However, there are not two, but three classes of
>> licenses for firmware images:
>> 
>> 1. Free software
>> 2. Non-free, but can be redistributed
>> 3. Cannot be redistributed
>> 
>> The split between 2 and 3 is the more important one, because we
>> cannot mirror things under 3.

> Have we talked to debian then? Nominally if we can't dist it, they
> can't dist it (and vice versa.)

From a quick glance at their tarball it seems that they exclude some
firmware images that are included in our tarball.

For example, I don't see atmsar11.fw and k1212.dsp (first two entries
in WHENCE) in their tarball. Which makes sense because both are not
redistributable.

Ulrich

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Tue, Feb 19, 2013 at 11:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> If all upstream has is a git tarball, what about git-snapshot builds?
> Use the git2 eclass and set a commit number, thus allowing testing and
> stabilization of a specific commit, but the checkout would be directly
> from upstream, so (for the general case, live-image case discussed below)
> gentoo wouldn't be distributing anything but the ebuild.

There is a current QA policy that anything using an scm to download
sources cannot be stabilized, because there is no way to verify the
manifest.

I'm actually wondering if that makes sense with git when a specific
commit is referenced, since everything is content-hashed anyway.
Perhaps we just need to confirm that git actually checks the hash.

Rich

Re: [gentoo-dev] Re: linux-firmware

[Tomáš Chvátal]

2013/2/20 Rich Freeman <rich0@gentoo.org>:
> There is a current QA policy that anything using an scm to download
> sources cannot be stabilized, because there is no way to verify the
> manifest.
>
> I'm actually wondering if that makes sense with git when a specific
> commit is referenced, since everything is content-hashed anyway.
> Perhaps we just need to confirm that git actually checks the hash.
>

If you checkout some revision or tag just create the darn tarball
yourself as it is much cleaner solution and you don't force user to
install git or other scm tools unless they need them.

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 13:02, Rich Freeman wrote:
> I'm actually wondering if that makes sense with git when a specific
> commit is referenced, since everything is content-hashed anyway.
> Perhaps we just need to confirm that git actually checks the hash.

No.

The policy is not _just_ because of the manifest verification.

The policy is also because any ebuild relying on a network service to
work cannot be assured to work at any point in time: not only it depends
on the network connection of the user, but it also depends on the
service to be available.

So don't even _think_ about trying to ask for an exception for Git,
because you'll have to have it over my ssh key.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Chí-Thanh Christopher Nguyễn]

Tomáš Chvátal schrieb:
> 2013/2/20 Rich Freeman <rich0@gentoo.org>:
>> There is a current QA policy that anything using an scm to download
>> sources cannot be stabilized, because there is no way to verify the
>> manifest.
>>
>> I'm actually wondering if that makes sense with git when a specific
>> commit is referenced, since everything is content-hashed anyway.
>> Perhaps we just need to confirm that git actually checks the hash.
>>
> If you checkout some revision or tag just create the darn tarball
> yourself as it is much cleaner solution and you don't force user to
> install git or other scm tools unless they need them.

Problem is that the tarball cannot be redistributed by us. Now what?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 14:29, Chí-Thanh Christopher Nguyễn wrote:
> Problem is that the tarball cannot be redistributed by us. Now what?

Now you drop the firmwares that we can't distribute, and make the same
tarball — as for those firmware... hash them separately and
fetch-restrict them.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 20/02/2013 13:02, Rich Freeman wrote:
>> I'm actually wondering if that makes sense with git when a specific
>> commit is referenced, since everything is content-hashed anyway.
>> Perhaps we just need to confirm that git actually checks the hash.
>
> The policy is also because any ebuild relying on a network service to
> work cannot be assured to work at any point in time: not only it depends
> on the network connection of the user, but it also depends on the
> service to be available.

Makes sense in general.

If there really are firmware blobs that are only available via git and
which cannot be redistributed we might consider whether it makes sense
to not support them entirely, or to force them to be masked.  Dropping
or masking the packages doesn't fix the fact that they require a
network service to install - it just makes it harder to install the
package.

If a tarball exists or can be created that would be the best solution
all-around, of course.

Rich

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 17:03, Rich Freeman wrote:
> Dropping
> or masking the packages doesn't fix the fact that they require a
> network service to install - it just makes it harder to install the
> package.

The reason why they are masked is because users who want to use a live
ebuild will acknowledge that they know it might not install at all.

No, we're not going to change this policy, so don't even suggest it

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Rick "Zero_Chaos" Farina]

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

On 02/20/2013 02:55 AM, Ulrich Mueller wrote:

I am going to respond here because it makes the most sense to me.

> I mostly agree. However, there are not two, but three classes of
> licenses for firmware images:
> 
>   1. Free software
>   2. Non-free, but can be redistributed
>   3. Cannot be redistributed
> 
> The split between 2 and 3 is the more important one, because we cannot
> mirror things under 3.

I completely agree. I will HAPPILY divide the ebuild up with a nonfree
(or other suggested SANE use flag) to denote the difference between 1
and 2.  None of this is under contest, this choice is all but too easy.
Depending on the licensing issues which arise I may even add in a
separate ebuild.

The issue come in with number 3.  Adding a bindist use flag for the
- -9999 ebuild seems sane since it pulls from git and we don't have to
redist it, but is is possible to RESTRICT="bindist? bindist" ?

Anyone volunteering to tear through this licensing mess and start
breaking things into groups?

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

iQIcBAEBAgAGBQJRJPedAAoJEKXdFCfdEflKhIUQAKXMr8tpwhrFBh2/LxfsdVRQ
n6F72a2KCHyM2YCCQsw3eKskBKmeawQNNKWAQmOaDjn6dcEVi0hxHBLr42m3CZiL
yNA9PRAvRSyshEn8NN/ExTR4eGZft2XqPuhszN129Eu3pJknvKQaPy5ItNzORzN0
FJDherBc2DXs4Uc0VmKxezHxNZZwv1OHIRPtNFGTDy4Eixw4GCYOEg8u1yI23iz7
p+Ef2YjoJPqs9Q3zxuFuJ/is9tIcKdzRy7kNXne92BCvVIst5Dflgg6kQ925eoaM
RifTXv6w1cinItrBRzITftS6j44CcZVpYyRye1ganwuLb90Cxb5U2x8wsj6a1Tcu
okVMWk/ncAHvjrkVoC1/wSpjyCgL5J2EaY5C5O5kkhPxNhwjfICpppawGR7psxAJ
EQjl+u8O6HlVVbPIHTKGlEtSG+HGxVrVX5+CNj39MHEVIhqqVkvw+UenG4lG/Dv8
T+uAjTMYXJzMcVcw90hg8vHmygjXDwIypf0VGf4h+RCloX92dCP5HeBaU79/18Gz
cGfdnOlSsUG7dr+VG4g7O+4AsopNbRe+a2EugGSMQ5IjkK7TaCYFt7K0nKbVYVyt
AeMhsU17/X15rUpYNv37Liu4ythXyldVQMpnvclbx/kwiPR1bK3XSZfvZOX0g5Rb
E2snaN0NNWWCIoj4aK1r
=BJk0
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: linux-firmware

[Peter Stuge]

Diego Elio Pettenò wrote:
> The policy is also because any ebuild relying on a network service
> to work cannot be assured to work at any point in time

While noble, I think it is a bit naïve. Reality is that many if not
most ebuilds *anyway* rely on temporal things - such as a current
enough versions of portage, or a new enough profile, or tar and sed.

Requiring git and a network connection is the restriction imposed by
the copyright holder. There's really no way around that.


> depends on the network connection of the user, but it also depends
> on the service to be available.

Right, because those files can only be legally distributed by the
service on the network. No matter how much you and I think that
sucks, it is still the only way for the user to get that file.

It makes no sense to make that unneccessarily difficult for users.


> So don't even _think_ about trying to ask for an exception for Git,
> because you'll have to have it over my ssh key.

This is just trying to be a bully and acting like a drama queen,
which does nothing but make you look super silly, and that seems
completely unneccessary.

If you dislike something then you should express that in a more
mature manner so that people can actually take you seriously.

When you behave badly like this you just end up getting bad behavior,
spite and disrespect in return, even if it takes a while to reach you.


//Peter

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 17:28, Peter Stuge wrote:
> This is just trying to be a bully and acting like a drama queen,
> which does nothing but make you look super silly, and that seems
> completely unneccessary.
> 
> If you dislike something then you should express that in a more
> mature manner so that people can actually take you seriously.
> 
> When you behave badly like this you just end up getting bad behavior,
> spite and disrespect in return, even if it takes a while to reach you.

Peter, I'll ask simply, and politely: stop being a nuisance, especially
since you can't be bothered to become a developer (not that I would like
to have you among the developers, honestly; I'd gladly take a few more
mgornys beside you).

This policy has been around for a very long time, and will be kept
around. It's not going to change, because it makes no sense for it to
change. It might be inconvenient to _you_, but once again, we're not
here to do stuff only when it's convenient.

So, please, really please, stop thinking like whatever your experience
is, that's the only experience out there.

Between you and Rich, I think you've been voicing your opinion just
because you can, and without thinking about repercussion for others,
under the principle that the incumbent is always wrong.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Ulrich Mueller]

>>>>> On Wed, 20 Feb 2013, Rick \"Zero Chaos\" Farina wrote:

> On 02/20/2013 02:55 AM, Ulrich Mueller wrote:

> I am going to respond here because it makes the most sense to me.

>> I mostly agree. However, there are not two, but three classes of
>> licenses for firmware images:
>> 
>> 1. Free software
>> 2. Non-free, but can be redistributed
>> 3. Cannot be redistributed
>> 
>> The split between 2 and 3 is the more important one, because we cannot
>> mirror things under 3.

> I completely agree. I will HAPPILY divide the ebuild up with a nonfree
> (or other suggested SANE use flag) to denote the difference between 1
> and 2.  None of this is under contest, this choice is all but too easy.
> Depending on the licensing issues which arise I may even add in a
> separate ebuild.

> The issue come in with number 3.  Adding a bindist use flag for the
> - -9999 ebuild seems sane since it pulls from git and we don't have to
> redist it, but is is possible to RESTRICT="bindist? bindist" ?

Eh, what? You want to exclude the non-redistributable firmware from
binpkgs build by the user? I.e. USE="-bindist" would include
everything but USE="bindist" wouldn't? IIUC, you don't need an
additional RESTRICT then.

> Anyone volunteering to tear through this licensing mess and start
> breaking things into groups?

Does the WHENCE cover everything that is currently included in your
tarball?

Ulrich

Re: [gentoo-dev] Re: linux-firmware

[Alec Warner]

On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge <peter@stuge.se> wrote:
> Diego Elio Pettenò wrote:
>> The policy is also because any ebuild relying on a network service
>> to work cannot be assured to work at any point in time
>
> While noble, I think it is a bit naïve. Reality is that many if not
> most ebuilds *anyway* rely on temporal things - such as a current
> enough versions of portage, or a new enough profile, or tar and sed.

These are things that we have covered, generally speaking. @system
will bring in tar and sed, and a minimum version of portage. Old
profiles are tagged as deprecated, and users are encouraged to migrate
to current profiles. The PMS defines which bits the ebuilds can use,
and if a program needs a 'newer' sed, it should say so in its
dependencies.

We could add something like PROPERTIES="network" to packages that
require the network. I'm vaguely sure for instance, that some
src_test() phases require a functioning network to work properly.

>
> Requiring git and a network connection is the restriction imposed by
> the copyright holder. There's really no way around that.

I'm confused though, we can easily just make 2 ebuilds.

linux-firmware[non-free] <- the use flag to toggle between free and
non-free licenses.
linux-firmware-noredist <- This one is RESTRICT="fetch mirror"

RESTRICT="fetch mirror" already exists, has existed for years, and
exists for exactly this purpose.

>
>
>> depends on the network connection of the user, but it also depends
>> on the service to be available.
>
> Right, because those files can only be legally distributed by the
> service on the network. No matter how much you and I think that
> sucks, it is still the only way for the user to get that file.
>
> It makes no sense to make that unneccessarily difficult for users.

I don't think fetch restriction is that annoying. You could argue that
we do it debian / ubuntu style where the files are fetched in a
postinstall, but I think that is sort of hacky myself.

>
>
>> So don't even _think_ about trying to ask for an exception for Git,
>> because you'll have to have it over my ssh key.
>
> This is just trying to be a bully and acting like a drama queen,
> which does nothing but make you look super silly, and that seems
> completely unneccessary.
>
> If you dislike something then you should express that in a more
> mature manner so that people can actually take you seriously.
>
> When you behave badly like this you just end up getting bad behavior,
> spite and disrespect in return, even if it takes a while to reach you.
>
>
> //Peter
>

Re: [gentoo-dev] Re: linux-firmware

[Rick "Zero_Chaos" Farina]

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

On 02/20/2013 11:44 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 20 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
> 
>> On 02/20/2013 02:55 AM, Ulrich Mueller wrote:
> 
>> I am going to respond here because it makes the most sense to me.
> 
>>> I mostly agree. However, there are not two, but three classes of
>>> licenses for firmware images:
>>>
>>> 1. Free software
>>> 2. Non-free, but can be redistributed
>>> 3. Cannot be redistributed
>>>
>>> The split between 2 and 3 is the more important one, because we cannot
>>> mirror things under 3.
> 
>> I completely agree. I will HAPPILY divide the ebuild up with a nonfree
>> (or other suggested SANE use flag) to denote the difference between 1
>> and 2.  None of this is under contest, this choice is all but too easy.
>> Depending on the licensing issues which arise I may even add in a
>> separate ebuild.
> 
>> The issue come in with number 3.  Adding a bindist use flag for the
>> - -9999 ebuild seems sane since it pulls from git and we don't have to
>> redist it, but is is possible to RESTRICT="bindist? bindist" ?
> 
> Eh, what? You want to exclude the non-redistributable firmware from
> binpkgs build by the user? I.e. USE="-bindist" would include
> everything but USE="bindist" wouldn't? IIUC, you don't need an
> additional RESTRICT then.
So RESTRICT=bindist is only needed when there is no flag?  Still I
suppose it will come up if we break this into three parts.
> 
>> Anyone volunteering to tear through this licensing mess and start
>> breaking things into groups?
> 
> Does the WHENCE cover everything that is currently included in your
> tarball?

The tarball is a full copy of the git tree so I'm going to say no.

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

iQIcBAEBAgAGBQJRJP89AAoJEKXdFCfdEflKI3AP/33BKxpQA+lYGVcLTALhBsje
ubxIcc6s3bo97O3XBaAxYOKTkb0SS8LGS4jCGN4m/IgMycqPZrkVTCruSq1SpRJ6
4thkLsLNsYr+niUQUt/QFoDRwzeWiFrToECXrJB7cPl0s8/TcGTxyke+rGeRjOVr
TmKMEZB790mgjyTrSD4ZJkww3Czf1B370RDgNviN6LseiGXS0Il5Tuv8FouGFBFS
cfyvVN/1RhQW8ANb9Dd+AzGhYdR8gNWUxFypVJSvM40n61BnOJ1RgfOqPKxv1RjD
hvu5oDVBO7fSrT3iY3Cw5t70RS46lptJ7WE6wiRRP0KmvLyv+zimmdSs/4URpTZQ
SXVhmBkRlRRLt6NKkg2Ok92F87uzu/eFFA4cUh+/sJazdRyY69JXRRl5/UbOeq8f
62MQJRiDbBGIDIDSKl01KyQ9oPba9+HNbakaTUYqB4bRvc5+0iJ0cmheThcFooCm
PHpvWzkSxe5pIrs9Qk4c2eVRsrG8xl0mx+xsSRMv2nheYCFfJUnOy9pvs2p3Hk8e
P3f7zN/WP7C/RvUDHBe8CAuNMuDDYT1c0PY6Kh1cKcWbNDn2tdq/Xat1kUiuOJQX
k1vgEQdgrMR0VSmxi6aa909rWx4kqUh4P8MyOrDChaHGV/7v3PSrJha35vc9E/ls
QZ8ZjHumELOrJ21lz7G1
=5Rzv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 17:45, Alec Warner wrote:
> We could add something like PROPERTIES="network" to packages that
> require the network. I'm vaguely sure for instance, that some
> src_test() phases require a functioning network to work properly.

This has been proposed a bunch of times before, and I still wish to see
it implemented.

On the other hand, even for those that currently require network for
src_test, if there was a quick opt-out, I foresee trouble: quite a few
times it's possible to test 90% (figurative number) of a library without
network, you just need to take the time to disable the network-bound
tests (eventually giving upstream a patch to enable/disable the network
side, or to ignore network failures instead of consider them a FAIL —
versus getting the wrong response which _is_ a FAIL).

Having non-masked ebuilds rely on network access also makes it extremely
hard to do things such as isolated builds (for embedded/firmware-style
OSes), and by experience would make the whole tinderboxing effort nearly
unfeasible — for sure I would shut down both the tinderboxes as I'd be
debugging network issues more often than actual problems with
tinderbox/packages.

> linux-firmware[non-free] <- the use flag to toggle between free and
> non-free licenses.
> linux-firmware-noredist <- This one is RESTRICT="fetch mirror"

+1 — It requires some work from someone to actually split the stuff
manually though, and there is at least one problem: somebody _got_ to
redist the firmware for it to be fetched.. unless.

But yes, the first obvious solution is, when snapshotting the
repository, to just drop the noredist files, and add the above-suggested
USE flag for the non-free ones.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner <antarus@gentoo.org> wrote:
> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge <peter@stuge.se> wrote:
>>
>> It makes no sense to make that unneccessarily difficult for users.
>
> I don't think fetch restriction is that annoying. You could argue that
> we do it debian / ubuntu style where the files are fetched in a
> postinstall, but I think that is sort of hacky myself.

The concern wasn't with fetch restrictions so much as with masking.
Fetch restriction works if upstream provides a tarball but we can't
redistribute it.  If upstream doesn't provide a tarball and we can't
redistribute anything, then a live scm ebuild is the only way to
deploy something, and current policy is that these must be masked.

I do understand Diego's concerns with some edge cases, including the
tinderbox.  Some kind of PROPERTIES=network solution might be the best
compromise.  Until then masking things is better than dropping them.
It just doesn't seem ideal to have packages that are basically
permanently masked.  Masking is usually a temporary solution for
testing or removal, or it can be applied to things like live ebuilds
which are moving targets that can never have QA.  I think the fact
that we have to resort to masking in this case is more a reflection of
a limitation of portage, but saying so doesn't fix anything, so we'll
just have to live with it for now...

Since this topic came up elsewhere in the thread it really isn't my
goal to cause inconvenience or debate things imply for their own sake.
 I just would like to see things improve when it is possible, and
don't tend to censor my questions as a result.  I don't really
disagree with the status quo simply because it is the status quo.  I
think that is more selection bias - when I agree with the status quo
I'm less likely to post anything at all...

Rich

Re: [gentoo-dev] Re: linux-firmware

[Alec Warner]

On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner <antarus@gentoo.org> wrote:
>> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge <peter@stuge.se> wrote:
>>>
>>> It makes no sense to make that unneccessarily difficult for users.
>>
>> I don't think fetch restriction is that annoying. You could argue that
>> we do it debian / ubuntu style where the files are fetched in a
>> postinstall, but I think that is sort of hacky myself.
>
> The concern wasn't with fetch restrictions so much as with masking.
> Fetch restriction works if upstream provides a tarball but we can't
> redistribute it.  If upstream doesn't provide a tarball and we can't
> redistribute anything, then a live scm ebuild is the only way to
> deploy something, and current policy is that these must be masked.

Not following you here. We cannot redistribute dev-java/sun-j2ee for
instance. We don't mirror dev-java/sun-j2ee. We tell the user 'hey go
download j2ee from Oracle and put it in $LOCATION. A live SCM ebuild
is not the only way to deploy something. If the user has to go
download a blob out of linux-firmware's gitweb because we feel we
cannot legally distribute the firmware, then that is what they have to
do. If the user has to go to the manufacturers website to get the
firmware, then that is what they have to do.

>
> I do understand Diego's concerns with some edge cases, including the
> tinderbox.  Some kind of PROPERTIES=network solution might be the best
> compromise.  Until then masking things is better than dropping them.
> It just doesn't seem ideal to have packages that are basically
> permanently masked.  Masking is usually a temporary solution for
> testing or removal, or it can be applied to things like live ebuilds
> which are moving targets that can never have QA.  I think the fact
> that we have to resort to masking in this case is more a reflection of
> a limitation of portage, but saying so doesn't fix anything, so we'll
> just have to live with it for now...
>
> Since this topic came up elsewhere in the thread it really isn't my
> goal to cause inconvenience or debate things imply for their own sake.
>  I just would like to see things improve when it is possible, and
> don't tend to censor my questions as a result.  I don't really
> disagree with the status quo simply because it is the status quo.  I
> think that is more selection bias - when I agree with the status quo
> I'm less likely to post anything at all...
>
> Rich
>

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner <antarus@gentoo.org> wrote:
> A live SCM ebuild
> is not the only way to deploy something. If the user has to go
> download a blob out of linux-firmware's gitweb because we feel we
> cannot legally distribute the firmware, then that is what they have to
> do. If the user has to go to the manufacturers website to get the
> firmware, then that is what they have to do.

Agreed, especially if only 1-2 files are involved.  If it is a bunch
that could get unwieldy.  Wasn't really thinking about that option.

Rich

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 18:28, Rich Freeman wrote:
> Agreed, especially if only 1-2 files are involved.  If it is a bunch
> that could get unwieldy.  Wasn't really thinking about that option.

That being the case, splitting them in multiple packages might indeed be
a better option. Yes I know I'm the one pushing for using a single
package — as long as it doesn't have licensing issues of course.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> That being the case, splitting them in multiple packages might indeed be
> a better option. Yes I know I'm the one pushing for using a single
> package — as long as it doesn't have licensing issues of course.

Yup, a combined package that is fetch-restricted with 57 files in the
SRC_URI isn't really something that anybody would like.

Probably makes sense to have a few tiers:
1.  Free
2.  Non-free, but redistributable
3.  Non-free, nonredistributable, but fetchable (maybe combine with #2)
4.  Non-fetchable - do not combine.

Rich

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 11:03:47AM -0500, Rich Freeman wrote:
> On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
> <flameeyes@flameeyes.eu> wrote:
> > On 20/02/2013 13:02, Rich Freeman wrote:
> >> I'm actually wondering if that makes sense with git when a specific
> >> commit is referenced, since everything is content-hashed anyway.
> >> Perhaps we just need to confirm that git actually checks the hash.
> >
> > The policy is also because any ebuild relying on a network service to
> > work cannot be assured to work at any point in time: not only it depends
> > on the network connection of the user, but it also depends on the
> > service to be available.
> 
> Makes sense in general.
> 
> If there really are firmware blobs that are only available via git and
> which cannot be redistributed we might consider whether it makes sense
> to not support them entirely, or to force them to be masked.

Did anyone actually consider the fact that there should not be
non-redistributable firmware blobs in the upstream git tree in the first
place, as it is the thing that is doing the redistributing originally?

Has anyone pointed out any problems with the package to upstream if you
have found them?  If so, what did they say?

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Peter Stuge]

Greg KH wrote:
> > If there really are firmware blobs that are only available via git and
> > which cannot be redistributed we might consider whether it makes sense
> > to not support them entirely, or to force them to be masked.
> 
> Did anyone actually consider the fact that there should not be
> non-redistributable firmware blobs in the upstream git tree in the
> first place, as it is the thing that is doing the redistributing
> originally?

I think non-redistributable in this case means "by Gentoo" since that
was identified to be the case for some of the files in the git
repository. Their license allows them to be distributed in
linux-firmware.git, but not elsewhere.


//Peter

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 07:25:14PM +0100, Peter Stuge wrote:
> Greg KH wrote:
> > > If there really are firmware blobs that are only available via git and
> > > which cannot be redistributed we might consider whether it makes sense
> > > to not support them entirely, or to force them to be masked.
> > 
> > Did anyone actually consider the fact that there should not be
> > non-redistributable firmware blobs in the upstream git tree in the
> > first place, as it is the thing that is doing the redistributing
> > originally?
> 
> I think non-redistributable in this case means "by Gentoo" since that
> was identified to be the case for some of the files in the git
> repository. Their license allows them to be distributed in
> linux-firmware.git, but not elsewhere.

Really?  What firmware files are that way, I just did a quick scan
through the upstream linux-firmware.git tree and didn't see anything
that would prevent Gentoo from doing this.

What did I miss?

thanks,

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Diego Elio Pettenò]

On 20/02/2013 19:43, Greg KH wrote:
> Really?  What firmware files are that way, I just did a quick scan
> through the upstream linux-firmware.git tree and didn't see anything
> that would prevent Gentoo from doing this.

No, not really. Greg, please don't expect everybody's word here to be
the Project's as you did already once - especially not if they are not
even really involved in it.

Ulrich Mueller (ulm) wrote this on the 16th:

> Look into the WHENCE file and be horrified. Taking just the first ten
> items (of a total 114):
> 
>    Unknown license (3 times)
>    GPL, but without source (3 times)
>    "All rights reserved"
>    BSD, without source
>    Right for redistribution not granted
>    "Permission is hereby granted for the distribution [...] as part of
>        a Linux or other Open Source operating system kernel"
> 
> With one exception, we are not even allowed to redistribute these.

This is what we've been discussing about. This is not really about
Gentoo by itself, but the ability to distribute the sources at all, be
it from us or somebody else.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: linux-firmware

[Chí-Thanh Christopher Nguyễn]

Diego Elio Pettenò schrieb:
>> linux-firmware[non-free] <- the use flag to toggle between free and
>> non-free licenses.
>> linux-firmware-noredist <- This one is RESTRICT="fetch mirror"
> +1 — It requires some work from someone to actually split the stuff
> manually though, and there is at least one problem: somebody _got_ to
> redist the firmware for it to be fetched.. unless.

Distinguishing between free and non-free firmware would be ok with me
but I am not going to invest any work in that.
I think the bindist flag is suitable for toggling the download of
non-redistributable firmware. Possibly SRC_URI for the
non-redistributable files can point to upstream gitweb. Although I don't
know happy upstream will be when hordes of Gentoo users start hammering
their servers.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: linux-firmware

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> Probably makes sense to have a few tiers:
> 1.  Free
> 2.  Non-free, but redistributable
> 3.  Non-free, nonredistributable, but fetchable (maybe combine with #2)
> 4.  Non-fetchable - do not combine.

I don't see a reason for fetch restriction, as long as a direct download
link from upstream exists (via gitweb).


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>> 4.  Non-fetchable - do not combine.
>
> I don't see a reason for fetch restriction, as long as a direct download
> link from upstream exists (via gitweb).

Agreed.  You would only fetch-restrict a file if it wasn't fetchable
or redistributable.  If that is the empty set, then great.  If not,
then split them up and fetch-restrict them.

Rich

Re: [gentoo-dev] Re: linux-firmware

[Rick "Zero_Chaos" Farina]

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

On 02/20/2013 12:32 PM, Diego Elio Pettenò wrote:
> On 20/02/2013 18:28, Rich Freeman wrote:
>> Agreed, especially if only 1-2 files are involved.  If it is a bunch
>> that could get unwieldy.  Wasn't really thinking about that option.
> 
> That being the case, splitting them in multiple packages might indeed be
> a better option. Yes I know I'm the one pushing for using a single
> package — as long as it doesn't have licensing issues of course.
> 

I'm fine splitting the package into linux-firmware[non-free] and
linux-firmware-restricted (or something like that).  When I say I want
one one ebuild for all firmware I really don't care to include
fetch-restricted and the like in that.  I'm very happy to have one
ebuild for free and redistributable firmware and then have multiple
other ebuilds as appropriate for the non-redistributable stuff.

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

iQIcBAEBAgAGBQJRJSa2AAoJEKXdFCfdEflKSM0P/jjNsGH7MW8rcCRkMsL/i4mw
08CBJ/mxl81YnKPZGoXS0JcMG9LmCjW+2f87JBmMAk8cOPJhzlGV7V8y7GlY+BgF
oz37nfOqJVciY2sWqPze+H1bH0crrrBZhIDTnCfo/ryRPR+oTTQdO4xRxIXOe3Fo
Fw6VJPQkCLFFMwraOYBxcrXPmGQ7RVz8MvmyeVcJH5lUFh7wi/dPu/Iwqu2dX4Yc
faXOCBzU06r62CvWt1+7msouO6Y+f4Hh1XcOe2cXCLsZJj+74WiQzXeQB7iQv0F+
zE/p6Stee5yhrn9bhB/mASeBk9YvyztUng8IIigNdnFovAhUyZp86wvEt7xd0rqp
N8U7WHnSYzfU8Wntr/p1ZHHYsvmdwJToRsh6e9+IrX0i82W+I6b6s9L0n1+SqIIY
fCacto2idRN4k9lQ51beEq7ZqqCcLpPuWthTzVT9E3obCH8UrFlFFvImMtdJyMq1
4J8MWRVSWUPwEn84Yu5RpPxl3aOmqfv5cVzUqXmYy1hYQb0P4e/43+L0hyQvthPR
N6htokFjS0iWpYklp6hkSt+VdBUf6wF/4ytNjeAd0BhpRWK/diDiysKDTHVAPswB
0PX6cX++uYPVNTD+PdaW2PbFVwzKgCzUI185dw26rBjarRJpfhdcrPyIMXGeEqa6
RoR0efRHAnraGw/qqL8v
=lAF5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 07:51:15PM +0100, Diego Elio Pettenò wrote:
> On 20/02/2013 19:43, Greg KH wrote:
> > Really?  What firmware files are that way, I just did a quick scan
> > through the upstream linux-firmware.git tree and didn't see anything
> > that would prevent Gentoo from doing this.
> 
> No, not really. Greg, please don't expect everybody's word here to be
> the Project's as you did already once - especially not if they are not
> even really involved in it.

Of course not, I know better than that from -dev, I've been around long
enough :)

That's why I was asking for specifics.

> Ulrich Mueller (ulm) wrote this on the 16th:
> 
> > Look into the WHENCE file and be horrified. Taking just the first ten
> > items (of a total 114):
> > 
> >    Unknown license (3 times)

Which ones specifically?

> >    GPL, but without source (3 times)

Really?  Which?

> >    "All rights reserved"

That's not an issue, unless it is alone, is there something else in the
license as well?

> >    BSD, without source

There's no problem with that.

> >    Right for redistribution not granted

Huh?  Which?

> >    "Permission is hereby granted for the distribution [...] as part of
> >        a Linux or other Open Source operating system kernel"

What is wrong with that?  We happen to be distributing a Linux operating
system.

> > With one exception, we are not even allowed to redistribute these.

I don't understand, please explain all of these in detail so that we can
fix this upstream.

> This is what we've been discussing about. This is not really about
> Gentoo by itself, but the ability to distribute the sources at all, be
> it from us or somebody else.

I understand, and as an upstream developer, I want to see that fixed
because all distros need to be able to distribute these files for the
kernel to work properly.

Oh, and other distros, with lots of lawyers, are distributing these
firmware images as a single package, so this needs to be resolved either
by realizing that our interpretation is incorrect, or that everyone is
wrong here.

thanks,

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/02/13 12:26 PM, Greg KH wrote:

>>>>> "Permission is hereby granted for the distribution [...] as
>>>>> part of a Linux or other Open Source operating system
>>>>> kernel"
> What is wrong with that?  We happen to be distributing a Linux
> operating system.
> 

"...as part of a Linux (...) *kernel*."  This (linux-firmware) isn't
being distributed as part of the kernel, or even with the kernel; it's
being distributed separately right?

When these particular firmwares were being distributed in-kernel, the
license would've been fine..  The license needs to be adjusted to
replace "as part of" with "for use with" or some similar change.

My interpretation of this is the concern you had also, ulm?  Apologies
for jumping in without fully reading the backlog (it seems to have
been going on for days)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEmXQEACgkQ2ugaI38ACPA3rwEApkmWZZISrLyB1RoFEOG+KsoS
vlalAvqcQr82mdIZ5qYBAKYziTD2OcHQ47SwaOegmooaPqHSHRj9P5G1APoNSpMr
=erNV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: linux-firmware

[Ulrich Mueller]

>>>>> On Thu, 21 Feb 2013, Greg KH wrote:

>> Ulrich Mueller (ulm) wrote this on the 16th:
>> 
>> > Look into the WHENCE file and be horrified. Taking just the first ten
>> > items (of a total 114):
>> > 
>> >    Unknown license (3 times)

> Which ones specifically?

Driver: snd-korg1212 -- Korg 1212 IO audio device
Driver: kaweth -- USB KLSI KL5USB101-based Ethernet device
Driver: dvb-ttusb-budget -- Technotrend/Hauppauge Nova-USB devices

>> >    GPL, but without source (3 times)

> Really?  Which?

Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM NIC.
Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device
Driver: qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support

>> >    "All rights reserved"

> That's not an issue, unless it is alone, is there something else in the
> license as well?

Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices

According to WHENCE, it is:
"Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved."
Nothing else.

>> >    BSD, without source

> There's no problem with that.

Driver: advansys - AdvanSys SCSI

Right, and it's the only one out of the first ten that we're allowed
to redistribute.

>> >    Right for redistribution not granted

> Huh?  Which?

Driver: smctr -- SMC ISA/MCA Token Ring adapter

>> >    "Permission is hereby granted for the distribution [...] as part of
>> >        a Linux or other Open Source operating system kernel"

> What is wrong with that?  We happen to be distributing a Linux operating
> system.

Driver: keyspan -- USB Keyspan USA-xxx serial device

We distribute it in a separate package. And it doesn't say "part of
an OS" but explicitly "part of a kernel".

>> > With one exception, we are not even allowed to redistribute these.

> I don't understand, please explain all of these in detail so that we can
> fix this upstream.

>> This is what we've been discussing about. This is not really about
>> Gentoo by itself, but the ability to distribute the sources at all, be
>> it from us or somebody else.

> I understand, and as an upstream developer, I want to see that fixed
> because all distros need to be able to distribute these files for the
> kernel to work properly.

> Oh, and other distros, with lots of lawyers, are distributing these
> firmware images as a single package, so this needs to be resolved either
> by realizing that our interpretation is incorrect, or that everyone is
> wrong here.

Can you show me a distro that distributes above-mentioned files?
Debian, for example, doesn't distribute them (AFAICS).

Ulrich

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Thu, Feb 21, 2013 at 07:33:48PM +0100, Ulrich Mueller wrote:
> >>>>> On Thu, 21 Feb 2013, Greg KH wrote:
> 
> >> Ulrich Mueller (ulm) wrote this on the 16th:
> >> 
> >> > Look into the WHENCE file and be horrified. Taking just the first ten
> >> > items (of a total 114):
> >> > 
> >> >    Unknown license (3 times)
> 
> > Which ones specifically?
> 
> Driver: snd-korg1212 -- Korg 1212 IO audio device
> Driver: kaweth -- USB KLSI KL5USB101-based Ethernet device
> Driver: dvb-ttusb-budget -- Technotrend/Hauppauge Nova-USB devices

As these originally came from the kernel source tree, they are "by
default" ok.

> >> >    GPL, but without source (3 times)
> 
> > Really?  Which?
> 
> Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM NIC.
> Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device
> Driver: qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support

Some of these came from the kernel source tree originally, others don't,
but they all imply that the GPL really isn't for the firmware itself.
Odd.

> >> >    "All rights reserved"
> 
> > That's not an issue, unless it is alone, is there something else in the
> > license as well?
> 
> Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices
> 
> According to WHENCE, it is:
> "Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved."
> Nothing else.

That's a copyright notice, not a license, so I don't know what to
suggest :)

> >> >    BSD, without source
> 
> > There's no problem with that.
> 
> Driver: advansys - AdvanSys SCSI
> 
> Right, and it's the only one out of the first ten that we're allowed
> to redistribute.
> 
> >> >    Right for redistribution not granted
> 
> > Huh?  Which?
> 
> Driver: smctr -- SMC ISA/MCA Token Ring adapter

Token ring drivers were dropped from the kernel already, so this isn't
an issue.

> >> >    "Permission is hereby granted for the distribution [...] as part of
> >> >        a Linux or other Open Source operating system kernel"
> 
> > What is wrong with that?  We happen to be distributing a Linux operating
> > system.
> 
> Driver: keyspan -- USB Keyspan USA-xxx serial device
> 
> We distribute it in a separate package. And it doesn't say "part of
> an OS" but explicitly "part of a kernel".

Ah, that's because at the time, that's the way it was originally
distributed.  Given that the company isn't around anymore, I don't think
this is going to be an issue :)

> 
> >> > With one exception, we are not even allowed to redistribute these.
> 
> > I don't understand, please explain all of these in detail so that we can
> > fix this upstream.
> 
> >> This is what we've been discussing about. This is not really about
> >> Gentoo by itself, but the ability to distribute the sources at all, be
> >> it from us or somebody else.
> 
> > I understand, and as an upstream developer, I want to see that fixed
> > because all distros need to be able to distribute these files for the
> > kernel to work properly.
> 
> > Oh, and other distros, with lots of lawyers, are distributing these
> > firmware images as a single package, so this needs to be resolved either
> > by realizing that our interpretation is incorrect, or that everyone is
> > wrong here.
> 
> Can you show me a distro that distributes above-mentioned files?
> Debian, for example, doesn't distribute them (AFAICS).

As far as I can tell, both SuSE and Red Hat distribute these today.  And
so does Canonical, but really, that can't be taken as "valid legal
usage" at all :)

Has anyone asked the upstream linux-firmware developers about these
files?

thanks for the detailed descriptions, much appreciated.

I think this is something that the Board needs to decide, after
discussing it with our lawyers, it's not something that non-legal people
(like myself) should be saying is the definitive answer.

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Ulrich Mueller]

>>>>> On Thu, 21 Feb 2013, Greg KH wrote:

> Has anyone asked the upstream linux-firmware developers about these
> files?

I don't know. I haven't, for my part. But maybe we should first try
to produce a more complete list, instead of reporting each file
separately? Given that most of the files are being distributed since
years, another few days cannot matter.

> thanks for the detailed descriptions, much appreciated.

> I think this is something that the Board needs to decide, after
> discussing it with our lawyers, it's not something that non-legal
> people (like myself) should be saying is the definitive answer.

I fully agree. And IANAL, so anything that I say about license issues
should be taken with a grain of salt.

Ulrich

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Thu, Feb 21, 2013 at 3:44 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 21 Feb 2013, Greg KH wrote:
>> I think this is something that the Board needs to decide, after
>> discussing it with our lawyers, it's not something that non-legal
>> people (like myself) should be saying is the definitive answer.
>
> I fully agree. And IANAL, so anything that I say about license issues
> should be taken with a grain of salt.

My recommendation would be to have the licensing team get things as
organized as they can, and escalate to the Trustees any cases where
the legal situation is unclear.  We can certainly seek legal counsel,
but as with all matters it is best for the licensing team to just take
care of issues which aren't controversial.

Rich

[gentoo-dev] Re: linux-firmware

[Duncan]

Greg KH posted on Thu, 21 Feb 2013 11:55:34 -0800 as excerpted:

> On Thu, Feb 21, 2013 at 07:33:48PM +0100, Ulrich Mueller wrote:
>> >>>>> On Thu, 21 Feb 2013, Greg KH wrote:
>> 
>> >> Ulrich Mueller (ulm) wrote this on the 16th:
>> >> 
>> >> > Look into the WHENCE file and be horrified. Taking just the first
>> >> > ten items (of a total 114):
>> >> > 
>> >> >    Unknown license (3 times)
>> 
>> > Which ones specifically?
>> 
>> Driver: snd-korg1212 -- Korg 1212 IO audio device Driver: kaweth -- USB
>> KLSI KL5USB101-based Ethernet device Driver: dvb-ttusb-budget --
>> Technotrend/Hauppauge Nova-USB devices
> 
> As these originally came from the kernel source tree, they are "by
> default" ok.

Well, not entirely.  It's exactly this sort of issue that's the reason 
many people were uncomfortable with firmware in the kernel at all, and 
why all the ongoing work to separate it out.

>> >> >    GPL, but without source (3 times)
>> 
>> > Really?  Which?
>> 
>> Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM
>> NIC.
>> Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device Driver:
>> qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support
> 
> Some of these came from the kernel source tree originally, others don't,
> but they all imply that the GPL really isn't for the firmware itself.
> Odd.

Again... precisely why this stuff's being gradually kicked out of the 
kernel in the first place.

>> >> >    "All rights reserved"
>> 
>> > That's not an issue, unless it is alone, is there something else in
>> > the license as well?
>> 
>> Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices
>> 
>> According to WHENCE, it is:
>> "Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved."
>> Nothing else.
> 
> That's a copyright notice, not a license, so I don't know what to
> suggest :)

See above...

>> >> >    BSD, without source
>> 
>> > There's no problem with that.
>> >
>> Driver: advansys - AdvanSys SCSI
>> 
>> Right, and it's the only one out of the first ten that we're allowed to
>> redistribute.

=:^)

>> >> >    Right for redistribution not granted
>> 
>> > Huh?  Which?
>> 
>> Driver: smctr -- SMC ISA/MCA Token Ring adapter
> 
> Token ring drivers were dropped from the kernel already, so this isn't
> an issue.

It's only an issue to the extent that we're still shipping it.

>> >> >    "Permission is hereby granted for the distribution [...] as
>> >> >    part of
>> >> >        a Linux or other Open Source operating system kernel"
>> 
>> > What is wrong with that?  We happen to be distributing a Linux
>> > operating system.
>> 
>> Driver: keyspan -- USB Keyspan USA-xxx serial device
>> 
>> We distribute it in a separate package. And it doesn't say "part of an
>> OS" but explicitly "part of a kernel".
> 
> Ah, that's because at the time, that's the way it was originally
> distributed.  Given that the company isn't around anymore, I don't think
> this is going to be an issue :)

But what about whoever bought up the rights?  In practice, that's 
precisely when many of these things BECOME an issue, when a new owner 
decides they can monetize...


In general, this is an ongoing problem for the entire community.  It's 
gradually being straightened out, but it's a years-long, likely decades 
long, project.

In practice, as long as nobody's suing, and because the overall trend is 
to clean things up, that's why most distros kind of wink and nudge and 
don't talk about it much.

But it's also one of the BIG reasons for the "firmwareless kernel" 
projects.  While they're not entirely practical for most people on their 
own, they DO serve the purpose of demonstrating that it's possible under 
limited circumstances and measuring how far we have to go...

-- 
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: linux-firmware

[Greg KH]

On Thu, Feb 21, 2013 at 09:44:12PM +0100, Ulrich Mueller wrote:
> >>>>> On Thu, 21 Feb 2013, Greg KH wrote:
> 
> > Has anyone asked the upstream linux-firmware developers about these
> > files?
> 
> I don't know. I haven't, for my part. But maybe we should first try
> to produce a more complete list, instead of reporting each file
> separately? Given that most of the files are being distributed since
> years, another few days cannot matter.

Such a list would be wonderful to have.

> > thanks for the detailed descriptions, much appreciated.
> 
> > I think this is something that the Board needs to decide, after
> > discussing it with our lawyers, it's not something that non-legal
> > people (like myself) should be saying is the definitive answer.
> 
> I fully agree. And IANAL, so anything that I say about license issues
> should be taken with a grain of salt.

I am willing to work with lawyers, who know these type of things quite
well, to get upstream straightened out, given that I was the one who
originally added firmware files to the kernel, oh so many years ago,
causing this problem...

This should be a cross-distro issue/solution, so I suggest working with
the Linux Foundation on this.  Anyone object to me doing that?

thanks,

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Rich Freeman]

On Thu, Feb 21, 2013 at 5:44 PM, Greg KH <gregkh@gentoo.org> wrote:
> This should be a cross-distro issue/solution, so I suggest working with
> the Linux Foundation on this.  Anyone object to me doing that?

Go for it (speaking only for myself, but I can't imagine the other
Trustees would be opposed)!

Rich

Re: [gentoo-dev] Re: linux-firmware

[David Abbott]

On Thu, Feb 21, 2013 at 6:18 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Feb 21, 2013 at 5:44 PM, Greg KH <gregkh@gentoo.org> wrote:
>> This should be a cross-distro issue/solution, so I suggest working with
>> the Linux Foundation on this.  Anyone object to me doing that?
>
> Go for it (speaking only for myself, but I can't imagine the other
> Trustees would be opposed)!
>
> Rich
>

Hi Greg,
I would appreciate your help.
Thanks,
David

-- 
David Abbott (dabbott)
Gentoo
http://dev.gentoo.org/~dabbott/

Re: [gentoo-dev] Re: linux-firmware

[Roy Bamford]

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

On 2013.02.21 23:18, Rich Freeman wrote:
> On Thu, Feb 21, 2013 at 5:44 PM, Greg KH <gregkh@gentoo.org> wrote:
> > This should be a cross-distro issue/solution, so I suggest working
> with
> > the Linux Foundation on this.  Anyone object to me doing that?
> 
> Go for it (speaking only for myself, but I can't imagine the other
> Trustees would be opposed)!
> 
> Rich
> 
> 

Works for me too, so thats a majority vote of Trustees.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]