[gentoo-dev] Should we list sys-apps/sed in DEPEND
... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On 19 February 2013 13:10, Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ No you should not. It is a system package for every arch because it's listed in base/packages so every arch should have it. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On Tue, 19 Feb 2013 14:10:33 +0100 Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas Gnu sed version 4 is guaranteed by pms [1] [1] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12500011.3.1 signature.asc Description: PGP signature
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
Hi thomas, @all: Thanks for bring up this for discussion.. I think 'embedded' profile have only one sys-apps/busybox as system package, but seems this profile haven't updated for long time, and may become obsolete.. Dennis On Tue, Feb 19, 2013 at 9:10 PM, Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On Tue, 19 Feb 2013 14:10:33 +0100 Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? No. sed is required by POSIX, so it shall always be there. Additionally, it's provided by PMS too. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] linux-firmware
-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: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Mon, 7 Jan 2013 00:02:33 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org wrote: [...] + 07 Jan 2013; Mike Frysinger vap...@gentoo.org profiles.desc: + Mark s390 profiles stable. + 06 Jan 2013; Justin Bronder jsbron...@gentoo.org package.mask: Remove net-nntp/sabnzbd mask, fix already released and updated in tree. [...] --- profiles.desc 3 Jan 2013 16:08:06 - 1.201 +++ profiles.desc 7 Jan 2013 00:02:32 - 1.202 @@ -122,10 +122,10 @@ ppc64 default/linux/powerpc/ppc64/10.0/64bit-userland/server dev # S390 Profiles -s390default/linux/s390/10.0 dev -s390default/linux/s390/10.0/s390x dev -s390default/linux/s390/10.0/server dev -s390default/linux/s390/10.0/server/s390xdev +s390default/linux/s390/10.0 stable +s390 default/linux/s390/10.0/s390x stable +s390default/linux/s390/10.0/server stable +s390 default/linux/s390/10.0/server/s390xstable # SH Profiles sh default/linux/sh/10.0 dev please run 'repoman full | grep s390' on gentoo-x86 and fix the broken deps, they are now errors and I just hit one: dependency.bad16 app-text/texlive-core/texlive-core-2011-r6.ebuild: DEPEND: s390(default/linux/s390/13.0) ['media-libs/silgraphite'] A.
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On Tue, 2013-02-19 at 14:10 +0100, Thomas Kahle wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas Only if the pkg is also a system package. I recently ran into a problem running a catalyst build because portage-utils did not list the xz-utils dep which was another system package. It failed to unpack because xz-utils was still waiting to be merged. I was running catalyst with --jobs=3.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:38 PM, Kent Fredric kentfred...@gmail.com wrote: The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. Some material I read recommended doing a key rotation every 6 months, which I did for a while until it got tiresome to perform the rotation. It turns out that real security is very inconvenient ;) I believe the rationale behind it was basically, the longer you use a key, and the more data you produce signed by a key, the more leverage an attacker has against you to compromise the key. But I have no idea if that is really relevant or not. Trust is not really conferred by 'how much you have signed with the key.' It is conferred by 'how many people trust your key.' It is unclear to me how difficult this is to calculate in practice for an attacker. You rotate keys nominally because during routine key handling, your key (unless it is stored in a smartcard) is exposed to risk during use (the key material is mlocked in memory, or they can chat with your gpg-agent to sign content, or try to steal the key material, or steal the passphrase, and so forth.) If someone got your key, they can only sign data with it for $INTERVAL until it expires and you generate a new key. The attacker has no incentive to renew the key for you, because that would expose him, as he has to publish the renewal. All of this is similar in scope to changing your password every $INTERVAL, which is standard security practice. Generally speaking if the attacker is running code as you, or as root, on the machine that you are signing content on, you are already screwed. If the attacker has persistent access to your machine, generating a new key does not help at all (he will get that one too.) A common guard against this is simply to perform host attestation. I don't think that is in scope for Gentoo though :) -A -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
2013/2/19 Brian Dolbec dol...@gentoo.org: On Tue, 2013-02-19 at 14:10 +0100, Thomas Kahle wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas Only if the pkg is also a system package. I recently ran into a problem running a catalyst build because portage-utils did not list the xz-utils dep which was another system package. It failed to unpack because xz-utils was still waiting to be merged. I was running catalyst with --jobs=3. That is what unpacker_src_uri_depends from unpacker.eclass is intended for. DEPEND+=$(unpacker_src_uri_depends) -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On 02/19/2013 07:21 AM, Brian Dolbec wrote: On Tue, 2013-02-19 at 14:10 +0100, Thomas Kahle wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas Only if the pkg is also a system package. I recently ran into a problem running a catalyst build because portage-utils did not list the xz-utils dep which was another system package. It failed to unpack because xz-utils was still waiting to be merged. I was running catalyst with --jobs=3. If it's not in $PORTDIR/profiles/default/linux/packages.build then it's not necessarily included in stage1 and therefore you can't rely on it for stage1 - stage2 - stage3. If that's the case, then it has to be in *DEPEND for anything in stage3. -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Tue, Feb 19, 2013 at 7:19 AM, Alexis Ballier aball...@gentoo.org wrote: On Mon, 7 Jan 2013 00:02:33 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org wrote: [...] + 07 Jan 2013; Mike Frysinger vap...@gentoo.org profiles.desc: + Mark s390 profiles stable. + 06 Jan 2013; Justin Bronder jsbron...@gentoo.org package.mask: Remove net-nntp/sabnzbd mask, fix already released and updated in tree. [...] --- profiles.desc 3 Jan 2013 16:08:06 - 1.201 +++ profiles.desc 7 Jan 2013 00:02:32 - 1.202 @@ -122,10 +122,10 @@ ppc64 default/linux/powerpc/ppc64/10.0/64bit-userland/server dev # S390 Profiles -s390default/linux/s390/10.0 dev -s390default/linux/s390/10.0/s390x dev -s390default/linux/s390/10.0/server dev -s390default/linux/s390/10.0/server/s390xdev +s390default/linux/s390/10.0 stable +s390 default/linux/s390/10.0/s390x stable +s390default/linux/s390/10.0/server stable +s390 default/linux/s390/10.0/server/s390xstable # SH Profiles sh default/linux/sh/10.0 dev please run 'repoman full | grep s390' on gentoo-x86 and fix the broken deps, they are now errors and I just hit one: dependency.bad16 app-text/texlive-core/texlive-core-2011-r6.ebuild: DEPEND: s390(default/linux/s390/13.0) ['media-libs/silgraphite'] A. Yep, me too with a Mesa revision bump.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some quick thoughts on this: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits I don't really agree. From your own link (https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#dont-use-pgp-mit-edu): Many people still have 1024-bit DSA keys. You really should consider transitioning to a stronger bit-length and hashing algo. This size is known now to be within Well Funded Organizations’ ability to break. Also the hashing algo is showing its age. Some more opinions from different studies: keylength.com. 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Best regards, Craig -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEkGjEACgkQuiczp+KMe7SkWACgrioKjFkuPwJOxUCmhGKcC4Ib uyQAmwUfM7u3x6sD1rmQJrEjjUu7C6ok =OyqH -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits ... 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) A physical token defends against a different method of attack than a longer key. Simply having a longer key isn't going to help you if store the key on the laptop and it gets compromised: presuming the attacker extracts your secret key and passphrase). In such a case, the smartcard at worst limits him to doing some number of signatures only, or even better if the reader has a hardwired pinpad, he gets nowhere at all. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? NOWHERE did I require key rotation. Why do you think that I did? My own key is more than a decade old. I need to see about replacing it soon, but I've been trying to hold out for the OpenPGP standard to have ECC included, before I repeat getting my extremely large web-of-trust. 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box. Average of running clearsign ~100 times, for various signature types. The gpg.conf was set as in my initial post. DSA1024 0.059830s DSA2048 0.158800s DSA3072 0.274850s RSA1024 0.060020s RSA2048 0.173070s RSA4096 0.896480s For reasons of time, while I wanted to create the keys on the host as well for timing, I gave up after the first key, DSA1024, took more than 3 minutes (I did ensure that /dev/random was not the blocking factor). If somebody from MIPS or m68k wants to chime in, I think they probably have the slowest hardware around presently. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: linux-firmware
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
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 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] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 7:12 PM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits ... 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) A physical token defends against a different method of attack than a longer key. Simply having a longer key isn't going to help you if store the key on the laptop and it gets compromised: presuming the attacker extracts your secret key and passphrase). In such a case, the smartcard at worst limits him to doing some number of signatures only, or even better if the reader has a hardwired pinpad, he gets nowhere at all. I'm a bit confused. 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 flash, or java, or whatever. A smartcard is the defense against this attack (because the key material is well protected, and they need physical access to actually relocate it.) Storing it in the TPM would also be cool, except TPMs are crap on Linux, *and* most hardware TPMs are crap anyway. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I would ask the opposite question. What is the perceived difficulty in using DSA2048 vs 1024? For the non-smartcard users, the cost is likely trivial. Even your perf data shows that signing requests still complete in 200ms or less, and that is on old / slow hardware. I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? NOWHERE did I require key rotation. Why do you think that I did? My own key is more than a decade old. I need to see about replacing it soon, but I've been trying to hold out for the OpenPGP standard to have ECC included, before I repeat getting my extremely large web-of-trust. 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box. Average of running clearsign ~100 times, for various signature types. The gpg.conf was set as in my initial post. DSA1024 0.059830s DSA2048 0.158800s DSA3072 0.274850s RSA1024 0.060020s RSA2048 0.173070s RSA4096 0.896480s For reasons of time, while I wanted to create the keys on the host as well for timing, I gave up after the first key, DSA1024, took more than 3 minutes (I did ensure that /dev/random was not the blocking factor). If somebody from MIPS or m68k wants to chime in, I think they probably have the slowest hardware around presently. djm works for Google, and I chat with him at least once a quarter. I've seen some patches go by that we could re-purpose for gpg-agent forwarding. For slow machines we could have them sign on a faster-trusted machine with a forwarded agent. -A -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: linux-firmware
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
[gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update
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 started to test it after being running udev-19x for a long time. Yesterday, my father mailed me because he got udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt gcc, keeping other broken packages untouched (while revdep-rebuild rebuilt them) Do you know what kind of information could I demand him to help diagnose the problem? Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update
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 started to test it after being running udev-19x for a long time. Yesterday, my father mailed me because he got udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt gcc, keeping other broken packages untouched (while revdep-rebuild rebuilt them) Do you know what kind of information could I demand him to help diagnose the problem? It only works if the broken packages have references to the libudev.so.0 (or maybe libgudev-1.0.so.0) soname in their /var/db/pkg/*/*/NEEDED.ELF.2 files. -- Thanks, Zac
