On 2013.02.21 23:18, Rich Freeman wrote:
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH gre...@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
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,
-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.
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
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)
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
On Thu, Feb 21, 2013 at 3:44 PM, Ulrich Mueller u...@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
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
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
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH gre...@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)!
On Thu, Feb 21, 2013 at 6:18 PM, Rich Freeman ri...@gentoo.org wrote:
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH gre...@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
On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller u...@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
Duncan wrote:
Is it possible to tell git to only clone/pull specific files in a repo?
No.
//Peter
On Wed, 20 Feb 2013, Alec Warner wrote:
On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller u...@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
On Tue, Feb 19, 2013 at 11:43 PM, Duncan 1i5t5.dun...@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
2013/2/20 Rich Freeman ri...@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
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
Tomáš Chvátal schrieb:
2013/2/20 Rich Freeman ri...@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
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
On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
flamee...@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
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
-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,
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
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
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.
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@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
-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
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
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner anta...@gentoo.org wrote:
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@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
On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman ri...@gentoo.org wrote:
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner anta...@gentoo.org wrote:
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@stuge.se wrote:
It makes no sense to make that unneccessarily difficult for users.
I don't think
On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner anta...@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.
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
On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò
flamee...@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
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ò
flamee...@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
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
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
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
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:
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
On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn
chith...@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
-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
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
On Tue, Feb 19, 2013 at 8:43 PM, Duncan 1i5t5.dun...@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
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
44 matches
Mail list logo
