[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-06-17 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-06-17 23h59 UTC. Removals: x11-libs/libPropList2012-06-14 15:45:59 ssuominen app-pda/synce-connector 2012-06-15 09:24:10 ssuominen dev-libs/librapi2 2012-06-15 09:26:07 ssuominen dev-libs/libsynce 2012-06-15 09:26:07 ssuominen dev-python/4suite 2012-06-16 07:49:19 dev-zero app-benchmarks/bootchart2012-06-16 11:49:09 pacho dev-embedded/parapin-driver 2012-06-16 11:51:01 pacho dev-perl/adocman2012-06-16 11:51:35 pacho media-tv/linuxtv-dvb2012-06-16 11:52:15 pacho media-video/undvd 2012-06-16 11:52:57 pacho media-sound/ssrc2012-06-16 11:53:41 pacho net-firewall/ipchains 2012-06-16 11:54:19 pacho media-libs/libflash 2012-06-16 11:54:43 pacho net-fs/fusesmb 2012-06-16 11:55:37 pacho app-mobilephone/galicesms 2012-06-16 11:56:49 pacho net-misc/batman-vis 2012-06-16 11:57:30 pacho net-misc/batmand2012-06-16 11:57:30 pacho www-plugins/libflashsupport 2012-06-16 11:58:09 pacho sys-kernel/xen-sources 2012-06-16 12:00:27 pacho media-gfx/flphoto 2012-06-16 12:01:28 pacho app-office/gnotime 2012-06-16 12:02:23 pacho app-crypt/quintuple-agent 2012-06-16 12:03:48 pacho app-misc/rio500 2012-06-16 12:04:21 pacho dev-ada/tash2012-06-16 12:06:37 pacho sci-physics/abinit 2012-06-16 12:07:12 pacho x11-misc/xsimpsons 2012-06-16 12:08:23 pacho sys-kernel/sparc-sources2012-06-16 12:08:54 pacho x11-misc/xmbdfed2012-06-16 12:09:41 pacho x11-misc/fme2012-06-16 12:10:10 pacho x11-misc/fspanel2012-06-16 12:10:43 pacho x11-misc/fxred 2012-06-16 12:11:04 pacho games-arcade/ssc2012-06-16 12:13:10 pacho app-dicts/sumika2012-06-16 12:13:56 pacho app-dicts/canna-canada-med 2012-06-16 12:16:41 pacho app-dicts/canna-shion 2012-06-16 12:16:41 pacho app-dicts/canna-zipcode 2012-06-16 12:16:41 pacho media-sound/squeezeboxserver2012-06-16 12:17:29 pacho Additions: sys-libs/libseccomp 2012-06-11 17:48:39 vapier net-wireless/iwl2030-ucode 2012-06-12 19:15:48 vapier app-dicts/myspell-sq2012-06-13 15:41:43 scarabeus sys-process/numad 2012-06-14 05:13:03 cardoe x11-misc/appmenu-qt 2012-06-14 12:06:48 kensington x11-libs/libproplist2012-06-14 15:43:21 ssuominen sci-libs/shogun 2012-06-14 17:16:03 bicatali dev-lang/ispc 2012-06-14 17:31:34 ottxor media-sound/opus-tools 2012-06-14 19:12:22 lu_zero dev-lang/libcilkrts 2012-06-14 19:38:03 ottxor x11-themes/zukini 2012-06-15 01:09:09 ssuominen games-misc/bsod 2012-06-15 03:23:09 ssuominen app-pda/synce-core 2012-06-15 07:52:42 ssuominen dev-python/cliapp 2012-06-15 10:16:15 mschiff dev-python/larch2012-06-15 10:17:07 mschiff dev-python/tracing 2012-06-15 10:17:56 mschiff dev-python/ttystatus2012-06-15 10:18:46 mschiff app-backup/obnam2012-06-15 10:24:15 mschiff app-text/zathura-cb 2012-06-15 12:34:43 ssuominen net-libs/libosmocore2012-06-15 13:51:23 chithanh dev-ruby/aws-sdk2012-06-15 14:46:52 flameeyes dev-haskell/polyparse 2012-06-16 09:50:41 gienah sys-apps/etckeeper 2012-06-16 16:01:51 hasufell dev-perl/PerlIO-Layers 2012-06-16 19:52:48 bicatali dev-perl/Hash-MoreUtils 2012-06-16 19:55:44 flameeyes dev-perl/Const-Fast 2012-06-16 19:55:52 bicatali dev-perl/File-Map 2012-06-16 19:56:54 bicatali dev-perl/OpenGL 2012-06-16 19:59:01 bicatali dev-perl/String-RewritePrefix 2012-06-16 20:04:29 flameeyes perl-core/ExtUtils-Constant 2012-06-16 20:06:08 tove virtual/perl-ExtUtils-Constant 2012-06-16 20:09:48
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 4:30 PM, Florian Philipp wrote: > Am 17.06.2012 20:56, schrieb Sascha Cunz: >> I was under the impression that it should at least help in that scenario. >> OTOH, if it takes a compromised system or physical access to the machine in >> order to manipulate the boot sequence, then I no longer understand what the >> boot sequence in such a system must be protected against (Assuming that the >> primary reason for boot sequence manipulation is to later on compromise the >> system). >> > > Well, it does help, especially when you also prevent changing UEFI > settings with a password. However, there are so many variables and > possibilities when talking about attacks on physically accessible > systems, that you're usually screwed anyway. I'd view secure boot as complementary to TPM. TPM keeps somebody with physical access from being able to access important information on your computer, since that data would be encrypted and the keys would not be surrendered by the TPM module without a proper chain of trust. TPM is potentially more secure, although it has a fatal flaw in that if the OS is compromised then the keys can be obtained (since the OS needs the keys to access the disk) and a trojan can be installed on the bootloader. That trojan is difficult to remove or even detect even if you update your virus scanners/etc. Secure boot keeps trojans out of the early boot chain, making them easier to clean up once your system is further updated. Secure boot is also somewhat easier to implement, and a bit more recoverable if things go wrong. If you're using TPM and trusted grub and all that, then if you mess up your trusted boot chain then you may never get back the contents of your drive, unless you kept a copy of various keys elsewhere. Rich
Re: [gentoo-dev] About what would be included in EAPI5
On Saturday 16 June 2012 08:12:13 Ulrich Mueller wrote: > > On Sat, 16 Jun 2012, Pacho Ramos wrote: > > I would like to know if there is some place where things going to be > > included (or proposed to be included) for eapi5 are listed (if such > > place exists). Currently, looks like there is no eapi5 tracker :-/ > > The PMS git repository has an eapi-5 development branch, and some > parallel discussion took place in the gentoo-pms mailing list. > > So far we have: > ╓ > ║ EAPI 5 is EAPI 4 with the following changes: > ║ > ║ • econf adds --disable-silent-rules. > ║ • Slot operator dependencies. > ║ • src_test supports parallel tests. > ║ • USE is calculated differently. > ║ • IMAGE is gone. > ║ • REQUIRED_USE now supports ?? groups. > ║ • apply_user_patches function, with src_prepare changes. > ║ • EBUILD_PHASE_FUNC. > ║ • find is guaranteed to be GNU. > ║ • new* can read from standard input. > ╙ usex() should be there too considering its simplicity and the API already being ironed out and in active use -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, 17 Jun 2012 21:38:50 +0100 Ciaran McCreesh wrote: > On Sun, 17 Jun 2012 22:31:59 +0200 > Michał Górny wrote: > > A simple solution to a program long-unsolved. In GLEP form. > > > > Both attached and published as a gist: > > > > https://gist.github.com/2945569 > > Do you have an implementation we can play with? Not yet. But expect one in the next few days. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, 17 Jun 2012 22:31:59 +0200 Michał Górny wrote: > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 Do you have an implementation we can play with? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Hello, A simple solution to a program long-unsolved. In GLEP form. Both attached and published as a gist: https://gist.github.com/2945569 (please note that github doesn't render GLEP headers correctly) -- Best regards, Michał Górny GLEP: XXX Title: Optional runtime dependencies via runtime-switchable USE flags Version: $Revision:$ Last-Modified: $Date:$ Author: MichaÅ Górny Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17 Jun 2012 Post-History: Abstract This GLEP addresses the issue of referencing optional runtime dependencies in Gentoo packages and ebuilds. It does introduce a concept of runtime-switchable USE flags to achieve that goal. Motivation == Optional runtime dependencies are often found in packages installing various scripts (shell, python, perl). These are not strictly required for the particular package to work but installing them enables additional functionality. Unlike in compiled programs, enabling or disabling those features (dependencies) does not affect the files installed by the package. They can be installed and uninstalled independently of the package, resulting in changes of functionality without a need to rebuild the package. Currently such dependencies are usually expressed only through ``pkg_postinst()`` messages. This forces user to manually install the necessary dependencies, and uninstall them when they are no longer necessary. Another solution is using regular USE flags. Those flags do not strictly follow the principles of USE flags because they do not affect files installed by the package and are not entirely effective to the package (a disabled feature will still be available if necessary dependency is installed). Additionally, it requires unnecessary rebuilds of the package in order to change the dependencies. Specification = The ebuilds aiming to provide features enabled through optional runtime dependencies should: 1. create regular USE flags for all those features, following appropriate specifications for Gentoo ebuilds, and including the flags in the ``IUSE`` variable; 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE flags related to optional runtime dependencies (without prefixes related to IUSE defaults). Additionally, the ebuilds must obey the following rules: 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``, 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``, ``PDEPEND`` and ``REQUIRED_USE`` variables, 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase functions, ``DEPEND`` or ``SRC_URI``, 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE dependencies by other packages' ``DEPEND``, ``RDEPEND`` and ``PDEPEND`` variables. The package manager should treat flags listed in ``IUSE_RUNTIME`` as regular USE flags, except for the following: 1. the state of the flags must be re-evaluated each time the package dependency graph is considered, 2. enabling or disabling any of the flags must not involve rebuilding the package, 3. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. Rationale = The proposed solution tries to solve the issue of handling runtime dependencies while reusing the existing infrastructure. Most importantly, users will be able to reuse the existing tools and configuration files to enable and disable optional runtime and build-time dependencies alike. The remaining reused features include: - dependency syntax, - ability to use ``REQUIRED_USE``, USE dependencies, - ability to describe flags in `metadata.xml`, - global flag names (and descriptions). Alternative proposed solution involved creating additional ``SDEPEND`` variable. That proposition had the following disadvantages: - being package-oriented rather than feature-oriented, - lack of ability to express multiple packages required by a single feature, - lack of ability to express cross-feature dependencies, - lack of ability to describe features provided by enabled packages, - necessity of implementing a new user interface parts to control the dependencies, - lack of backwards compatibility. Backwards compatibility === Package managers not implementing this GLEP will consider the ``IUSE_RUNTIME`` variable as an irrelevant bash variable and treat runtime-switchable USE flags as regular USE flags. The dependency tree will still be consistent yet packages may be rebuilt unnecessarily. Copyright = This document has been placed in the public domain. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 20:56, schrieb Sascha Cunz: > On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: >> Am 17.06.2012 19:34, schrieb Sascha Cunz: >>> [...] >>> It doesn't. It's just a very long wooden fence; you just didn't find the hole yet. >>> >>> Given the fact that the keys in the BIOS must somehow get there and it >>> must >>> also be able to update them (how to revoke or add keys else?). >>> >>> Unless this is completely done in hardware, there must be a software doing >>> it. Software can - by design - be reverse engineered; in some countries >>> even legally without any further agreement or license. >>> >>> So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on >>> this blob of software - at some point it must be readable from the >>> processor, so you have to provide the mechanisms to verify signs, undo >>> encryption etc somewhere (either in hardware or another software). >>> >>> Even if you somehow manage to embed all of this in the hardware stack, it >>> would still require some kind of interface to get updated / revoked keys >>> to >>> operate on. >>> >>> It's not a matter of *if this can* be broken by someone who cares, it's a >>> matter of *how long does it take* for someone who cares to break it. >>> >>> In the end, this is just another kind of "seems to be secure for a day or >>> two". Admittedly a complex one - but there will always be a "kid in a >>> garage" that is able to set everyone else out of business. >>> >>> SaCu >> >> Okay, a few points here: >> >> First: On an abstract level, the key innovation in Secure Boot and >> driver signing is that it establishes a trust relationship between >> platform owner and platform firmware (using a so called Platform Key) as >> well as trust between operating system and platform firmware (using Key >> Exchange Keys). > > You've said yourself, that "some removable media might not require > signatures" > in order to boot. Well, if that is the case, then isn't this defeating the > whole point of Secure Boot at that stage? > No. If that was the case, then UEFI shouldn't allow deactivating Secure Boot, should it? Secure Boot's primary purpose is to prevent malware from installing itself into the bootloader or (by extension) the kernel image. >> Under the assumption that the implementation is correct, nothing on the >> operating system level can inject drivers, boot loaders or whatever else >> into the firmware unless it is properly signed. The platform will not >> allow anything unless it is bit-by-bit verified to come from the >> platform owner or a trusted third party. The recommended algorithms for >> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking >> that in "a day or two"! >> >> Second point: Secure Boot is not designed to protect against an attacker >> with physical access to the machine. So you can leave your soldering >> iron and memory stick at home when you try to prove that Secure Boot can >> be broken. > > I was under the impression that it should at least help in that scenario. > OTOH, if it takes a compromised system or physical access to the machine in > order to manipulate the boot sequence, then I no longer understand what the > boot sequence in such a system must be protected against (Assuming that the > primary reason for boot sequence manipulation is to later on compromise the > system). > Well, it does help, especially when you also prevent changing UEFI settings with a password. However, there are so many variables and possibilities when talking about attacks on physically accessible systems, that you're usually screwed anyway. Again, the point is that malware, even if it gets temporary access to your system, even if it gets root access, cannot install itself into the boot process. It cannot persist in kernel space. >> Third point: Of course Secure Boot will be broken! A mainboard maker >> will screw up, there will be a bug in the specs or RSA will be broken. >> And when one of these happens, it will be fixed. Plain and simple. We >> didn't abandon SSL just because version 1 and 2 were broken. Why should >> we abandon Secure Boot? > > "Plain and simple" here probably means, that all (at least many) sold system > up to that date are downgraded to "unsecure". Not every user out there is > reachable by any channel telling that it is just now a hard requirement to > update the system - and even getting the message to the user won't cause 100% > of the reached users to go that upgrade path. > Yes, you are right here. But ultimately, any bugs will be fixed. Even if it means waiting for the next device generation. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 8:03 PM, Greg KH wrote: > Huh? No, why would a user need to resign the UEFI drivers? Those > "live" in the BIOS and are only used to get the machine up and running > in UEFI space, before UEFI hands the control off to the bootloader it > has verified is signed with a correct key. Is that always the case? E.g., kernel's efifb module uses the EFI console driver, similarly to legacy BIOS's VESA interface. It is possible that in the future more OS-usable EFI drivers will become commonplace, especially for non-performance-critical periphery interaction (sensors, etc.). Architecture-independent EFI bytecode drivers apparently don't have OS interface now, but this could change as well. >> If the user does not perform this procedure (due to its >> complexity and/or lack of tools automating the process), is it >> possible for an externally connected device to compromise the system >> by supplying a Microsoft-signed blob directly to the UEFI firmware, >> circumventing the (Linux) OS? > > Again, what? Please explain. I am thinking about a possibility where a “rogue” device can upload its driver directly to the UEFI firmware. I don't see something like that in the UEFI spec, but perhaps the firmware can support such behavior outside the spec. E.g., many 3G network tokens support presenting themselves as network devices or as storage media on the USB bus (sys-apps/usb_modeswitch deals with that). The reason they do that is for the OS to install the network driver from the storage media “representation”. Now, imagine that the OS defers handling of unfamiliar network devices to the UEFI network driver (as it might do with unfamiliar video cards and UEFI GOP). It makes sense that UEFI firmware vendors would support a similar mechanism of loading (possibly EBC) UEFI drivers from the network device. Why not — the drivers will be signed, and UEFI can verify the signatures. So it seems to me that UEFI, because of its complexity and multitude of features, may provide an OS-circumventing attack vector, which can only be dealt with by revoking (probably Microsoft) keys in UEFI firmware, and re-signing only the necessary drivers with a custom key. Compromising major player's certificates is a real possibility — e.g., see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft. > What API? The signing tool is public, and no, it doesn't add keys, > that's up to the BIOS to do, not the userspace tool. So the re-signing mentioned above must be done in a tedious manual process? Or can some automatic tool be developed (not necessary userspace, it can be an EFI app)? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Sascha Cunz writes: > You've said yourself, that "some removable media might not require > signatures" > in order to boot. Well, if that is the case, then isn't this defeating the > whole point of Secure Boot at that stage? Not necessarily. As has been stated previously, secure boot is not intended to protect against an attacker who has physical access. So even if allowing boot from removable media, it does protect against malware which corrupts/infects the hard drive boot image.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: > Am 17.06.2012 19:34, schrieb Sascha Cunz: > > [...] > > > >> It doesn't. It's just a very long wooden fence; you just didn't find > >> the hole yet. > > > > Given the fact that the keys in the BIOS must somehow get there and it > > must > > also be able to update them (how to revoke or add keys else?). > > > > Unless this is completely done in hardware, there must be a software doing > > it. Software can - by design - be reverse engineered; in some countries > > even legally without any further agreement or license. > > > > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on > > this blob of software - at some point it must be readable from the > > processor, so you have to provide the mechanisms to verify signs, undo > > encryption etc somewhere (either in hardware or another software). > > > > Even if you somehow manage to embed all of this in the hardware stack, it > > would still require some kind of interface to get updated / revoked keys > > to > > operate on. > > > > It's not a matter of *if this can* be broken by someone who cares, it's a > > matter of *how long does it take* for someone who cares to break it. > > > > In the end, this is just another kind of "seems to be secure for a day or > > two". Admittedly a complex one - but there will always be a "kid in a > > garage" that is able to set everyone else out of business. > > > > SaCu > > Okay, a few points here: > > First: On an abstract level, the key innovation in Secure Boot and > driver signing is that it establishes a trust relationship between > platform owner and platform firmware (using a so called Platform Key) as > well as trust between operating system and platform firmware (using Key > Exchange Keys). You've said yourself, that "some removable media might not require signatures" in order to boot. Well, if that is the case, then isn't this defeating the whole point of Secure Boot at that stage? > Under the assumption that the implementation is correct, nothing on the > operating system level can inject drivers, boot loaders or whatever else > into the firmware unless it is properly signed. The platform will not > allow anything unless it is bit-by-bit verified to come from the > platform owner or a trusted third party. The recommended algorithms for > signing and verifying code are SHA-256 and RSA-2048. Good luck breaking > that in "a day or two"! > > Second point: Secure Boot is not designed to protect against an attacker > with physical access to the machine. So you can leave your soldering > iron and memory stick at home when you try to prove that Secure Boot can > be broken. I was under the impression that it should at least help in that scenario. OTOH, if it takes a compromised system or physical access to the machine in order to manipulate the boot sequence, then I no longer understand what the boot sequence in such a system must be protected against (Assuming that the primary reason for boot sequence manipulation is to later on compromise the system). > Third point: Of course Secure Boot will be broken! A mainboard maker > will screw up, there will be a bug in the specs or RSA will be broken. > And when one of these happens, it will be fixed. Plain and simple. We > didn't abandon SSL just because version 1 and 2 were broken. Why should > we abandon Secure Boot? "Plain and simple" here probably means, that all (at least many) sold system up to that date are downgraded to "unsecure". Not every user out there is reachable by any channel telling that it is just now a hard requirement to update the system - and even getting the message to the user won't cause 100% of the reached users to go that upgrade path. SaCu
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 19:34, schrieb Sascha Cunz: > [...] > >> It doesn't. It's just a very long wooden fence; you just didn't find >> the hole yet. > > Given the fact that the keys in the BIOS must somehow get there and it must > also be able to update them (how to revoke or add keys else?). > > Unless this is completely done in hardware, there must be a software doing > it. > Software can - by design - be reverse engineered; in some countries even > legally without any further agreement or license. > > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on > this blob of software - at some point it must be readable from the processor, > so you have to provide the mechanisms to verify signs, undo encryption etc > somewhere (either in hardware or another software). > > Even if you somehow manage to embed all of this in the hardware stack, it > would still require some kind of interface to get updated / revoked keys to > operate on. > > It's not a matter of *if this can* be broken by someone who cares, it's a > matter of *how long does it take* for someone who cares to break it. > > In the end, this is just another kind of "seems to be secure for a day or > two". Admittedly a complex one - but there will always be a "kid in a garage" > that is able to set everyone else out of business. > > SaCu > Okay, a few points here: First: On an abstract level, the key innovation in Secure Boot and driver signing is that it establishes a trust relationship between platform owner and platform firmware (using a so called Platform Key) as well as trust between operating system and platform firmware (using Key Exchange Keys). Under the assumption that the implementation is correct, nothing on the operating system level can inject drivers, boot loaders or whatever else into the firmware unless it is properly signed. The platform will not allow anything unless it is bit-by-bit verified to come from the platform owner or a trusted third party. The recommended algorithms for signing and verifying code are SHA-256 and RSA-2048. Good luck breaking that in "a day or two"! Second point: Secure Boot is not designed to protect against an attacker with physical access to the machine. So you can leave your soldering iron and memory stick at home when you try to prove that Secure Boot can be broken. Third point: Of course Secure Boot will be broken! A mainboard maker will screw up, there will be a bug in the specs or RSA will be broken. And when one of these happens, it will be fixed. Plain and simple. We didn't abandon SSL just because version 1 and 2 were broken. Why should we abandon Secure Boot? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 07:06:16PM +0200, Michał Górny wrote: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > > > On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > > > 2. What happens if, say, your bootloader is compromised? > > > > And how would this happen? Your bootloader would not run. > > Yes. I'm asking what happens next. Is there an easy way to replace it? I do not know, you need to test this on a UEFI secure boot system to see what happens. > Or is your computer bricked until you run some other bootloader to > replace the compromised one? Probably. > > > 3. What happens if the machine signing the blobs is compromised? > > > > So, who's watching the watchers, right? Come on, this is getting > > looney. > > I'm just pointing out that this simply relies on trusting people. Much > like not having those signatures. Of course, this is life, and should not be anything "new" to you or anyone else. And before you get upset, do you trust the "people" who implemented the firmware in your processor and I/O controllers? This argument is not one that is worth discussing. greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 1:34 PM, Sascha Cunz wrote: > > Given the fact that the keys in the BIOS must somehow get there and it must > also be able to update them (how to revoke or add keys else?). Based on what I've read the keys are stored in flash. The flash module itself is protected. There are a number of ways to implement something like this fairly securely. The simplest is to have an unprotected area of the flash that the OS can write to. Upon bootup the firmware looks in this area for a signed message. If the message is signed by a trusted source, then the firmware interprets it as instructions to update itself, add/remove keys, or whatever. Then before booting the OS the firmware sets the protect flag on the protected area of flash that is only unset by a hardware reset. The only software exploit against something like this is to find a bug in the code that inspects the flash (overflow/etc) to trick it into running an unsigned blob. There are also hardware attacks, like bypassing flash protection hardware, directly accessing flash, or controlling what shows up on the data bus when the CPU tries to read the firmware. Any of these can be made fairly difficult, and extreme case being how modern gaming consoles work (flash embedded in CPU, and so on). > > Unless this is completely done in hardware, there must be a software doing it. > Software can - by design - be reverse engineered; in some countries even > legally without any further agreement or license. With the scheme above no software need be distributed that contains any information useful for anything other than a replay attack. The blob would be signed prior to distribution. You could read the code that loads it into the flash, but that need not be kept secret. You can load whatever you want into the flash and it won't matter unless it is signed. If the hardware is fancy enough you could even update settings without having to reboot, and again unless the hardware isn't done right you're not going to be able to get around it without tapping busses/etc. Rich
[gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Thomas Sachau posted on Sun, 17 Jun 2012 14:02:26 +0200 as excerpted: > I suggest you look for a better client to handle the line wrapping > better. ;-) In the meantime, the same file attached with wrapped lines. Thanks. (And I'm actually involved upstream tho not as a coder, so maybe...) -- 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: UEFI secure boot and Gentoo
Am 17.06.2012 19:10, schrieb Michał Górny: > On Sun, 17 Jun 2012 12:56:34 -0400 > Matthew Finkel wrote: > >> On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny >> wrote: >>> 1. How does it increase security? >>> >> This removed a few vectors of attack and ensures your computer is only >> bootstrapped by and booted using software you think is safe. By using >> any software we don't write, we make a lot of assumptions. > > I agree that it removes a few vectors of attack. But this doesn't > necessarily mean the system is more secure. It has one vulnerability > less but let's not get overenthusiastic. > > I'm basically trying to point out that a single solution like that can > do more evil than good if people will believe it's perfect. > I think I now understand your train of thought. But I don't think anyone implied that Secure Boot solves each and every security issue. What it does, however, is impose new hurdles for malware authors. Therefore I don't see a reason not to use it as long as the inconveniences and limitations it imposes are acceptable for my particular use case. >>> 3. What happens if the machine signing the blobs is compromised? >>> >> See above. But also, a compromised system wouldn't necessarily mean >> the blobs would be compromised as well. In addition, ideally the >> priv-key would be kept isolated to ensure a compromise would be >> extremely difficult. > > In my opinion, if a toolchain is quietly compromised, everything built > on the particular machine can be compromised. And signed. I doubt that > someone will check bit-exact machine code of the toolchain > and operating system before starting to sign packages. > Just because you cannot rule out bugs doesn't mean you shouldn't use security enhancing systems. Don't tell me you open telnet for root access to your machines just because you cannot rule out the chance that SSH is compromised or someone compromised the SSH source code you downloaded from the Gentoo mirrors. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
[...] > It doesn't. It's just a very long wooden fence; you just didn't find > the hole yet. Given the fact that the keys in the BIOS must somehow get there and it must also be able to update them (how to revoke or add keys else?). Unless this is completely done in hardware, there must be a software doing it. Software can - by design - be reverse engineered; in some countries even legally without any further agreement or license. So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on this blob of software - at some point it must be readable from the processor, so you have to provide the mechanisms to verify signs, undo encryption etc somewhere (either in hardware or another software). Even if you somehow manage to embed all of this in the hardware stack, it would still require some kind of interface to get updated / revoked keys to operate on. It's not a matter of *if this can* be broken by someone who cares, it's a matter of *how long does it take* for someone who cares to break it. In the end, this is just another kind of "seems to be secure for a day or two". Admittedly a complex one - but there will always be a "kid in a garage" that is able to set everyone else out of business. SaCu
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 19:06, schrieb Michał Górny: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > >> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: [...] > >>> 3. What happens if the machine signing the blobs is compromised? >> >> So, who's watching the watchers, right? Come on, this is getting >> looney. > > I'm just pointing out that this simply relies on trusting people. Much > like not having those signatures. > If you are so much worried about it, UEFI allows you to remove all keys and just add your own. That way, only code signed by you will be executed. And in the standard case, well, it is just as good (or bad) as the SSL certificate business. It's not a perfect system but it is better than having everyone using self-signed certificates or none at all. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Greg KH wrote: > On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote: >> Just picking a random response to reply to. I'm not speaking >> officially, however, I'm pretty sure we at Genesi aren't going to pay >> Microsoft in order to boot our own boards. > If you don't want your boards to be Windows 8 certified, then you are > fine. Otherwise, you have to follow their guidelines, which I don't > think requires paying them any money if you want to run Windows 8. > > Also, as these are "your own boards", you control the BIOS, so you don't > even have to implement UEFI, or, if you do, you can control what keys > are installed in the BIOS by default. > > So I don't understand the issue here, please explain. > > greg k-h > > . > I'm glad you said that. If I was going to have to pay M$ to run Linux, I was thinking of shooting them with laser eyes or something. I have no plans to ever support M$ in any shape, form or fashion. Period. Thing is, they will likely try to make it so you can't disable it eventually. Some politician will try to make it a law if nothing else. After all, politicians are clueless anyway. Reminds me of chickens and it raining. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 1:06 PM, Michał Górny wrote: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > >> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: >> > 2. What happens if, say, your bootloader is compromised? >> >> And how would this happen? Your bootloader would not run. > > Yes. I'm asking what happens next. Is there an easy way to replace it? > Or is your computer bricked until you run some other bootloader to > replace the compromised one? My understanding is that there are a few options here. One is to simply re-image the system, either directly (as any vendor does), or after booting off of removable media. I'd have to re-read the spec but some of those might not require signatures, and in any case ones with valid signatures should be available. You can of course disable secure boot or go into custom mode as well which lets you do whatever you want until you have the system back in a bootable state. If you're running Windows 8 I believe they plan to have a recovery partition as well, which will be signed and bootable and which is designed to recover the OS. Rich
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 12:56:34 -0400 Matthew Finkel wrote: > On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny > wrote: > > 1. How does it increase security? > > > This removed a few vectors of attack and ensures your computer is only > bootstrapped by and booted using software you think is safe. By using > any software we don't write, we make a lot of assumptions. I agree that it removes a few vectors of attack. But this doesn't necessarily mean the system is more secure. It has one vulnerability less but let's not get overenthusiastic. I'm basically trying to point out that a single solution like that can do more evil than good if people will believe it's perfect. > > 3. What happens if the machine signing the blobs is compromised? > > > See above. But also, a compromised system wouldn't necessarily mean > the blobs would be compromised as well. In addition, ideally the > priv-key would be kept isolated to ensure a compromise would be > extremely difficult. In my opinion, if a toolchain is quietly compromised, everything built on the particular machine can be compromised. And signed. I doubt that someone will check bit-exact machine code of the toolchain and operating system before starting to sign packages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 09:55:35 -0700 Greg KH wrote: > On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > > 2. What happens if, say, your bootloader is compromised? > > And how would this happen? Your bootloader would not run. Yes. I'm asking what happens next. Is there an easy way to replace it? Or is your computer bricked until you run some other bootloader to replace the compromised one? > > 3. What happens if the machine signing the blobs is compromised? > > So, who's watching the watchers, right? Come on, this is getting > looney. I'm just pointing out that this simply relies on trusting people. Much like not having those signatures. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Sat, Jun 16, 2012 at 12:22:24PM +0300, Maxim Kammerer wrote: > On Fri, Jun 15, 2012 at 3:01 PM, Rich Freeman wrote: > > I think that anybody that really cares about security should be > > running in custom mode anyway, and should just re-sign anything they > > want to run. Custom mode lets you clear every single key in the > > system from the vendor on down, and gives you the ability to ensure > > the system only boots stuff you want it to. > > I have several questions, that hopefully someone familiar with UEFI > Secure Boot is able to answer. If I understand UEFI correctly, the > user will need to not just re-sign bootloaders, but also the > OS-neutral drivers (e.g., UEFI GOP), which are hardware-specific, and > will be probably signed with Microsoft keys, since the hardware vendor > would otherwise need to implement expensive key security measures — is > that correct? Huh? No, why would a user need to resign the UEFI drivers? Those "live" in the BIOS and are only used to get the machine up and running in UEFI space, before UEFI hands the control off to the bootloader it has verified is signed with a correct key. > If the user does not perform this procedure (due to its > complexity and/or lack of tools automating the process), is it > possible for an externally connected device to compromise the system > by supplying a Microsoft-signed blob directly to the UEFI firmware, > circumventing the (Linux) OS? Again, what? Please explain. > Is it possible to develop an automatic > re-signing tool — i.e., does the API support all needed features > (listing / extracting drivers, revoking keys, adding keys, etc.)? What API? The signing tool is public, and no, it doesn't add keys, that's up to the BIOS to do, not the userspace tool. confused, greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote: > Just picking a random response to reply to. I'm not speaking > officially, however, I'm pretty sure we at Genesi aren't going to pay > Microsoft in order to boot our own boards. If you don't want your boards to be Windows 8 certified, then you are fine. Otherwise, you have to follow their guidelines, which I don't think requires paying them any money if you want to run Windows 8. Also, as these are "your own boards", you control the BIOS, so you don't even have to implement UEFI, or, if you do, you can control what keys are installed in the BIOS by default. So I don't understand the issue here, please explain. greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny wrote: > On Sun, 17 Jun 2012 11:20:38 +0200 > Florian Philipp wrote: > > > Am 16.06.2012 19:51, schrieb Michał Górny: > > > On Fri, 15 Jun 2012 09:54:12 +0200 > > > Florian Philipp wrote: > > > > > >> Am 15.06.2012 06:50, schrieb Duncan: > > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > >>> > > So, anyone been thinking about this? I have, and it's not > > pretty. > > > > Should I worry about this and how it affects Gentoo, or not worry > > about Gentoo right now and just focus on the other issues? > > > > Minor details like, "do we have a 'company' that can pay > > Microsoft to sign our bootloader?" is one aspect from the > > non-technical side that I've been wondering about. > > >>> > > >>> I've been following developments and wondering a bit about this > > >>> myself. > > >>> > > >>> I had concluded that at least for x86/amd64, where MS is mandating > > >>> a user controlled disable-signed-checking option, gentoo shouldn't > > >>> have a problem. Other than updating the handbook to accommodate > > >>> UEFI, presumably along with the grub2 stabilization, I believe > > >>> we're fine as if a user can't figure out how to disable that > > >>> option on their (x86/amd64) platform, they're hardly likely to be > > >>> a good match for gentoo in any case. > > >>> > > >> > > >> As a user, I'd still like to have the chance of using Secure Boot > > >> with Gentoo since it _really_ increases security. Even if it means > > >> I can no longer build my own kernel. > > > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > > the hole yet. > > > > > > > Oh come on! That's FUD and you know it. If not, did you even look at > > the specs and working principle? > > Could you answer the following question: > (Sorry to jump in on this Florian) The real problem that surrounds this idea of security is that we need to make _a lot_ of assumptions about the code/programs we run. We _trust_ that the code we compile is as secure as possible and does not implement any "backdoors". If this is the case, then > 1. How does it increase security? > This removed a few vectors of attack and ensures your computer is only bootstrapped by and booted using software you think is safe. By using any software we don't write, we make a lot of assumptions. 2. What happens if, say, your bootloader is compromised? > Same thing that would happen if the bootloader was compromised today. We currently rely on trusting the maintainer, code review, community review, etc. Perhaps these efforts will need to be doubled now that any weak-link could compromise the system. > 3. What happens if the machine signing the blobs is compromised? > See above. But also, a compromised system wouldn't necessarily mean the blobs would be compromised as well. In addition, ideally the priv-key would be kept isolated to ensure a compromise would be extremely difficult. My understanding is that it's not the case that UEFI will lock down a system to prevent a compromise from occurring, it's the fact that it reduces the areas of attack and/or makes the attacks extremely difficult to accomplish. This just adds more protection in hardware for kernel-space that SELinux, apparmor, etc provide for userspace. - Matt
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > On Sun, 17 Jun 2012 11:20:38 +0200 > Florian Philipp wrote: > > > Am 16.06.2012 19:51, schrieb Michał Górny: > > > On Fri, 15 Jun 2012 09:54:12 +0200 > > > Florian Philipp wrote: > > > > > >> Am 15.06.2012 06:50, schrieb Duncan: > > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > >>> > > So, anyone been thinking about this? I have, and it's not > > pretty. > > > > Should I worry about this and how it affects Gentoo, or not worry > > about Gentoo right now and just focus on the other issues? > > > > Minor details like, "do we have a 'company' that can pay > > Microsoft to sign our bootloader?" is one aspect from the > > non-technical side that I've been wondering about. > > >>> > > >>> I've been following developments and wondering a bit about this > > >>> myself. > > >>> > > >>> I had concluded that at least for x86/amd64, where MS is mandating > > >>> a user controlled disable-signed-checking option, gentoo shouldn't > > >>> have a problem. Other than updating the handbook to accommodate > > >>> UEFI, presumably along with the grub2 stabilization, I believe > > >>> we're fine as if a user can't figure out how to disable that > > >>> option on their (x86/amd64) platform, they're hardly likely to be > > >>> a good match for gentoo in any case. > > >>> > > >> > > >> As a user, I'd still like to have the chance of using Secure Boot > > >> with Gentoo since it _really_ increases security. Even if it means > > >> I can no longer build my own kernel. > > > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > > the hole yet. > > > > > > > Oh come on! That's FUD and you know it. If not, did you even look at > > the specs and working principle? > > Could you answer the following question: > > 1. How does it increase security? Non-signed bootloaders and kernels will not run. > 2. What happens if, say, your bootloader is compromised? And how would this happen? Your bootloader would not run. > 3. What happens if the machine signing the blobs is compromised? So, who's watching the watchers, right? Come on, this is getting looney. greg k-h
Re: [gentoo-dev] [RFC] Dynamic SLOTs
Michał Górny schrieb: > On Sun, 17 Jun 2012 17:46:00 +0200 > Thomas Sachau wrote: > Beside that, it seems to solve things pretty similar to the proposed way in multilib-portage for cross-compiling (which could also be adapted for multi-slot languages) with different wording and with additional work for ebuild maintainers. And since my proposal already uses USE flags, things would not change visually for users of e.g. ruby or php. >>> >>> I'm sad you aren't even trying to listen. Your attempt implies that >>> every single change in targets requires rebuilding all of them. If I >>> weren't using 32-bit libs, and now I want to compile 32-bit wine, I >>> have to recompile most of my libraries for both ABIs. That is >>> a no go for me. >> >> So you want to build a 32bit package, which is depending on 32bit >> libs, but want to do that without the needed dependencies? Please >> tell me, how that works. > > I'm trying to build a 32bit package and its 32bit dependencies. Your > solution involves building a 32bit package and rebuilding all 64bit > packages which happen to be its dependencies for no reason. You should already know, that "for no reason" is plain wrong. Beside the point, that you can build just the 32bit libs, if you dont want 64bit ones. And you did not answer my questions when i asked you about maintainence of your suggestion back then to keep every target as a seperate package (which itself has its own disadvantages like common files and UI questions). Either way, my working solution might have some overhead, but is easy to control and maintain for both devs and users. If you get to the point, that you can show me your suggestion working with the main tree, it might be much more clear, what you actually want to do and how you want to implement it. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Michał Górny :
> On Sun, 17 Jun 2012 19:03:22 +0400
> Maxim Koltsov wrote:
>
>> 2012/6/17 Justin :
>> > On 17.06.2012 15:23, Maxim Koltsov wrote:
>> >> 2012/6/17 Justin :
>> >>> On 17.06.2012 14:13, Maxim Koltsov wrote:
>> Hi,
>> During prefix bootstrap i noticed that strip-flags removes -L
>> and -I flags from *FLAGS while these flags are essential for
>> prefix bootstrapping. Therefore i propose a fix for strip-flags
>> function to
>> >>>
>> >>> Is this really necessary? I never experienced any problems which
>> >>> need this when following the guides. I looks like a hack, because
>> >>> something else is borked.
>> >>
>> >> I've just hit binutils on OpenBSD not finding libdl.so installed in
>> >> $EPREFIX/usr/lib/ because of this.
>> >> Don't tell me that OpenBSD prefix is unsupported, i'm working on
>> >> getting it supported.
>> >>
>> >
>> > I am still not convinced. libdl.so is provided by glibc, at least
>> > on my linux system. And glibc is one of the rare packages which
>> > needs to be provided by the host system instead of being installed
>> > in the prefix.
>> >
>> > Is there something different on BSD which makes libdl.so appear
>> > inside the prefix?
>>
>> At least on OpenBSD dlopen() is not in libdl.so, but in ld.so itself,
>> so I have to install dummy libdl.so to ${EPREFIX}/usr/lib.
>> I think we should use Fabian's solution from the bug, if it does not
>> cause any unwanted consequences.
>
> Shouldn't configure detect that no libdl is necessary?
Should, but eclass does the bad thing anyway.
>
> --
> Best regards,
> Michał Górny
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 17:46:00 +0200 Thomas Sachau wrote: > >> Beside that, it seems to solve things pretty similar to the > >> proposed way in multilib-portage for cross-compiling (which could > >> also be adapted for multi-slot languages) with different wording > >> and with additional work for ebuild maintainers. And since my > >> proposal already uses USE flags, things would not change visually > >> for users of e.g. ruby or php. > > > > I'm sad you aren't even trying to listen. Your attempt implies that > > every single change in targets requires rebuilding all of them. If I > > weren't using 32-bit libs, and now I want to compile 32-bit wine, I > > have to recompile most of my libraries for both ABIs. That is > > a no go for me. > > So you want to build a 32bit package, which is depending on 32bit > libs, but want to do that without the needed dependencies? Please > tell me, how that works. I'm trying to build a 32bit package and its 32bit dependencies. Your solution involves building a 32bit package and rebuilding all 64bit packages which happen to be its dependencies for no reason. > > And adjusting that for other multi-slot languages is pointless. > > Because they do the same already. > > So you dont like one framework for all multi-slot languages and prefer > having each one using their own solution? Or do you just dislike my > idea for them and want to use your own suggestion for them? I'm just saying that your framework doesn't change anything for user; it just involves some work to change the label. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 11:20:38 +0200 Florian Philipp wrote: > Am 16.06.2012 19:51, schrieb Michał Górny: > > On Fri, 15 Jun 2012 09:54:12 +0200 > > Florian Philipp wrote: > > > >> Am 15.06.2012 06:50, schrieb Duncan: > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > >>> > So, anyone been thinking about this? I have, and it's not > pretty. > > Should I worry about this and how it affects Gentoo, or not worry > about Gentoo right now and just focus on the other issues? > > Minor details like, "do we have a 'company' that can pay > Microsoft to sign our bootloader?" is one aspect from the > non-technical side that I've been wondering about. > >>> > >>> I've been following developments and wondering a bit about this > >>> myself. > >>> > >>> I had concluded that at least for x86/amd64, where MS is mandating > >>> a user controlled disable-signed-checking option, gentoo shouldn't > >>> have a problem. Other than updating the handbook to accommodate > >>> UEFI, presumably along with the grub2 stabilization, I believe > >>> we're fine as if a user can't figure out how to disable that > >>> option on their (x86/amd64) platform, they're hardly likely to be > >>> a good match for gentoo in any case. > >>> > >> > >> As a user, I'd still like to have the chance of using Secure Boot > >> with Gentoo since it _really_ increases security. Even if it means > >> I can no longer build my own kernel. > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > the hole yet. > > > > Oh come on! That's FUD and you know it. If not, did you even look at > the specs and working principle? Could you answer the following question: 1. How does it increase security? 2. What happens if, say, your bootloader is compromised? 3. What happens if the machine signing the blobs is compromised? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
On Sun, 17 Jun 2012 19:03:22 +0400
Maxim Koltsov wrote:
> 2012/6/17 Justin :
> > On 17.06.2012 15:23, Maxim Koltsov wrote:
> >> 2012/6/17 Justin :
> >>> On 17.06.2012 14:13, Maxim Koltsov wrote:
> Hi,
> During prefix bootstrap i noticed that strip-flags removes -L
> and -I flags from *FLAGS while these flags are essential for
> prefix bootstrapping. Therefore i propose a fix for strip-flags
> function to
> >>>
> >>> Is this really necessary? I never experienced any problems which
> >>> need this when following the guides. I looks like a hack, because
> >>> something else is borked.
> >>
> >> I've just hit binutils on OpenBSD not finding libdl.so installed in
> >> $EPREFIX/usr/lib/ because of this.
> >> Don't tell me that OpenBSD prefix is unsupported, i'm working on
> >> getting it supported.
> >>
> >
> > I am still not convinced. libdl.so is provided by glibc, at least
> > on my linux system. And glibc is one of the rare packages which
> > needs to be provided by the host system instead of being installed
> > in the prefix.
> >
> > Is there something different on BSD which makes libdl.so appear
> > inside the prefix?
>
> At least on OpenBSD dlopen() is not in libdl.so, but in ld.so itself,
> so I have to install dummy libdl.so to ${EPREFIX}/usr/lib.
> I think we should use Fabian's solution from the bug, if it does not
> cause any unwanted consequences.
Shouldn't configure detect that no libdl is necessary?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
Michał Górny schrieb: > On Sun, 17 Jun 2012 14:09:14 +0200 > Thomas Sachau wrote: > >> Michał Górny schrieb: >>> Hello, >>> >>> I have prepared a first draft of 'dynamic SLOT' specification. This >>> is my proposal in attempt to solve the problem of building packages >>> for multiple Python and Ruby versions. It could also be reused for >>> multilib. >>> >>> The spec tries to explain the broad idea, and all problems relevant >>> to it. It also lists a few problems which are still unsolved and I >>> think they will cause the spec to change after hearing your ideas. >>> >>> To be honest, I tried to keep it as simple as possible. Please don't >>> say it doesn't solve all the world problems because it simply won't. >>> >>> I'm attaching a reStructuredText version of the spec. You can view >>> it rendered as a gist[1]. But please keep the replies on the list, >>> rather than forking the gist. >>> >>> [1]:https://gist.github.com/2943774 >>> >> >> Since you have not responded to my lines in IRC, i will repeat them >> here: >> >> First: How does the user see, which slots are possible and which ones >> are currently active and which are currently not selected? > > Implementation is left to be package-manager specific. I guess colorful > output (similar to USE flags) would be enough. So you dont like my solution with USE flags and then suggest some USE flag like output for your own solution? If you want to use something USE flag like, then simply use USE flags, they already exist. ;-) > >> Beside that, it seems to solve things pretty similar to the proposed >> way in multilib-portage for cross-compiling (which could also be >> adapted for multi-slot languages) with different wording and with >> additional work for ebuild maintainers. And since my proposal already >> uses USE flags, things would not change visually for users of e.g. >> ruby or php. > > I'm sad you aren't even trying to listen. Your attempt implies that > every single change in targets requires rebuilding all of them. If I > weren't using 32-bit libs, and now I want to compile 32-bit wine, I > have to recompile most of my libraries for both ABIs. That is > a no go for me. So you want to build a 32bit package, which is depending on 32bit libs, but want to do that without the needed dependencies? Please tell me, how that works. > > And adjusting that for other multi-slot languages is pointless. Because > they do the same already. > So you dont like one framework for all multi-slot languages and prefer having each one using their own solution? Or do you just dislike my idea for them and want to use your own suggestion for them? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 12:51:50 +0200 Marien Zwart wrote: > A common operation in an ebuild will be (say) "get the selected > version of python". That's easy enough if there's only one kind of > dynamic slot being used by the ebuild (just use CURRENT_SLOTS > directly), but if the ebuild supports more than one kind of dynamic > slot you need a helper function that picks the selected value of that > one kind of slot out of CURRENT_SLOTS, either relying on the naming > scheme or on a list of supported values of that kind of slot > hardcoded in the helper function (in an eclass). That seems a little > fragile. Your "dynamic slot groups" idea could help with this, by > having that list sit in a more sensible place than in an eclass, and > perhaps by having the package mangler provide a variable per slot > group (a little like how USE_EXPAND works). Yes, you are right. > I really dislike the implicit dependencies. First of all: it is > entirely possible for ebuild A supporting dynamic slots for (say) > python to have a build-time dependency on ebuild B that supports > dynamic slots (also for python), but only to get at a utility to run, > not to use B as a library. In that case we don't want to force slots > to match, and (as you point out) that may not even be possible if the > two packages don't support the same slots. Hmm, that is true. However, it all depends on how the utility would be called. As I see it, there are two possibilities here: a) utility is called using the currently selected Python version, b) utility is called using currently built Python version. In case (b) the complete dependency graph for that version of Python is probably required anyway. In case (a) indeed that may even cause the necessary version of the utility to be missing. First thought on handling this is to invent additional dependency symbol which would disable dynamic SLOTs for that particular dependency (opt-out seems to be simpler to handle globally than opt-in). > Also, it just breaks down > completely if you don't use your "slot groups" idea: if A has > DYNAMIC_SLOTS="|| ( py2.6 py2.7 )" and B has DYNAMIC_SLOTS="|| > ( ruby1.8 ruby1.9 )" it makes no sense to require the dynamic slot > setting to match, but if A has DYNAMIC_SLOTS="|| ( py2.5 py2.6 )" and > B has "|| ( py2.7 py3.2 )" then we do need them to match, and the > user has requested an impossible situation (he needs to use versions > of A and B that have at least one supported python version in > common). Without "slot groups" the package manager cannot tell these > two cases apart. > > I think it'd make more sense to have those slot groups, per-slot group > variables like DYNAMIC_SLOTS_PYTHON="py2.7 py3.2" resulting in > CURRENT_SLOT_PYTHON getting set, and an addition to the dependency > syntax that lets you depend on a matching named dynamic slot. That > makes your DYNAMIC_SLOTS="|| ( py2.6 py2.7 ruby1.8 ruby1.9 )" example > impossible, but I think it'd be uncommon for that approach to make > sense: I think it'd usually make more sense to split that into two > packages, one per language. Agreed. The next version of the spec (if the goal seemed still possible to achieve) will certainly have those. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 11:43:30 +0200 Hans de Graaff wrote: > On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote: > > > I'm attaching a reStructuredText version of the spec. You can view > > it rendered as a gist[1]. But please keep the replies on the list, > > rather than forking the gist. > > I don't like the approach taken in 6. I'd rather state that there > should not be file collisions between the dynamic slots. We already > handle things this way in ruby (with a common 'all' and specific > version builds). That is impossible for most of the build systems. If Ruby has a nice ability to split between building common and ABI-specific stuff, that's great. But Python doesn't have one. Bindings built using other languages don't have that either. The usual way of handling that is through letting all the ABIs install to the same image, and then installing whatever got merged as a result. The spec practically suggests the same yet split in time. Shortly saying, we can't do that or we will be stuck installing everything by hand, which will practically make this idea useless. > For 9c I can't see us limiting users to a single ruby implementation > by default (the only current exception is www-apache/passenger), so a > combined ||() block makes no sense to me. I think it is better to be > explicit here and express the real situation with multiple ||() blocks > if needed. I think you misunderstand the concept of combined block. It was mostly supposed to be useful when a single package provides bindings for multiple languages, so that a single build would involve building bindings for one ABI of one language. Multiple blocks would involve building bindings for both one Python ABI and one Ruby ABI at a time which means scary results. That probably even won't work, so splitting it is the only alternative to one big block. > Finally, I don't expect ruby to use this unless we can ensure that > this works with our current ebuilds without changes. I'm fine with > supporting some code in the eclass to determine which mechanism to > use in which way, but we won't be spending huge amounts of time > switching to yet another system. To me the perceived benefits aren't > big enough. I'm trying hard to make this as painless as possible but I can't guarantee single ebuilds (uncommon cases) wouldn't need changes. However, I'm trying hard to ensure that majority would be clearly handled by eclasses. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 14:09:14 +0200 Thomas Sachau wrote: > Michał Górny schrieb: > > Hello, > > > > I have prepared a first draft of 'dynamic SLOT' specification. This > > is my proposal in attempt to solve the problem of building packages > > for multiple Python and Ruby versions. It could also be reused for > > multilib. > > > > The spec tries to explain the broad idea, and all problems relevant > > to it. It also lists a few problems which are still unsolved and I > > think they will cause the spec to change after hearing your ideas. > > > > To be honest, I tried to keep it as simple as possible. Please don't > > say it doesn't solve all the world problems because it simply won't. > > > > I'm attaching a reStructuredText version of the spec. You can view > > it rendered as a gist[1]. But please keep the replies on the list, > > rather than forking the gist. > > > > [1]:https://gist.github.com/2943774 > > > > Since you have not responded to my lines in IRC, i will repeat them > here: > > First: How does the user see, which slots are possible and which ones > are currently active and which are currently not selected? Implementation is left to be package-manager specific. I guess colorful output (similar to USE flags) would be enough. > Beside that, it seems to solve things pretty similar to the proposed > way in multilib-portage for cross-compiling (which could also be > adapted for multi-slot languages) with different wording and with > additional work for ebuild maintainers. And since my proposal already > uses USE flags, things would not change visually for users of e.g. > ruby or php. I'm sad you aren't even trying to listen. Your attempt implies that every single change in targets requires rebuilding all of them. If I weren't using 32-bit libs, and now I want to compile 32-bit wine, I have to recompile most of my libraries for both ABIs. That is a no go for me. And adjusting that for other multi-slot languages is pointless. Because they do the same already. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Justin :
> On 17.06.2012 15:23, Maxim Koltsov wrote:
>> 2012/6/17 Justin :
>>> On 17.06.2012 14:13, Maxim Koltsov wrote:
Hi,
During prefix bootstrap i noticed that strip-flags removes -L and -I
flags from *FLAGS while these flags are essential for prefix
bootstrapping. Therefore i propose a fix for strip-flags function to
>>>
>>> Is this really necessary? I never experienced any problems which need
>>> this when following the guides. I looks like a hack, because something
>>> else is borked.
>>
>> I've just hit binutils on OpenBSD not finding libdl.so installed in
>> $EPREFIX/usr/lib/ because of this.
>> Don't tell me that OpenBSD prefix is unsupported, i'm working on
>> getting it supported.
>>
>
> I am still not convinced. libdl.so is provided by glibc, at least on my
> linux system. And glibc is one of the rare packages which needs to be
> provided by the host system instead of being installed in the prefix.
>
> Is there something different on BSD which makes libdl.so appear inside
> the prefix?
At least on OpenBSD dlopen() is not in libdl.so, but in ld.so itself,
so I have to install dummy libdl.so to ${EPREFIX}/usr/lib.
I think we should use Fabian's solution from the bug, if it does not
cause any unwanted consequences.
[gentoo-dev] Re: [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17-06-2012 16:13:33 +0400, Maxim Koltsov wrote:
> Hi,
> During prefix bootstrap i noticed that strip-flags removes -L and -I
> flags from *FLAGS while these flags are essential for prefix
> bootstrapping. Therefore i propose a fix for strip-flags function to
> make it preserve prefix-related flags. I have attached a patch, please
> review it. It works for me, but I'm unsure how it will work with
> spaces in ${EPREFIX}
https://bugs.gentoo.org/show_bug.cgi?id=414641
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17.06.2012 15:23, Maxim Koltsov wrote: > 2012/6/17 Justin : >> On 17.06.2012 14:13, Maxim Koltsov wrote: >>> Hi, >>> During prefix bootstrap i noticed that strip-flags removes -L and -I >>> flags from *FLAGS while these flags are essential for prefix >>> bootstrapping. Therefore i propose a fix for strip-flags function to >> >> Is this really necessary? I never experienced any problems which need >> this when following the guides. I looks like a hack, because something >> else is borked. > > I've just hit binutils on OpenBSD not finding libdl.so installed in > $EPREFIX/usr/lib/ because of this. > Don't tell me that OpenBSD prefix is unsupported, i'm working on > getting it supported. > I am still not convinced. libdl.so is provided by glibc, at least on my linux system. And glibc is one of the rare packages which needs to be provided by the host system instead of being installed in the prefix. Is there something different on BSD which makes libdl.so appear inside the prefix? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Richard Yao : > On 06/17/2012 09:23 AM, Maxim Koltsov wrote: >> Don't tell me that OpenBSD prefix is unsupported, i'm working on >> getting it supported. > > OpenBSD is listed on the platform matrix, but it has lacked a maintainer > for quite some time: > > http://www.gentoo.org/proj/en/gentoo-alt/prefix/ > > I am happy to see that you are working on this. If you have questions > about prefix, feel free to ping me in IRC. :) Gentoo/OpenBSD was listed in my gentooRoles since the beginning, but i had no time for it until this summer :) Thank's for you offer, i will ping you if needed.
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 09:26:55 +0200 Michał Górny wrote: > I have prepared a first draft of 'dynamic SLOT' specification. This is > my proposal in attempt to solve the problem of building packages for > multiple Python and Ruby versions. It could also be reused for > multilib. I'm pretty sure we can't go anywhere with this until all the things that manually access VDB are gone. Can you work on that first? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
2012/6/17 Justin :
> On 17.06.2012 14:13, Maxim Koltsov wrote:
>> Hi,
>> During prefix bootstrap i noticed that strip-flags removes -L and -I
>> flags from *FLAGS while these flags are essential for prefix
>> bootstrapping. Therefore i propose a fix for strip-flags function to
>
> Is this really necessary? I never experienced any problems which need
> this when following the guides. I looks like a hack, because something
> else is borked.
I've just hit binutils on OpenBSD not finding libdl.so installed in
$EPREFIX/usr/lib/ because of this.
Don't tell me that OpenBSD prefix is unsupported, i'm working on
getting it supported.
>> make it preserve prefix-related flags. I have attached a patch, please
>> review it. It works for me, but I'm unsure how it will work with
>> spaces in ${EPREFIX}
>
> Why not use "use prefix" instead of checking for the variable?
>
>
I didn't know about prefix use flag. I attach the fixed patch.
flag-o-matic.patch
Description: Binary data
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17.06.2012 14:13, Maxim Koltsov wrote:
> Hi,
> During prefix bootstrap i noticed that strip-flags removes -L and -I
> flags from *FLAGS while these flags are essential for prefix
> bootstrapping. Therefore i propose a fix for strip-flags function to
Is this really necessary? I never experienced any problems which need
this when following the guides. I looks like a hack, because something
else is borked.
> make it preserve prefix-related flags. I have attached a patch, please
> review it. It works for me, but I'm unsure how it will work with
> spaces in ${EPREFIX}
Why not use "use prefix" instead of checking for the variable?
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-perl/Tie-RegexpHash, net-proxy/vulture
The following packages will be removed from the tree: # Mask for removal (#421461) # Test suite fails since perl 5.13.6 dev-perl/Tie-RegexpHash # Mask for removal (#310711) # vulture is the only consumer of =dev-perl/DBD-SQLite-0.31* net-proxy/vulture
[gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
Hi,
During prefix bootstrap i noticed that strip-flags removes -L and -I
flags from *FLAGS while these flags are essential for prefix
bootstrapping. Therefore i propose a fix for strip-flags function to
make it preserve prefix-related flags. I have attached a patch, please
review it. It works for me, but I'm unsure how it will work with
spaces in ${EPREFIX}
Thanks,
Maxim.
flag-o-matic.patch
Description: Binary data
Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 17 Jun 2012 03:35:08 +0200 hasufell wrote: > On 06/16/2012 08:14 PM, Ciaran McCreesh wrote: > > Suggested dependencies were used in the old kdebuilds, and Exherbo > > makes extensive use of both suggested and recommended dependencies, > > so there are plenty of examples, spec wording and an implementation > > already if you want to play. > > I don't want to install Exherbo to see an example. Archlinux also has > a nice implementation about optional dependencies and I don't care > about that either. > > This is about a gentoo specific implementation and I am still not > clear about how that proposed SDEPEND would look like. > Are useflags allowed for those too? How do I "activate" it? Via a > seperate config file in /etc/portage, is it a FEATURE? what what what Surely being able to use it and play around with it for real is better than seeing some not very helpful textual examples pasted in... Anyway, you can probably find the old kdebuilds somewhere, those run on Gentoo. For that matter, the Paludis ebuild in the overlay makes use of suggestions, although it's only for one small set of things. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/dyD0ACgkQ96zL6DUtXhFrUgCgkxzRAgqaDf6Al1/Zp9n7wRJL pRYAoOBw7143Mch81VvBVsK3Us0FilRM =JGNo -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Dynamic SLOTs
Michał Górny schrieb: > Hello, > > I have prepared a first draft of 'dynamic SLOT' specification. This is > my proposal in attempt to solve the problem of building packages for > multiple Python and Ruby versions. It could also be reused for multilib. > > The spec tries to explain the broad idea, and all problems relevant to > it. It also lists a few problems which are still unsolved and I think > they will cause the spec to change after hearing your ideas. > > To be honest, I tried to keep it as simple as possible. Please don't > say it doesn't solve all the world problems because it simply won't. > > I'm attaching a reStructuredText version of the spec. You can view it > rendered as a gist[1]. But please keep the replies on the list, rather > than forking the gist. > > [1]:https://gist.github.com/2943774 > Since you have not responded to my lines in IRC, i will repeat them here: First: How does the user see, which slots are possible and which ones are currently active and which are currently not selected? Beside that, it seems to solve things pretty similar to the proposed way in multilib-portage for cross-compiling (which could also be adapted for multi-slot languages) with different wording and with additional work for ebuild maintainers. And since my proposal already uses USE flags, things would not change visually for users of e.g. ruby or php. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
El sáb, 16-06-2012 a las 22:10 +0200, Peter Stuge escribió:
> Pacho Ramos wrote:
> > > I guess the point is that it is not really a dependency.
> >
> > No, it's a dependency only when you want ppp support working,
>
> Logically, but not technically.
>
> I like this separation; the package manager takes care of technical
> requirements, and I get to take care of the logical requirements.
>
>
> > > I dunno if a USE flag is much better? Both require the user to inform
> > > herself in the same way ("when do I need USE=ppp for bluez" vs. "when
> > > do I need to emerge ppp")
> >
> > It's much easier to widely set "ppp" USE in make.conf to be sure ppp
> > support works for all things in my system that needing to rebuild
> > affected package to see elog message telling me that I need to manually
> > emerge some other package
>
> My point is that when you know that you need ppp (and how could you
> set USE=ppp otherwise) then it is about equally easy to emerge ppp
> as it is to set USE=ppp.
But that point is valid with this exact example because, in this case,
it's really intuitive to do so, but in other cases in the tree, there is
not such good liaison between USE flag name and needed package ;)
>
>
> > > > people end up with a lot of packages they needed to manually
> > > > emerge some year but that they problem no longer need at all.
> > >
> > > Disk is pretty cheap. If the package is never being used and the user
> > > doesn't care to remove it then the package doesn't do any harm IMO,
> > > and as mentioned I think it's difficult for the package manager to
> > > know what the user has installed on the system but no longer needs..
> >
> > What kind of argument is "disk is pretty cheap".
>
> Please read the rest of what I wrote too. :)
>
>
> > I still administrate a laptop with a 250GB of disk space, and that
> > space cannot be as large if you have a lot of files at home.
>
> My primary system had 8GB storage until a few years ago when flash
> prices went down. I was motivated to keep my system clean. If one is
> space constrained then I think one naturally pays more attention to
> keeping world small. Disk is still cheap. If it is a problem for me
> that I have unneeded packages installed, *then* I will start looking
> at cleaning up. Until then, there's no problem.
>
>
> > Also, you are missing that having unneeded packages in world file
> > will also cause them to be updated on every system updated, with
> > the time it takes for compile.
>
> I'm not missing, but I'm saying that it is merely the effect of not
> managing world very actively.
>
> I think it's difficult to impossible for a package manager to
> reliably determine logical requirements from what is a model
> (USE flags) of technical requirements (link-time dependencies).
>
>
> //Peter
Well, looks like a solution for this is already implemented in exherbo
and there were also similar solutions proposed in the past, lets see if
we can agree on witch one would be better for us :)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Duncan schrieb:
> Thomas Sachau posted on Sat, 16 Jun 2012 12:31:40 +0200 as excerpted:
>
>> Since i am not that sure about my ability to write formal specs, i am
>> presenting my first draft for further review and suggestions for
>> improvement.
>
> Just a format suggestion. Call it nitpicky if you want, and yes, my
> client isn't perfect, but I'm sure people with a bit of experience
> writing such specs will tell you I'm not alone...
>
> Several of your points ended up as very long single lines. My client can
> wrap, but that wraps the points as well (so for example 2.1 starts in the
> middle of a line). So I was left with the choice to either massively
> horizontally scroll, or of trying to figure out where one point ended and
> another began, since wrapping it... /wrapped/ it, so points appeared in
> the middle of a line.
>
> Please:
>
> * If you use long lines, leave a vertical space (blank line) between
> points so when a client wraps them, they wrap as individual paragraphs.
>
> * Alternatively, wrap at something sensible. (The traditional wrap for
> posting is 72 chars or so, 80 minus a few to allow a few levels of
> quoting without rewrap. I wouldn't complain at 90, but if you're going
> to bother, you might as well go the standard route and avoid further
> issues.)
>
> Long lines as paragraphs would probably be easier especially early in the
> process when you're modifying a lot, but you still risk (even more)
> limited clients having issues with it. YMMV.
>
I suggest you look for a better client to handle the line wrapping
better. ;-) In the meantime, the same file attached with wrapped lines.
--
Thomas Sachau
Gentoo Linux Developer
For amd64 users, there is sometimes the issue, that they need 32bit libs for
certain packages (e.g. wine or many binary-only packages). Currently,
they only get them prepackaged in binary form with the emul-linux-x86-*
packages. But those packages have a few issues (list does not have to be
complete):
-they only contain a limited set of 32bit packages
-they are precompiled, so the user cannot define his own flags
-they have to be manually maintained and updated
So the idea was to add the ability to compile 32bit packages with support from
the package manager, so there is no need for additional packages to
maintain. After this was originally implemented, it was further extended
to allow cross-compilation for other targets, not only limited to 32bit
packages.
The basic way, how this should work:
1. Check for the current profile being multilib, this means, that the
MULTILIB_ABIS var exists and has more then 1 (space seperated) value.
Additionally, the DEFAULT_ABI var has to be defined and its content should
be part of the MULTILIB_ABIS var. Only continue with the following steps,
if this is true
2.1 Take the entries from MULTILIB_ABIS var and add a USE flag for each of them
in the form of multilib_abi_$value
2.2 Add "abiwrapper" as a USE flag
3. Check, if the package has USE=multilib enabled. Only continue with the
following steps, if this is false.
4. Add a use dependency for each USE flag added in step 2 for all dependencies
except those defined in a space seperated list of the NO_AUTO_FLAG var. The
dependency should then look like category/package[multilib_abi_$value?]
5. Find the first enabled USE flag from the list of step 2, start with
multilib_abi_$DEFAULT_ABI during the search. If none is enabled, use
multilib_abi_$DEFAULT_ABI. In the following, $ABI will reference the $value
part of the selected USE flag.
6. Before the pkg_setup phase is executed, setup the environment as following:
-export CHOST with $CHOST_$DEFAULT_ABI
-export $CC with $CHOST-gcc
-export $CXX with $CHOST-g++
-export $FC with $CHOST-gfortran
-export $CHOST with $CHOST_$ABI
-export $CBUILD with $CHOST_$ABI
-export $CDEFINE with $CDEFINE_$ABI
-export $CCASFLAGS with ${CCASFLAGS:-${CFLAGS}} and append $CFLAGS_$ABI
-export $CFLAGS with $CFLAGS and append $CFLAGS_$ABI
-export $CPPFLAGS with $CPPFLAGS and append $CPPFLAGS_$ABI
-export $CXXFLAGS with $CXXFLAGS and append $CFLAGS_$ABI
-export $FCFLAGS with $FCFLAGS and append $CFLAGS_$ABI
-export $FFLAGS with $FFLAGS and append $CFLAGS_$ABI
-export $ASFLAGS with $ASFLAGS and append $ASFLAGS_$ABI
-export $LDFLAGS with $LDFLAGS and append $CFLAGS_$ABI
-export $PKG_CONFIG_PATH with /usr/$LIBDIR_$ABI/pkgconfig
7. After src_install is finished:
7.1 Execute the following or equivalent code (prep_ml_binaries is a function
from multilib-portage from [1]):
prep_ml_binaries $(find "${D}"usr/bin "${D}"usr/sbin "${D}"bin "${D}"sbin -type
f -name '*-config' 2>/dev/null)
7.2 If USE flag abiwrapper is enabled, execute:
local noabi=()
for i in ${MULTILIB_ABIS}; do
noabi+=( ! -name '*-'${i} )
done
if use abiwrapper ; then
for i in $(find "${D}"usr/bin/ "${D}"usr/sbin "${D}"bin "${D}"sbi
Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
El sáb, 16-06-2012 a las 22:07 -0500, Dale escribió: > Duncan wrote: > > > > Looking at the broader picture, the problem of extraneous packages in the > > world file has always concerned me. If it were to be done over again, > > and I think Zac would likely agree, emerge would use --oneshot by > > default, so as not to contaminate the world file unnecessarily. Then > > there'd be a different option (say -2) to add the package to the world > > file if that's what was actually intended. > > > > That's actually how I have my emerge front-end scriptlets/aliases setup > > here. -1 is the default; if I want it in the world file I use the *2 > > script variant, which omits the -1. > > > > But of course changing behavior in mid-stream doesn't work so well, so > > emerge continues to stick stuff in the world file by default. > > > > I added -1 to my make.conf a long time ago. Whenever I emerge something > and want it in the world file, just use the --select option. If I > already emerged something but then want to add it to the world file, > just add the -n option too. That keeps the world file clean and I can > test things before adding anything to the world file. > > Dale > > :-) :-) > The problem is that this wouldn't solve the first issue because people would still need to emerge extra packages with "--select" option if they don't want to see them going away on next depclean round even if package that needed them is still installed signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
El sáb, 16-06-2012 a las 22:36 +0200, Michał Górny escribió: > On Sat, 16 Jun 2012 20:49:10 +0200 > Pacho Ramos wrote: > > > El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió: > > > On Sat, 16 Jun 2012 18:30:55 +0200 > > > Pacho Ramos wrote: > > > > > > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió: > > > > > It breaks the useflag philosophy, IMO. > > > > > > > > > > Useflags were meant as switches. You can turn things on and off. > > > > > Pulling in optional dependencies via useflags does not allow the > > > > > user to turn something off when he sets USE="-foo" emerge > > > > > fuqbar. That should only be valid for virtuals or > > > > > meta-packages. And that's what those are for. > > > > > > > > > > > > > Maybe we could split them from RDEPEND to some kind of > > > > EXTRA_DEPEND (or something else) to fit this purpose. > > > > > > There was already a lot of discussion about this and the community > > > didn't care enough to agree on one of the proposed solutions. You're > > > just reinventing one of them, with a new variable name and the same > > > disadvantages. > > > > > > > Do you have a link to that old thread? Because current situation of > > relying on elog messages also has disadvantages > > http://thread.gmane.org/gmane.linux.gentoo.devel/71794 Thanks :) From this one looks like: http://article.gmane.org/gmane.linux.gentoo.devel/71889 http://article.gmane.org/gmane.linux.gentoo.devel/71827 are interesting approaches. Personally, SDEPEND approach looks really interesting to me, maybe it's only problem would be how to explain that some extra packages are needed without requiring to elog, but looks like exherbo already implements a solution for this. Other think I would like to see in this approach is to add a way to *globally* configure PM to always accept or discard extra deps by default (even still being able to configure it per package as already suggested) > http://thread.gmane.org/gmane.linux.gentoo.devel/72162 > If it's too difficult to implement first EAPI solution ok, but I really would prefer the EAPI way instead of using eclass to show more postinst messages instead as I really prefer this to be handled in a more automatic/configurable way. Also, only packages currently needing to use elog messages for this kind of problem would need to be updated to latest EAPI. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
Hans de Graaff wrote: > > I think ABI fits well though? The situation is that A DEPENDs on B, > > and at some point B changes in a way that A must be rebuilt in order > > to run - right? > > At least for dev-ruby/nokogiri this is not the case. It checks the > version of libxml2 it was built against versus the one it finds at > runtime and starts to issue warnings if they don't match, but it will > still run. Why does nokogiri issue warnings about something that isn't actually a problem? > So it would be a good idea to automatically update nokogiri after > libxml2 to avoid cluttering logfiles and cron emails. But the ABI > didn't change. Or fix this behavior upstream, if there is no actual reason to require the built-against version. > dev-ruby/rmagick does something similar for imagemagick but > actually refuses to run, even if the ABI would stay the same. ruby y u so weird? //Peter pgpGpQNzTkz7w.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On zo, 2012-06-17 at 09:26 +0200, Michał Górny wrote: > I'm attaching a reStructuredText version of the spec. You can view it > rendered as a gist[1]. But please keep the replies on the list, rather > than forking the gist. I've only thought about this a little, but some thoughts so far: A common operation in an ebuild will be (say) "get the selected version of python". That's easy enough if there's only one kind of dynamic slot being used by the ebuild (just use CURRENT_SLOTS directly), but if the ebuild supports more than one kind of dynamic slot you need a helper function that picks the selected value of that one kind of slot out of CURRENT_SLOTS, either relying on the naming scheme or on a list of supported values of that kind of slot hardcoded in the helper function (in an eclass). That seems a little fragile. Your "dynamic slot groups" idea could help with this, by having that list sit in a more sensible place than in an eclass, and perhaps by having the package mangler provide a variable per slot group (a little like how USE_EXPAND works). I really dislike the implicit dependencies. First of all: it is entirely possible for ebuild A supporting dynamic slots for (say) python to have a build-time dependency on ebuild B that supports dynamic slots (also for python), but only to get at a utility to run, not to use B as a library. In that case we don't want to force slots to match, and (as you point out) that may not even be possible if the two packages don't support the same slots. Also, it just breaks down completely if you don't use your "slot groups" idea: if A has DYNAMIC_SLOTS="|| ( py2.6 py2.7 )" and B has DYNAMIC_SLOTS="|| ( ruby1.8 ruby1.9 )" it makes no sense to require the dynamic slot setting to match, but if A has DYNAMIC_SLOTS="|| ( py2.5 py2.6 )" and B has "|| ( py2.7 py3.2 )" then we do need them to match, and the user has requested an impossible situation (he needs to use versions of A and B that have at least one supported python version in common). Without "slot groups" the package manager cannot tell these two cases apart. I think it'd make more sense to have those slot groups, per-slot group variables like DYNAMIC_SLOTS_PYTHON="py2.7 py3.2" resulting in CURRENT_SLOT_PYTHON getting set, and an addition to the dependency syntax that lets you depend on a matching named dynamic slot. That makes your DYNAMIC_SLOTS="|| ( py2.6 py2.7 ruby1.8 ruby1.9 )" example impossible, but I think it'd be uncommon for that approach to make sense: I think it'd usually make more sense to split that into two packages, one per language. -- Marien Zwart
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote: > I'm attaching a reStructuredText version of the spec. You can view it > rendered as a gist[1]. But please keep the replies on the list, rather > than forking the gist. I don't like the approach taken in 6. I'd rather state that there should not be file collisions between the dynamic slots. We already handle things this way in ruby (with a common 'all' and specific version builds). For 9c I can't see us limiting users to a single ruby implementation by default (the only current exception is www-apache/passenger), so a combined ||() block makes no sense to me. I think it is better to be explicit here and express the real situation with multiple ||() blocks if needed. Finally, I don't expect ruby to use this unless we can ensure that this works with our current ebuilds without changes. I'm fine with supporting some code in the eclass to determine which mechanism to use in which way, but we won't be spending huge amounts of time switching to yet another system. To me the perceived benefits aren't big enough. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 16.06.2012 19:51, schrieb Michał Górny: > On Fri, 15 Jun 2012 09:54:12 +0200 > Florian Philipp wrote: > >> Am 15.06.2012 06:50, schrieb Duncan: >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: >>> So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, "do we have a 'company' that can pay Microsoft to sign our bootloader?" is one aspect from the non-technical side that I've been wondering about. >>> >>> I've been following developments and wondering a bit about this >>> myself. >>> >>> I had concluded that at least for x86/amd64, where MS is mandating >>> a user controlled disable-signed-checking option, gentoo shouldn't >>> have a problem. Other than updating the handbook to accommodate >>> UEFI, presumably along with the grub2 stabilization, I believe >>> we're fine as if a user can't figure out how to disable that option >>> on their (x86/amd64) platform, they're hardly likely to be a good >>> match for gentoo in any case. >>> >> >> As a user, I'd still like to have the chance of using Secure Boot with >> Gentoo since it _really_ increases security. Even if it means I can no >> longer build my own kernel. > > It doesn't. It's just a very long wooden fence; you just didn't find > the hole yet. > Oh come on! That's FUD and you know it. If not, did you even look at the specs and working principle? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Dynamic SLOTs
Hello, I have prepared a first draft of 'dynamic SLOT' specification. This is my proposal in attempt to solve the problem of building packages for multiple Python and Ruby versions. It could also be reused for multilib. The spec tries to explain the broad idea, and all problems relevant to it. It also lists a few problems which are still unsolved and I think they will cause the spec to change after hearing your ideas. To be honest, I tried to keep it as simple as possible. Please don't say it doesn't solve all the world problems because it simply won't. I'm attaching a reStructuredText version of the spec. You can view it rendered as a gist[1]. But please keep the replies on the list, rather than forking the gist. [1]:https://gist.github.com/2943774 -- Best regards, Michał Górny = Dynamic SLOTs = 1. Motivation - There is currently no good way to handle building and installing ebuilds for multi-ABI languages like Perl, Python or Ruby. The Perl modules are bound to a particular Perl version. Since we support having only one Perl version around, this issue will supposedly be solved via ABI_SLOT solution which is not part of this spec. However, we support having multiple Python & Ruby versions installed (via SLOTs). Therefore, we need to have a good solution to support having multiple versions of modules, each one built against respective ABI version. Currently, this problem is worked-around through USE flags. This solution is incomplete and has a few drawbacks including: - necessity of rebuilding *all* package versions when the list of enabled ABIs changes, - dynamically changing IUSE with new Python/Ruby versions being released (supported). The dynamic SLOT solution is supposed to solve these problems through providing a way to: - build multiple package variants (dynamic SLOTs) from the same ebuild, - have those variants installed in parallel, - automatically handle cross-package dynamic SLOT dependencies. 2. Definitions -- dynamic SLOT A dynamically assigned, additional SLOT specification for a package, representing ABIs for which it was built. Dynamic SLOT is defined at build-time. A single package may have more than one dynamic SLOT defined. dynamic SLOT variant of a package A single package built against chosen dynamic SLOT specification. 3. Defining supported SLOTs in an ebuild An ebuild supporting building for multiple dynamic SLOTs has to declare the supported slots using ``DYNAMIC_SLOTS`` variable. The variable can be inherited from eclasses. The one-of (``|| ( )``) group can be used in this variable to specify exclusive SLOT groups. For example, an ebuild supporting building for multiple Python ABIs would declare (either explicitly or implicitly through an eclass):: DYNAMIC_SLOTS='|| ( py2.6 py2.7 py3.1 py3.2 )' which would mean that when the package is built, one of the ``pyX.Y`` SLOTs must be used (and only one). An ebuild may also declare multiple dynamic SLOTs to be specified at a time:: DYNAMIC_SLOTS='|| ( py2.6 py2.7 ) || ( lib32 lib64 )' In this case, both one of ``pyX.Y`` and ``libX`` SLOTs need to be declared. 4. Building the ebuild against chosen SLOTs --- In ``pkg_*`` and ``src_*`` phases, the build environment is provided with currently enabled dynamic SLOTs via ``CURRENT_SLOTS`` array. The ebuild must use the contents of this variable to adjust the build process accordingly which can be done either directly or via an eclass. If multiple ABIs were chosen, they are propagated onto next indices of the array. 5. Relevance to binary and installed packages - It is necessary to store the dynamic SLOTs for which a package was built in the binary package and installed package metadata. The exact semantics are left to be implementation-specific. The implementation must ensure, however, that a multiple dynamic SLOT variants of the same package can be installed at the same time. For example, dynamic SLOT could be appended after package version:: dev-python/foo-1.2.3+py2.6 dev-libs/bar-1.0+lib32 6. Installed file collissions - Due to the specifics of dynamic SLOT implementation, it is possible that files installed by various dynamic SLOTs collide. For example, each dynamic SLOT variant of a Python module may install a README file in the same docdir. The ebuilds must ensure that the colliding files are exactly the same in all dynamic SLOT variants of the package. The package manager may either choose to overwrite those files when installing each consecutive dynamic ABI variant of a package, or leave the earlier version. The package must not remove the file unless all of dynamic SLOT variants of the package were unmerged. 7. Inter-package dependencies - If an
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/graphviz: ChangeLog
On 06/17/2012 10:12 AM, Naohiro Aota (naota) wrote: naota 12/06/17 07:12:19 Modified: ChangeLog Log: Add ~x86-fbsd. #419621 (Portage version: 2.2.0_alpha110/cvs/Linux x86_64) Revision ChangesPath 1.261media-gfx/graphviz/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?r1=1.260&r2=1.261 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v retrieving revision 1.260 retrieving revision 1.261 diff -u -r1.260 -r1.261 --- ChangeLog 16 Jun 2012 16:39:58 - 1.260 +++ ChangeLog 17 Jun 2012 07:12:19 - 1.261 @@ -1,6 +1,9 @@ # ChangeLog for media-gfx/graphviz # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.260 2012/06/16 16:39:58 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.261 2012/06/17 07:12:19 naota Exp $ + + 17 Jun 2012; Naohiro Aota graphviz-2.28.0.ebuild: + Add ~x86-fbsd. #419621 16 Jun 2012; Samuli Suominen graphviz-2.28.0.ebuild, metadata.xml: No change happened to the ebuild itself as it already had ~x86-fbsd (some faulty script?)
