Re: [gentoo-dev] Re: crossdev and multilib interference
On Thu 27 Mar 2014 00:41:47 Alexandre Rostovtsev wrote: On Wed, 2014-03-26 at 22:41 -0400, Mike Frysinger wrote: On Wed 26 Mar 2014 12:23:53 Ian Stakenvicius wrote: On 26/03/14 12:12 PM, Mike Frysinger wrote: that's bs. people install crossdev to get a cross-compile environment, not to get something that only works through `emerge`. attempting to restrict it so it only works through `emerge` is unacceptable and it has never been that way. it -does- make sense though to limit anything that one wants to EMERGE with the crossdev, to require the use of cross-emerge. Would it not be possible to somehow ensure the crossdev tools are ignored in/removed from/cannot pollute the standard emerge environment? Are there any use cases where one -would- want the crossdev to be used in a standard emerge environment instead of using cross-emerge ? you've lost me. when you `emerge-$CTARGET`, that package doesn't go anywhere near your ROOT=/ system. it's entirely contained in /usr/$CTARGET/. when you run `crossdev $CTARGET`, it installs all the standard $CTARGET-xxx tools in /usr/bin. this isn't polluting the environment at all ... in fact, they're living right alongside existing tools. as i pointed out elsewhere in this thread, the problem is that multilib relies on automatic detection of the toolchain *failing* so that it falls back to the native value. in other words, when you run `./configure --host=i686-pc-linux- gnu`, it tries to find e.g. i686-pc-linux-gnu-ar. it doesn't exist so the fallback is used (plain `ar`). multilib is using these tuples so that the standard checks (autoconf/eclasses/etc...) trigger in the right ways for the cpu/os/userland combinations. since crossdev installs a full proper toolchain for the target, the one multilib was using to lie now exists and its toolchain is used instead. Crossdev is polluting the environment in the specific case that we are talking about - secondary native ABIs on a multilib system. An amd64 multilib system is not expected to build MIPS binaries that would be hosted on itself. So of course anyone using amd64 undersands that mips-pc-linux-gnu-ar is part of a cross-compile toolchain, no matter whether it's in /usr/bin or /usr/libexec/crossdev or anywhere in the filesystem. However, an i686 crossdev on an amd64 multilib system is a fundamentally different situation. no, it is not An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if the user wants to build an ABI using their default toolchain, they can pass the right ABI flag for it. but that's irrelevant to how our multilib implementation picks its fake CHOST_$ABI to take care of implementing things. if anything, the current system is provably broken because the default ends up executing unqualified `ar` and `ranlib` friends. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] crossdev and multilib interference
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead
of i686-pc-linux-gnu would defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken, but we
can sort that out independently.
-mike
--- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 - 1.21
+++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -
@@ -21,17 +21,17 @@ ABI=amd64
# 64bit specific settings.
CFLAGS_amd64=-m64
LDFLAGS_amd64=-m elf_x86_64
-CHOST_amd64=x86_64-pc-linux-gnu
+CHOST_amd64=${CHOST}
# 32bit specific settings.
CFLAGS_x86=-m32
LDFLAGS_x86=-m elf_i386
-CHOST_x86=i686-pc-linux-gnu
+CHOST_x86=i686-gentoo%multilib-linux-gnu
# 64-32bit specific settings.
CFLAGS_x32=-mx32
LDFLAGS_x32=-m elf32_x86_64
-CHOST_x32=x86_64-pc-linux-gnux32
+CHOST_x32=x86_64-gentoo%multilib-linux-gnux32
# 2006/10/24 - Simon Stelling bl...@gentoo.org
# They are masked, but we can enable them anyway for those who have
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: crossdev and multilib interference
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote: An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if the user wants to build an ABI using their default toolchain, they can pass the right ABI flag for it. They can't pass the right ABI flag because only the core parts of the toolchain have the concept of an ABI flag. Sure, binutils and gcc respect -m32. But what about pkgconfig (and its clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for various libraries? Are you going to patch all of them to respect -m32? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: crossdev and multilib interference
On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote: On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote: An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if the user wants to build an ABI using their default toolchain, they can pass the right ABI flag for it. They can't pass the right ABI flag because only the core parts of the toolchain have the concept of an ABI flag. Sure, binutils and gcc respect -m32. But what about pkgconfig (and its clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for various libraries? Are you going to patch all of them to respect -m32? pkg-config does need fixing in some way. we already know this. it's why the multilib eclasses currently set PKG_CONFIG_XXX vars -- preciously so the correct ABI dir is utilized. and this breaks when using some build systems (like scons) where the env gets blown away (although we also know scons sucks). i don't care about the *-config scripts. that's a dead concept long ago proven to suck and anything still using it needs fixing. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: crossdev and multilib interference
Dnia 2014-03-27, o godz. 02:41:21 Mike Frysinger vap...@gentoo.org napisał(a): On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote: On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote: An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if the user wants to build an ABI using their default toolchain, they can pass the right ABI flag for it. They can't pass the right ABI flag because only the core parts of the toolchain have the concept of an ABI flag. Sure, binutils and gcc respect -m32. But what about pkgconfig (and its clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for various libraries? Are you going to patch all of them to respect -m32? pkg-config does need fixing in some way. we already know this. it's why the multilib eclasses currently set PKG_CONFIG_XXX vars -- preciously so the correct ABI dir is utilized. and this breaks when using some build systems (like scons) where the env gets blown away (although we also know scons sucks). i don't care about the *-config scripts. that's a dead concept long ago proven to suck and anything still using it needs fixing. Because it's everyone else that *always* does something wrong, and the rising number of work-arounds in the eclass just proves you're doing it the correct way. It's sad that decisions are made by man who *does not care* about most of the real-life things but cares much for his own precious tools that get priority over eclasses, and whenever they are essentially broken by design, you say that the world is actually broken and they are the only fine thing. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] crossdev and multilib interference
Dnia 2014-03-27, o godz. 02:13:52
Mike Frysinger vap...@gentoo.org napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead
of i686-pc-linux-gnu would defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken, but we
can sort that out independently.
Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.
--- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 - 1.21
+++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -
@@ -21,17 +21,17 @@ ABI=amd64
# 64bit specific settings.
CFLAGS_amd64=-m64
LDFLAGS_amd64=-m elf_x86_64
-CHOST_amd64=x86_64-pc-linux-gnu
+CHOST_amd64=${CHOST}
# 32bit specific settings.
CFLAGS_x86=-m32
LDFLAGS_x86=-m elf_i386
-CHOST_x86=i686-pc-linux-gnu
+CHOST_x86=i686-gentoo%multilib-linux-gnu
Using percent sign here looks like asking for trouble at some point.
I don't see why you can't use plain 'gentoomultilib' that is more
fool-proof.
# 64-32bit specific settings.
CFLAGS_x32=-mx32
LDFLAGS_x32=-m elf32_x86_64
-CHOST_x32=x86_64-pc-linux-gnux32
+CHOST_x32=x86_64-gentoo%multilib-linux-gnux32
# 2006/10/24 - Simon Stelling bl...@gentoo.org
# They are masked, but we can enable them anyway for those who have
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: crossdev and multilib interference
On 27/03/14 08:41, Mike Frysinger wrote: On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote: On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote: An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if the user wants to build an ABI using their default toolchain, they can pass the right ABI flag for it. They can't pass the right ABI flag because only the core parts of the toolchain have the concept of an ABI flag. Sure, binutils and gcc respect -m32. But what about pkgconfig (and its clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for various libraries? Are you going to patch all of them to respect -m32? pkg-config does need fixing in some way. we already know this. it's why the multilib eclasses currently set PKG_CONFIG_XXX vars -- preciously so the correct ABI dir is utilized. and this breaks when using some build systems (like scons) where the env gets blown away (although we also know scons sucks). I pushed 0.28-r1 of dev-util/pkgconfig with ABI_X86 support so that you can directly call eg. i686-pc-linux-gnu-pkg-config to search from /usr/lib32/pkgconfig/ I'll try to figure something out for pkgconfig-openbsd too. Don't care about pkgconf. i don't care about the *-config scripts. that's a dead concept long ago proven to suck and anything still using it needs fixing. nod
Re: [gentoo-dev] crossdev and multilib interference
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of
collisions. e.g. having an ABI=amd64 system use
i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-gnu would
defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken, but
we
can sort that out independently.
Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.
such as ... ? vague statements can't be addressed.
--- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 -
1.21
+++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -
@@ -21,17 +21,17 @@ ABI=amd64
# 64bit specific settings.
CFLAGS_amd64=-m64
LDFLAGS_amd64=-m elf_x86_64
-CHOST_amd64=x86_64-pc-linux-gnu
+CHOST_amd64=${CHOST}
# 32bit specific settings.
CFLAGS_x86=-m32
LDFLAGS_x86=-m elf_i386
-CHOST_x86=i686-pc-linux-gnu
+CHOST_x86=i686-gentoo%multilib-linux-gnu
Using percent sign here looks like asking for trouble at some point.
I don't see why you can't use plain 'gentoomultilib' that is more
fool-proof.
i merely picked a value that was highly unlikely for people to use. the %
should be safe as it is not interpreted by the shell and strongly indicates
hey man, don't mess with me. it could just as easily be a _ or nothing at
all. i don't feel strongly about it.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: crossdev and multilib interference
really have no idea what you're ranting about. doesn't look discussion worthy though. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] ImageMagick[opencl] sandbox access violations
Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-icon-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim.
[gentoo-dev] Re: Re: crossdev and multilib interference
Mike Frysinger wrote: Steven J. Long wrote: Mike Frysinger wrote: if they're in $PATH, then the exact location is irrelevant. they need not be in /usr/bin to cause a problem. if they're not in $PATH, then you're breaking the cross-compilers and that is unacceptable. Cross-compilation should be supported via cross-emerge, and perhaps a small script the cross-compiler sources to setup the env (ie prefix to PATH in this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting a straight x86 platform, instead of the normal multilib setup. The latter being used by the former (I'd have thought it was already done.) The cross tools should NOT pollute the default PATH, simply because the user happened to run crossdev at some point. that's bs. people install crossdev to get a cross-compile environment, not to get something that only works through `emerge`. attempting to restrict it so it only works through `emerge` is unacceptable and it has never been that way. That's why I suggested a small sh script to source, to setup that environment. Personally, I do an awful lot more than that just to build a native chroot, let alone cross-compile. And I really don't see the hardship for these brave cross-compilers of yours in sourcing a small setup script, which can be added to ~/.bashrc or even the system-wide one, for anyone who really wants it to apply whenever they login. Is this somehow beyond our most advanced userbase? People may install crossdev to get a cross-compile environment, but it's a broken design if it's not contained. And BS about how you think it should ALWAYS go for everybody, only leads to borked solutions elsewhere like telling the people on an amd64 install that they have to run some god-awful new %multilib thing to compile for their secondary ABI. That's just as counter-intuitive, when you could just fix your borkage and have a clean setup for everyone. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] ImageMagick[opencl] sandbox access violations
There's a sandbox.d configuration directory on purpose; imagemagick[opencl] should probably install its own exception. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 27 March 2014 07:29, Maxim Koltsov maksbo...@gentoo.org wrote: Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-icon-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim.
Re: [gentoo-dev] ImageMagick[opencl] sandbox access violations
btw, this is http://bugs.gentoo.org/472766 i'll look into adding a sandbox.d file... On 27/03/14 10:54, Diego Elio Pettenò wrote: There's a sandbox.d configuration directory on purpose; imagemagick[opencl] should probably install its own exception. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu mailto:flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 27 March 2014 07:29, Maxim Koltsov maksbo...@gentoo.org mailto:maksbo...@gentoo.org wrote: Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-icon-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim.
Re: [gentoo-dev] crossdev and multilib interference
Dnia 2014-03-27, o godz. 03:18:31
Mike Frysinger vap...@gentoo.org napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of
collisions. e.g. having an ABI=amd64 system use
i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-gnu would
defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken, but
we
can sort that out independently.
Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.
such as ... ? vague statements can't be addressed.
Such as all the builds that use ${CHOST}-foo currently. If you change
CHOST, our users will have to find and rebuild all packages that
install ${CHOST}-foos or otherwise random breakage will happen.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Pacho Ramos dixit: Due to nirbheek's lack of time the following packages are now up for grabs: x11-themes/gtk-engines-murrine I'm using it, but don't know how to maintain a package yet. Just letting you know, before you have to throw it out of the tree, I'll take it. Greetings, Alex
Re: [gentoo-dev] ImageMagick[opencl] sandbox access violations
Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-ico n-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim. This makes no sense, since it would have to be applied to every ebuild which (even indirectly) depends on imagemagick. Diego's and Samuli's solution is much better. -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?
Tom Wijsman wrote: If we were to take this example to its extreme; then we would have to create an inventory of which INSTALL_MASK entries are good and bad for each ebuild, in which we cover all the files installed by that ebuild. Why are you directing this at me? Please don't cc me off-list. Keep list discussion to the list. (That's an old one.) As for extremes I think it a dubious argument, much like many of your if only we define X like Y, even though we've all been discussing X at the end of a long chain of usually futile discussion. It's evidently meant for a few packages which would break, to avoid obvious breakage, and not as a blanket mechanism. That would run counter to the whole spirit of you break it, you pick up the pieces. IF there is a need to do it, that's how you can do it. If not, it's got nothing to do with me anyhow, since I'm not the one calling for it, nor raising the topic. Oh, and I realise you have difficulty configuring your email client[1]: it's still rude of you to constantly quote people's email addresses inline, imo. Long, tedious justifications notwithstanding. Especially when it turns out you can't even configure your client, and it might reasonably be surmised you have spouted justification to cover ignorance. I'm perfectly happy to take the time to edit my responses, in answer to your last justification for this behaviour. [1] http://marc.info/?l=gentoo-userm=139549986219431w=2 -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] crossdev and multilib interference
Dnia 2014-03-27, o godz. 10:23:30
Mike Frysinger vap...@gentoo.org napisał(a):
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of
collisions. e.g. having an ABI=amd64 system use
i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-gnu would
defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken,
but
we
can sort that out independently.
Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.
such as ... ? vague statements can't be addressed.
Such as all the builds that use ${CHOST}-foo currently. If you change
CHOST, our users will have to find and rebuild all packages that
install ${CHOST}-foos or otherwise random breakage will happen.
again, please give a concrete example
glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclass)
gpg-error -- ${CHOST}-gpg-error-config
libgcrypt -- ${CHOST}-libgcrypt-config
llvm -- ${CHOST}-llvm-config
pango -- ${CHOST}-pango-querymodules
If you change CHOST, all invocations of those tools will fail randomly
until the respective packages are rebuilt. In some cases it will call
the wrong variant (resulting in borked output), in other it will call
non-existing tool.
And let's just hope it's the only issue we're going to hit.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] crossdev and multilib interference
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of
collisions. e.g. having an ABI=amd64 system use
i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-gnu would
defeat any automatic path searches.
this patch keeps the status quo. although the status quo is broken,
but
we
can sort that out independently.
Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.
such as ... ? vague statements can't be addressed.
Such as all the builds that use ${CHOST}-foo currently. If you change
CHOST, our users will have to find and rebuild all packages that
install ${CHOST}-foos or otherwise random breakage will happen.
again, please give a concrete example
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Thu, 27 Mar 2014 13:43:24 + Steven J. Long wrote: Tom Wijsman wrote: It's evidently meant for a few packages which would break, to avoid obvious breakage, and not as a blanket mechanism. Yes, it is; but a package consists of multiple ebuilds, and thus, the individual files of the individual ebuilds are brought up as they would need to be tracked, which brings in more work to the maintainer. -- [OT] Below talk is about whom is addressed gentoo-dev ML etiquette. If we were to take this example to its extreme; then we would have to create an inventory of which INSTALL_MASK entries are good and bad for each ebuild, in which we cover all the files installed by that ebuild. Why are you directing this at me? The quoted paragraph is directed at anyone reading the example; and given I direct it to them, you are directed to as part of this out of respect to allow you to update the example if you need to. it's still rude of you to constantly quote people's email addresses Why is it rude? There are a lot of other developers on the list here that do this as well; so, if you want to see this changed then please bring it up for a vote. Un-CC-ed and stripped this time per request; being able to set this on a specific person, however, I don't see how to do that in my mailing client. Patches to do as such are welcome. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Packages up for grabs
On Thu, 27 Mar 2014 12:46:11 +0100 Alexander Hof gentoo...@cosmofox.net wrote: Pacho Ramos dixit: Due to nirbheek's lack of time the following packages are now up for grabs: x11-themes/gtk-engines-murrine I'm using it, but don't know how to maintain a package yet. Just letting you know, before you have to throw it out of the tree, I'll take it. Hello Alexander At the moment that you plan to do this, please CC proxy-ma...@gentoo.org such that we can help you with that; also note that tree removals are announced as last rites on the gentoo-project mailing list, it might end up being removed by someone other than those whom are here. More information about the proxy maintainers project: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[gentoo-dev] RFC: small update for check-reqs.eclass
The current test for MERGE_TYPE in check-reqs_pkg_setup suppresses
also the CHECKREQS_DISK_{USR,VAR} checks which are relevant for binary
installs. Move the test to check-reqs_run().
Also, don't check install disk space requirements if building a binpkg
without installing it.
--- check-reqs.eclass 19 Oct 2012 03:35:15 - 1.13
+++ check-reqs.eclass 27 Mar 2014 22:27:27 -
@@ -91,8 +91,6 @@
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
- [[ ${MERGE_TYPE} == binary ]] return
-
check-reqs_prepare
check-reqs_run
check-reqs_output
@@ -132,24 +130,29 @@
# some people are *censored*
unset CHECKREQS_FAILED
- [[ -n ${CHECKREQS_MEMORY} ]] \
- check-reqs_memory \
- ${CHECKREQS_MEMORY}
-
- [[ -n ${CHECKREQS_DISK_BUILD} ]] \
- check-reqs_disk \
- ${T} \
- ${CHECKREQS_DISK_BUILD}
-
- [[ -n ${CHECKREQS_DISK_USR} ]] \
- check-reqs_disk \
- ${EROOT}/usr \
- ${CHECKREQS_DISK_USR}
-
- [[ -n ${CHECKREQS_DISK_VAR} ]] \
- check-reqs_disk \
- ${EROOT}/var \
- ${CHECKREQS_DISK_VAR}
+ # use != in test, because MERGE_TYPE only exists in
EAPI 4 and later
+ if [[ ${MERGE_TYPE} != binary ]]; then
+ [[ -n ${CHECKREQS_MEMORY} ]] \
+ check-reqs_memory \
+ ${CHECKREQS_MEMORY}
+
+ [[ -n ${CHECKREQS_DISK_BUILD} ]] \
+ check-reqs_disk \
+ ${T} \
+ ${CHECKREQS_DISK_BUILD}
+ fi
+
+ if [[ ${MERGE_TYPE} != buildonly ]]; then
+ [[ -n ${CHECKREQS_DISK_USR} ]] \
+ check-reqs_disk \
+ ${EROOT}/usr \
+ ${CHECKREQS_DISK_USR}
+
+ [[ -n ${CHECKREQS_DISK_VAR} ]] \
+ check-reqs_disk \
+ ${EROOT}/var \
+ ${CHECKREQS_DISK_VAR}
+ fi
}
# @FUNCTION: check-reqs_get_mebibytes
pgpNBYL3iNYTF.pgp
Description: PGP signature
[gentoo-portage-dev] [PATCH] depgraph: Skip atoms that are None (bug 505944)
Don't try to display atoms that are None when in debug mode. --- Can I get an ACK on this please? Do share your ideas for refactoring, if any. But even if this is not how we want it to work in the end, I still think we should commit it to fix the bug. pym/_emerge/depgraph.py | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py index abb70a7..556cb08 100644 --- a/pym/_emerge/depgraph.py +++ b/pym/_emerge/depgraph.py @@ -2211,12 +2211,13 @@ class depgraph(object): # Display the specific atom from SetArg or # Package types. uneval = - if dep.atom is not dep.atom.unevaluated_atom: - uneval = (%s) % (dep.atom.unevaluated_atom,) - writemsg_level( - %s%s%s required by %s\n % - (Parent Dep:.ljust(15), dep.atom, uneval, myparent), - level=logging.DEBUG, noiselevel=-1) + if dep.atom is not None: + if dep.atom is not dep.atom.unevaluated_atom: + uneval = (%s) % (dep.atom.unevaluated_atom,) + writemsg_level( + %s%s%s required by %s\n % + (Parent Dep:.ljust(15), dep.atom, uneval, myparent), + level=logging.DEBUG, noiselevel=-1) # Ensure that the dependencies of the same package # are never processed more than once. -- 1.8.3.2
[gentoo-portage-dev] [PATCH 0/3] Let's standardise commit messages
The first two patches here are not interesting. The first one makes DEVELOPING cap at the same width as README. The second adds a duh paragraph on commits. They are only bundled with what I really wanna talk about because I need ACKs to push them anyway. (Please ACK them, someone.) So what I really wanna talk about are commit messages. They are sort of a mess. Let's just standardise them to something sane. I believe my suggestions are sane, and pretty much what everybody does. The reason I wanna do #number for bugs is because a) we need the number for easy grep and of course to look up the relevant bug, and b) because '#' is a very grepable char for looking up recently fixed bugs with head or whatever. No bikeshedding, please. These are not very interesting things to talk about. Let's just form a decision. Object if you have an objection. If not, give me an ACK. Alexander Berntsen (3): DEVELOPING: Cap at 72 columns DEVELOPING: Add note on commits DEVELOPING: Add note on commit messages DEVELOPING | 98 +- 1 file changed, 65 insertions(+), 33 deletions(-) -- 1.8.3.2
[gentoo-portage-dev] [PATCH 1/3] DEVELOPING: Cap at 72 columns
--- Nothing to see here, move along. DEVELOPING | 71 +- 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/DEVELOPING b/DEVELOPING index 40b4ca2..1f5087a 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -1,37 +1,39 @@ Code Guidelines --- -A few code guidelines to try to stick to, please comment if none of these make -sense, they are pretty basic and mostly apply to old code. However for people -who are looking at current code, they make take up bad habits that exist in the -current codebase. +A few code guidelines to try to stick to, please comment if none of +these make sense, they are pretty basic and mostly apply to old code. +However for people who are looking at current code, they make take up +bad habits that exist in the current codebase. Python Version -- -Python 2.6 is the minimum supported version, since it is the first version to -support Python 3 syntax. All exception handling should use Python 3 'except' -syntax, and the print function should be used instead of Python 2's print -statement (from __future__ import print_function). +Python 2.6 is the minimum supported version, since it is the first +version to support Python 3 syntax. All exception handling should use +Python 3 'except' syntax, and the print function should be used instead +of Python 2's print statement (from __future__ import print_function). Dependencies -Python and Bash should be the only hard dependencies. Any other dependencies, -including external Python modules that are not included with Python itself, -must be optionally enabled by run-time detection. +Python and Bash should be the only hard dependencies. Any other +dependencies, including external Python modules that are not included +with Python itself, must be optionally enabled by run-time detection. Tabs -The current code uses tabs, not spaces. Keep whitespace usage consistent -between files. New files should use tabs. Space is sometimes used for -indentation in Python code. Tab stop should for this reason be set to 4. +The current code uses tabs, not spaces. Keep whitespace usage +consistent between files. New files should use tabs. Space is +sometimes used for indentation in Python code. Tab stop should for this +reason be set to 4. Line-Wrapping - -Lines should typically not be longer than 80 characters; if they are an attempt -should be made to wrap them. Move code to the line below and indent once (\t). +Lines should typically not be longer than 80 characters; if they are an +attempt should be made to wrap them. Move code to the line below and +indent once (\t). errors.append(MalformedMetadata( errors.DESCRIPTION_TOO_LONG_ERROR % \ @@ -45,9 +47,10 @@ errors.append(MalformedMetadata( (length, max_desc_len), attr='DESCRIPTION.toolong') -The mixing of tabs and spaces means other developers can't read what you did. -This is why the python peps state spaces over tabs; because with spaces the line -wrapping is always clear (but you cannot convert spaces as easily as tabwidth). +The mixing of tabs and spaces means other developers can't read what you +did. This is why the python peps state spaces over tabs; because with +spaces the line wrapping is always clear (but you cannot convert spaces +as easily as tabwidth). Comparisons --- @@ -78,9 +81,9 @@ Generally you can do two things here, if you are messing with defaults.. dict.get(foo, some_default) -will try to retrieve foo from dict, if there is a KeyError, will insert foo -into dict with the value of some_default. This method is preferred in cases where -you are messing with defaults: +will try to retrieve foo from dict, if there is a KeyError, will insert +foo into dict with the value of some_default. This method is preferred +in cases where you are messing with defaults: try: dict[foo] @@ -114,7 +117,8 @@ YES: NO: import os,sys,time -When importing from a module, you may import more than 1 thing at a time. +When importing from a module, you may import more than 1 thing at a +time. YES: from portage.module import foo, bar, baz @@ -139,9 +143,9 @@ NO: import sys Try not to import large numbers of things into the namespace of a module. -I realize this is done all over the place in current code but it really makes it -a pain to do code reflection when the namespace is cluttered with identifiers -from other modules. +I realize this is done all over the place in current code but it really +makes it a pain to do code reflection when the namespace is cluttered +with identifiers from other modules. YES: @@ -153,14 +157,15 @@ from portage.output import bold, create_color_func, darkgreen, \ green, nocolor, red, turquoise, yellow The YES example imports the 'output' module into the current namespace. -The negative here is having to use output.COLOR all over the
[gentoo-portage-dev] [PATCH 3/3] DEVELOPING: Add note on commit messages
--- DEVELOPING | 20 1 file changed, 20 insertions(+) diff --git a/DEVELOPING b/DEVELOPING index c6004ec..a34dda5 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -175,6 +175,26 @@ change a lot of unrelated things. This makes it easier to see what parts of the system have actually changed. It also makes it easier to cherry-pick and revert commits. Use your commonsense! +Commit messages +--- + +Commit messages should be in the imperative mood with a capitalised +header, optionally followed by a newline and a more detailed explanatory +text. The headline should be capped at 50 characters, the detailed text +at 72. Prefix the message with the component you touched if this makes +sense. Postfix the message with the bug it fixes, if it does. Example: + + +emerge: Fix --tree output (#55) + +Make sure newlines appear where they are supposed to. Fix a bug with +colourisation of --tree output when used in tandem with --verbose +--pretend --ask. + + +For a more detailed explanation (and rationalisation) of these rules: +http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html + Releases -- 1.8.3.2
Re: [gentoo-portage-dev] [PATCH 3/3] DEVELOPING: Add note on commit messages
On Thu, 27 Mar 2014 13:48:40 +0100 Alexander Berntsen berna...@gentoo.org wrote: --- DEVELOPING | 20 1 file changed, 20 insertions(+) diff --git a/DEVELOPING b/DEVELOPING index c6004ec..a34dda5 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -175,6 +175,26 @@ change a lot of unrelated things. This makes it easier to see what parts of the system have actually changed. It also makes it easier to cherry-pick and revert commits. Use your commonsense! +Commit messages +--- + +Commit messages should be in the imperative mood with a capitalised +header, optionally followed by a newline and a more detailed explanatory +text. The headline should be capped at 50 characters, the detailed text +at 72. Prefix the message with the component you touched if this makes +sense. Postfix the message with the bug it fixes, if it does. Example: + + +emerge: Fix --tree output (#55) + +Make sure newlines appear where they are supposed to. Fix a bug with +colourisation of --tree output when used in tandem with --verbose +--pretend --ask. + + +For a more detailed explanation (and rationalisation) of these rules: +http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html + Releases No, Willikins works with Bug 55, not #55. so stick with (bug 55) format or if your worried about the space since bug is 2 char. longer than #, drop the 2 () characters. It'll be the same length so: +emerge: Fix --tree output bug 55 -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] [PATCH 1/3] DEVELOPING: Cap at 72 columns
On Thu, 27 Mar 2014 13:48:38 +0100 Alexander Berntsen berna...@gentoo.org wrote: --- Nothing to see here, move along. do it. -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] [PATCH 2/3] DEVELOPING: Add note on commits
On Thu, 27 Mar 2014 13:48:39 +0100 Alexander Berntsen berna...@gentoo.org wrote: --- Boilerplate text, nothing to see here either. DEVELOPING | 7 +++ 1 file changed, 7 insertions(+) diff --git a/DEVELOPING b/DEVELOPING index 1f5087a..c6004ec 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -167,6 +167,13 @@ when functions are needed and often unused functions are left in the import line until someone comes along with a linter to clean up (does not happen often). +Commits +--- + +Prefer small commits that change specific things to big commits that +change a lot of unrelated things. This makes it easier to see what +parts of the system have actually changed. It also makes it easier to +cherry-pick and revert commits. Use your commonsense! Releases ack -- Brian Dolbec dolsen
