On 2013.02.21 23:18, Rich Freeman wrote:
> On Thu, Feb 21, 2013 at 5:44 PM, Greg KH 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
On Thu, Feb 21, 2013 at 6:18 PM, Rich Freeman wrote:
> On Thu, Feb 21, 2013 at 5:44 PM, Greg KH 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
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH 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
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 lis
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 ju
On Thu, Feb 21, 2013 at 3:44 PM, Ulrich Mueller 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 answe
> 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
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):
> >> >
> >> >Unknow
> 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 12
-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
> opera
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.
>
-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
On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn
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
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
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 o
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 Pro
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.
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 11:03:47AM -0500, Rich Freeman wrote:
> On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
> 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-
On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò
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 th
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 pus
On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner 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 h
On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman wrote:
> On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote:
>> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote:
>>>
>>> It makes no sense to make that unneccessarily difficult for users.
>>
>> I don't think fetch restriction is that annoying. Yo
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote:
> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge 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
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 stil
-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 agre
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge 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 *an
> 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 sof
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 peopl
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 versi
-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
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 tha
On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
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 chec
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 Pe
Tomáš Chvátal schrieb:
> 2013/2/20 Rich Freeman :
>> 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 referen
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 manife
2013/2/20 Rich Freeman :
> 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 conten
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 ups
> On Wed, 20 Feb 2013, Alec Warner wrote:
> On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller 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 redistribut
Duncan wrote:
> Is it possible to tell git to only clone/pull specific files in a repo?
No.
//Peter
On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller 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
> 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.c
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 \
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
44 matches
Mail list logo
