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 Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote:
I agree that a smartcard is much better security vs a longer key. I
don't think attackers targetting Gentoo are going to brute force the
key. They are going to steal the key, trivially, by exploiting a 0-day
in a crappy browser, or
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
RHJ == Robin H Johnson robb...@gentoo.org writes:
RHJ 2. Root key type of RSA, 4096 bits
rsa 4k provides no real benefits over rsa 3k here; it is just slower
for everyone, signing or verifying.
Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which
recommends rsa 3k for use
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
Hi all,
I do not know whether this list is an appropriate place, so sorry if it
is not )
Recently I've wrote some little scripts that implement interface for
g-common type repositories of layman[1]. And I would ask those who is
interested to test them.
I've created two packages: g-common
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
On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote:
RHJ == Robin H Johnson robb...@gentoo.org writes:
RHJ 2. Root key type of RSA, 4096 bits
rsa 4k provides no real benefits over rsa 3k here; it is just slower
for everyone, signing or verifying.
You can shorten the subkeys, but the
-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
Am Mittwoch, 20. Februar 2013, 20:36:22 schrieb Robin H. Johnson:
Speed for i7-2600K CPU:
DSA1024 0.007980s
DSA2048 0.011940s
DSA3072 0.013530s
RSA1024 0.007000s
RSA2048 0.012290s
RSA3072 0.018420s
RSA4096 0.030800s
Which of course brings up the question, why the hardcoded 4096 limit
On Mon, 18 Feb 2013 23:27:46 +
Robin H. Johnson robb...@gentoo.org wrote:
3. Dedicated Gentoo signing subkey
What's the point of this, btw?
Luis
signature.asc
Description: PGP signature
On Wed, Feb 20, 2013 at 09:22:05PM +0100, Andreas K. Huettel wrote:
Which of course brings up the question, why the hardcoded 4096 limit in
GnuPG... but I guess that's not our problem yet.
https://www.google.de/search?q=gnupg+rsa+8192
Standards interoperability. RSA4096 will not work on legacy
On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote:
On Mon, 18 Feb 2013 23:27:46 +
Robin H. Johnson robb...@gentoo.org wrote:
3. Dedicated Gentoo signing subkey
What's the point of this, btw?
Ideally keeping your primary key offline to increase security.
However, the original
On Wed, 20 Feb 2013 21:37:38 +
Robin H. Johnson robb...@gentoo.org wrote:
Ideally keeping your primary key offline to increase security.
However, the original theory was that if there was some attack that
required a large amount of ciphertext or a targeted plaintext input,
you would be
El mar, 19-02-2013 a las 14:27 -0800, Zac Medico escribió:
On 02/19/2013 12:12 PM, Pacho Ramos wrote:
Hello
For some time I am running portage-2.1.x with preserve-libs enabled to
test it and try to prevent revdep-rebuild usage. Until now, I haven't
had any problems with it, but I
On 02/20/2013 12:53 PM, Pacho Ramos wrote:
El mar, 19-02-2013 a las 14:27 -0800, Zac Medico escribió:
On 02/19/2013 12:12 PM, Pacho Ramos wrote:
Hello
For some time I am running portage-2.1.x with preserve-libs enabled to
test it and try to prevent revdep-rebuild usage. Until now, I haven't
41 matches
Mail list logo
