Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Dnia 2015-01-19, o godz. 23:09:55 Rémi Cardona r...@gentoo.org napisał(a): Why not : libav? ( media-libs/libav:= ) ffmpeg? ( media-libs/ffmpeg:= ) + REQUIRED_USE=^^ ( libav ffmpeg ) I for one would never expect USE=-libav to enable ffmpeg (nor USE=-ffmpeg to enable libav FWIW). Two reasons: 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. -- Best regards, Michał Górny pgp9UBc_kkA0a.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, Jan 19, 2015 at 5:32 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 19 Jan 2015 17:02:11 -0500 Rich Freeman ri...@gentoo.org wrote: You're complaining about how somebody made a fix that they wouldn't have had to make but for the commit you made without consulting with them. No, I didn't do that commit at all and only a little complaining. This is between hasufell and patrick. I see now how you're confused there, so I'll skip the rest of your explaining since it shouldn't have been addressed to me at all. :) Indeed, apologies. -- Rich
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On 01/19/2015 05:44 PM, Pacho Ramos wrote: I agree with your suggestion but I would prefer the Remi's approach of letting people to know if they want ffmpeg or libav, otherwise it is not so obvious to know what disabling/enabling one of that USE flags will end up causing without reading each ebuild :/ (also, maybe some ebuilds will use one logic while others the inverse) This triggered a repressed memory of a bug once filed against me: https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags I vaguely agree, but please address any hate mail to Diego.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Mon, Jan 19, 2015 at 4:40 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-19, o godz. 23:09:55 Rémi Cardona r...@gentoo.org napisał(a): Why not : libav? ( media-libs/libav:= ) ffmpeg? ( media-libs/ffmpeg:= ) + REQUIRED_USE=^^ ( libav ffmpeg ) I for one would never expect USE=-libav to enable ffmpeg (nor USE=-ffmpeg to enable libav FWIW). Two reasons: 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. There are only 61 packages with USE=ffmpeg, and quite few of those might reasonably have package.use different from make.conf. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. So, it is then expected to have both (USE=ffmpeg libav) to enable the feature and then select the implementation? That's quite counter-intuitive, and in some cases, there are some significant API differences - it is not just a drop-in auxiliary implementation.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
El lun, 19-01-2015 a las 23:40 +0100, Michał Górny escribió: Dnia 2015-01-19, o godz. 23:09:55 Rémi Cardona r...@gentoo.org napisał(a): Why not : libav? ( media-libs/libav:= ) ffmpeg? ( media-libs/ffmpeg:= ) + REQUIRED_USE=^^ ( libav ffmpeg ) I for one would never expect USE=-libav to enable ffmpeg (nor USE=-ffmpeg to enable libav FWIW). Two reasons: 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. I agree with your suggestion but I would prefer the Remi's approach of letting people to know if they want ffmpeg or libav, otherwise it is not so obvious to know what disabling/enabling one of that USE flags will end up causing without reading each ebuild :/ (also, maybe some ebuilds will use one logic while others the inverse)
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
On Mon, Jan 19, 2015 at 4:41 AM, Alexis Ballier aball...@gentoo.org wrote: On Sun, 18 Jan 2015 15:15:22 -0800 Matt Turner matts...@gentoo.org wrote: mmx - Use the MMX instruction set mmxext - Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) padlock - Use VIA padlock instructions popcnt - Enable popcnt instruction support sse - Use the SSE instruction set sse2 - Use the SSE2 instruction set sse3 - Use the SSE3 instruction set (pni in cpuinfo) sse4 - Enable SSE4 instruction support We shouldn't have an sse4 USE flag. It's either one of the three below, but SSE4 by itself isn't a thing. wikipedia says it is sse4.1 + sse4.2 Some CPUs don't have 4.2, and some don't have 4a. You'd still need the separate flags, so an extraneous combined flag is a bit silly.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Mon, Jan 19, 2015 at 08:31:45PM +0100, Michał Górny wrote: Hello, As we've discussed multiple times, the following kind of dependencies is completely broken and can't work: || ( media-libs/libav:= media-libs/ffmpeg:= ) For this reason, I would like to employ the solution used by Exherbo. More specifically, use: libav? ( media-libs/libav:= ) !libav? ( media-libs/ffmpeg:= ) Is this going to be wrapped in a ffmpeg ? ( ) block? What happens if I want libav and not ffmpeg and i set -ffmpeg libav in make.conf? Does that mean I get nothing? cuz that is pretty un-intuitive. -- Jason
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
On Mon, 19 Jan 2015 08:13:46 +0800 Patrick Lauer wrote: On Sunday 18 January 2015 21:44:05 Michał Górny wrote: Hello, I would like to commit the following flags as cpu_flags_x86_desc. The list combines global USE flags with some local USE flags I've been able to find. 3dnow - Use the 3DNow! instruction set 3dnowext - Use the Enhanced 3DNow! instruction set Those are kinda mostly dead (no new CPUs have them anymore) 1) Modern AMD CPUs still support them (and can give performance benefits from using them. 2) I'm writing right now from an old host with CPU supporting them. aes-ni - Enable support for Intel's AES instruction set (aes in cpuinfo) avx - Adds support for Advanced Vector Extensions instructions avx2 - Adds support for Advanced Vector Extensions 2 instructions fma - Use the Fused Multiply Add instruction set mmx - Use the MMX instruction set Not sure if this one needs to be specified - amd64 always has it, and on x86 your code should do cpu feature detection anyway 1) No. We have cpudetection USE flag if user wants it. 2) Not all VIA CPUs support MMX. 3) Run-time CPU detection is *always slower* than compiled in code. (Learn the difference between using GOTs or long jupms and not using them, especiall on non-amd64 sysmems.) mmxext - Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) padlock - Use VIA padlock instructions Kinda very dead, even more than 3dnow So what? There are still people using it. popcnt - Enable popcnt instruction support Why?! Why not? It is an instruction set outside from official SSE4.2 standard, as well as LZCNT by the way. sse - Use the SSE instruction set Always exists on amd64, so this would be x86 special sse2 - Use the SSE2 instruction set sse3 - Use the SSE3 instruction set (pni in cpuinfo) sse4 - Enable SSE4 instruction support sse4_1 - Enable SSE4.1 instruction support sse4_2 - Enable SSE4.2 instruction support sse4a - Enable SSE4a instruction support ssse3 - Use the SSSE3 instruction set Wow, such a wonderful mess :) Very productive comment... So half of those are obsolete/dead, and the other half you need to do proper feature detection - why do we want that as useflags again? Because we have users interested in these flags, including myself but not limited to. Best regards, Andrew Savchenko pgplC2PtOBYLx.pgp Description: PGP signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Le 19/01/2015 23:40, Michał Górny a écrit : 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. I think our users are clever enough to update their USE flags as they wish. USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple and easily understood. I'd much rather we went with that. Cheers, Rémi
Re: [gentoo-dev] Things one could be upset about
On Tue, 20 Jan 2015 00:14:29 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote: From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). As the user the last thing I want is to have some USE flags changed without my permission ending up stuff I need to be omitted or stuff I don't want to see on my system to be installed. Of course if someone prefers USE flags to be randomly changed I don't mind if such option will exist (as proposed in bug #258371) as long as it is disabled by default. Is is of course perfectly fine to have that option disabled by default. But I am afraid that I do not quite understand yours and Daniel's concerns. If I paraphrase your statement with regards to current dependency handling, it is as if you were saying: I do not want portage to install any package automatically by its own, I want to install all the dependencies explicitly. Why we allow portage to install dependencies and still have things under control? Well we have --pretend and --ask options and we can see what would/will be done. This would be the same with USE flags. You would see in the --pretend output which flags would be changed. To match the package dependency handling, there should be also an option equivalent to --depclean. It would revert the USE changes which were done because of dependencies requirements if no longer needed. For example, lets have following packages: - libbar - libfoo with IUSE=bar, which depends on: bar? ( libbar ) - foo, which depends on: libfoo[bar] USE flag bar is not enabled. You want to install application foo. Current behaviour: # emerge -av foo ... Required USE changes: libfoo +bar ... (sorry for not exact emerge output but you get the idea) Now, you either fire up your favorite editor and add libfoo +bar to /etc/portage/package.use, re-run emerge and have libbar installed even you do not want it. The other option is not to install application foo at all. If you choose to emerge it and after year or so you decide to unmerge it because you do not need it anymore you still will have a leftover in package.use file - the line libfoo +foo even if you run emerge --depclean. New behaviour with automatic USE dependencies resolution: emerge -av foo [ebuild N ] libbar [ebuild N ] libfoo +bar [ebuild N ] foo Now, you can hit Y if you agree what portage wants to do or N and not to install foo at all. After unmerging it you run emerge --depclean which removes libfoo with its changed USE flag and libbar, no leftovers. (In this case new --use-depclean command is not required since libfoo was removed.) If libfoo would not be removed because some other package needs it, then emerge --use-depclean would revert the +bar USE flag to its default state and re-emerge libfoo. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Dnia 2015-01-20, o godz. 08:36:56 Rémi Cardona r...@gentoo.org napisał(a): Le 19/01/2015 23:40, Michał Górny a écrit : 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. I think our users are clever enough to update their USE flags as they wish. USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple and easily understood. I'd much rather we went with that. It's not about cleverness. It's about Gentoo developers being clever enough not to require users constantly going forth and back with the USE flags. -- Best regards, Michał Górny pgpbzQAD0iWQH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On Wed, 14 Jan 2015 11:01:16 -0800 Zac Medico zmed...@gentoo.org wrote: Why should we have to foresee the future? We can easily add support for new flags in CPU_FLAGS_* variables at any time. Ah, what I meant was that whoever maintains this flag list only needs to forsee the present—when AMD or Intel adds a new instruction set extension, you add a flag for it to the variable immediately, whether or not any package actually uses it yet. Why? Here’s why: Case 1: flags are added only as packages need them. This is pretty much what we have today, only without the USE-expand feature. Every time a package adds support for a new CPU feature, it gets a new USE flag, and I see it in my emerge output. Now I have to go and look up what the feature is, what it would be called in cpuinfo, and whether I have it. Maybe I already looked up the same CPU feature two or three times, many months ago, and forgot about it, for some other package. Lots of wasted work. But I can’t just ignore it, because maybe this is the first time that flag showed up, because no package ever used that feature before, but my CPU *does* have it, so I really want to turn it on! Case 2: flags are all added immediately as the CPU features are announced. When I install Gentoo, all the possible flags for my CPU are already listed in the variable. I immediately turn all those I have on and all those I don’t have off. Done. Now I can completely stop paying attention to the flags. As packages gain support, they gain new flags, and I can ignore them, secure in the knowledge that the flags for those features I have will all be turned on, while those I don’t have will be turned off, with no further input from me. Nice and easy. I’m not saying add flags for feature sets that haven’t been announced yet. I’m just saying, add flags for feature sets that *are* announced but that no package actually uses yet. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Mon, 19 Jan 2015 20:51:31 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský ope...@tightmail.com wrote: From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). This is only possible in carefully selected circumstances, and to get it to work more generally would require a lot of hinting from package maintainers. But portage already knows that. It tells the user which USE flags needs to be changed in order to emerge a package. It should just go one step further - to make the proposed change happen by itself. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, Jan 19, 2015 at 3:30 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 19 Jan 2015 10:21:15 -0500 Rich Freeman ri...@gentoo.org wrote: On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers j...@gentoo.org wrote: The only (QA) problem I see is the pointless removal of the ebuild in question and the subsequent addition of a pointless revision bump with no clue as to why it was removed or why the revision bump was required: You'd probably do well to read: https://en.wikipedia.org/wiki/Clean_hands The TL;DR of that is People who live in glass houses shouldn't throw stones. I get that you're probably not being serious, but if for some reason you are I'd suggest letting somebody else in QA handle it. And, really, next time just talk to somebody before you go bumping their ebuilds. If they're not cooperative then you'll garner a lot more sympathy. This is staff quiz kind of stuff. I have no idea why you're telling me all that. I don't normally quote excessive context but in this case I really don't see how my text and your text connect. You're complaining about how somebody made a fix that they wouldn't have had to make but for the commit you made without consulting with them. It is a bit like crashing into your neighbor's parked car and then complaining that they didn't do a good job cleaning up the glass on the sidewalk the next day. Courts call that having unclean hands - if you cut your foot on that glass you'd have a hard time suing them for it, even in the US where you can sue just about anybody for anything. -- Rich
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Why not : libav? ( media-libs/libav:= ) ffmpeg? ( media-libs/ffmpeg:= ) + REQUIRED_USE=^^ ( libav ffmpeg ) I for one would never expect USE=-libav to enable ffmpeg (nor USE=-ffmpeg to enable libav FWIW). Rémi
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, 19 Jan 2015 17:02:11 -0500 Rich Freeman ri...@gentoo.org wrote: You're complaining about how somebody made a fix that they wouldn't have had to make but for the commit you made without consulting with them. No, I didn't do that commit at all and only a little complaining. This is between hasufell and patrick. I see now how you're confused there, so I'll skip the rest of your explaining since it shouldn't have been addressed to me at all. :) jer
Re: [gentoo-portage-dev] [PATCH] chpathtool.py: avoid unnecessary optparse import
On Mon, 19 Jan 2015 01:13:17 -0800 Zac Medico zmed...@gentoo.org wrote: Since commit d217db2bc76e4c1a2e75685b4a00e25f7d8142a8, the optparse module has been imported unconditionally, even when the argparse module is available. Fix it to import optparse only if the argparse import fails. Fixes: d217db2bc76e (Make use of optparse to fix argument parsing for Python 2.6 in bin/chpathtool.py.) --- bin/chpathtool.py | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) Looks good. :) -- Brian Dolbec dolsen
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers j...@gentoo.org wrote: The only (QA) problem I see is the pointless removal of the ebuild in question and the subsequent addition of a pointless revision bump with no clue as to why it was removed or why the revision bump was required: You'd probably do well to read: https://en.wikipedia.org/wiki/Clean_hands The TL;DR of that is People who live in glass houses shouldn't throw stones. I get that you're probably not being serious, but if for some reason you are I'd suggest letting somebody else in QA handle it. And, really, next time just talk to somebody before you go bumping their ebuilds. If they're not cooperative then you'll garner a lot more sympathy. This is staff quiz kind of stuff. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, Jan 19, 2015 at 4:33 AM, Sergey Popov pinkb...@gentoo.org wrote: Do not get me wrong, Patrick. You, as QA team member, can touch other's packages without prior noticing, if fixing serious issues involved. But with great power comes great responsibility. Please, use your power more wisely next time. This wasn't a QA commit. QA modifications should always be noted as such in the commit/changelogs/etc. If you revert/etc one of these commits expect to be called on it, and you had better have a REALLY good reason for it. You're best off pinging somebody in QA if you have an issue with a QA commit, and working with them. If somebody feels QA commits are being abused they should reach out to the QA lead, or ultimately Comrel/Council if things can't be worked out - as you say with great power comes great responsibility. Commits made by people who happen to be members of QA that aren't labeled as QA commits are the same as commits made by any random developer, and should generally follow the same processes. That means working out things 1:1 if possible, and if not going through the normal Comrel process. The QA team really had nothing to do with this commit. I don't think bringing up QA is particularly helpful here. However, in general developers should always work with maintainers when modifying their packages, especially for things like bumps. It isn't always practical to consult with individual developers for tree-wide work, but this kind of work should generally be announced on the appropriate lists and so on, and will often use tracker bugs and the like. It sounds like neither was done here. However, in these sorts of situations it is probably better to let Comrel do their job (and appeal to Council if you're unsatisfied with it), rather than having everybody bicker on the list. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Rich Freeman wrote: working out things 1:1 if possible .. it is probably better to let Comrel do their job, rather than having everybody bicker on the list. Working out things 1:1 *on the list* is nice in that it adds transparency. Of course, it is then also very easy for people to send unrelated replies. //Peter
Re: [gentoo-dev] Things one could be upset about
Patrick Lauer: Here's a random unsorted list of things that it would make sense to be upset about. Some issues that people have successfully ignored for a few years ... In no way exhaustive list, feel free to remember a dozen things I forgot ;) (If you suggest other things please try to offer constructive criticism, i.e. possible strategies to fix issues ... whining by itself is not very useful) Thanks, that's an excellent thread. I think you forgot an important point: * lack of practical QA: no review workflow and no appropriate tools for reviewing I could start a long text block about why reviewing is mandatory for QA, but let's just think about it this way: What do you think would happen if the linux kernel switched to CVS and gave the most active 250 collaborators direct push access to the main Linus repository? I hope greg k-h does not read this. He'd probably get a heart attack. Also: people seem to think we don't have enough manpower for a review workflow. No, it's really the other way around. If you make collaboration difficult, then you need a lot more manpower.
Re: [gentoo-dev] Things one could be upset about
17.01.2015 18:51, Ciaran McCreesh пишет: On Sat, 17 Jan 2015 19:49:24 +0400 Сергей protsero...@gmail.com wrote: Any random user can tell you: -u means UPDATE, -D means DEEP (follow dependencies). And what do those actually mean? Do you need citation from 'man portage'? :-) -D usually adds to deptree more deps, than usual 'world'(if we are still talking about 'emerge -uDN world') like deps of deps, etc, until full tree will be built. Maybe i am not totally correct, cause i am not portage developer, but that's my point of view. And 'man portage' is telling me pretty much the same things -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH] chpathtool.py: avoid unnecessary optparse import
Since commit d217db2bc76e4c1a2e75685b4a00e25f7d8142a8, the optparse
module has been imported unconditionally, even when the argparse module
is available. Fix it to import optparse only if the argparse import
fails.
Fixes: d217db2bc76e (Make use of optparse to fix argument parsing for Python
2.6 in bin/chpathtool.py.)
---
bin/chpathtool.py | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/bin/chpathtool.py b/bin/chpathtool.py
index 9b26086..842f1f4 100755
--- a/bin/chpathtool.py
+++ b/bin/chpathtool.py
@@ -13,14 +13,12 @@ import os
import stat
import sys
-from portage.util._argparse import ArgumentParser
-
-# Argument parsing compatibility for Python 2.6 using optparse.
-if sys.hexversion 0x207:
+try:
+ from argparse import ArgumentParser
+except ImportError:
+ ArgumentParser = None
from optparse import OptionParser
-from optparse import OptionError
-
CONTENT_ENCODING = 'utf_8'
FS_ENCODING = 'utf_8'
@@ -154,8 +152,8 @@ def chpath_inplace_symlink(filename, st, old, new):
def main(argv):
- parser = ArgumentParser(description=doc)
- try:
+ if ArgumentParser is not None:
+ parser = ArgumentParser(description=doc)
parser.add_argument('location', default=None,
help='root directory (e.g. $D)')
parser.add_argument('old', default=None,
@@ -165,9 +163,8 @@ def main(argv):
opts = parser.parse_args(argv)
location, old, new = opts.location, opts.old, opts.new
- except OptionError:
+ else:
# Argument parsing compatibility for Python 2.6 using optparse.
- if sys.hexversion 0x207:
parser = OptionParser(description=doc,
usage=usage: %prog [-h] location old new\n\n
+ \
location: root directory (e.g. $D)\n + \
@@ -178,13 +175,10 @@ def main(argv):
if len(args) != 3:
parser.print_usage()
- print(%s: error: expected 3 arguments, got %i
+ parser.error(%s: error: expected 3 arguments,
got %i
% (__file__, len(args)))
- return
location, old, new = args[0:3]
- else:
- raise
is_text_file = IsTextFile()
--
2.0.5
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
On Sun, 18 Jan 2015 15:15:22 -0800 Matt Turner matts...@gentoo.org wrote: mmx - Use the MMX instruction set mmxext - Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) padlock - Use VIA padlock instructions popcnt - Enable popcnt instruction support sse - Use the SSE instruction set sse2 - Use the SSE2 instruction set sse3 - Use the SSE3 instruction set (pni in cpuinfo) sse4 - Enable SSE4 instruction support We shouldn't have an sse4 USE flag. It's either one of the three below, but SSE4 by itself isn't a thing. wikipedia says it is sse4.1 + sse4.2 Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Fri, 16 Jan 2015 15:26:55 + hasufell hasuf...@gentoo.org wrote: Patrick Lauer (patrick): patrick 15/01/16 04:16:55 Modified: ChangeLog Added:libuv-1.2.1.ebuild Log: Bump I expect people to ask me for review if they bump any of my packages. That includes QA team members. The only (QA) problem I see is the pointless removal of the ebuild in question and the subsequent addition of a pointless revision bump with no clue as to why it was removed or why the revision bump was required: *libuv-1.2.1-r1 (16 Jan 2015) 16 Jan 2015; Julian Ospald hasuf...@gentoo.org +libuv-1.2.1-r1.ebuild: version bump 16 Jan 2015; Julian Ospald hasuf...@gentoo.org -libuv-1.2.1.ebuild: rm unreviewed ebuild Also, nobody brought up the QA role but you. jer
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer patr...@gentoo.org wrote: * AutoRepoman catches on average maybe 2 user-visible breakages. Mostly removing stable on HPPA ;) Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours) Fix: Remind people that using repoman is not optional repoman doesn't check reverse dependencies for the package you're working on. eshowkw(1) displays keywording in a pretty nice graph. Avoiding removing the (last) stable ebuild probably involves having that automatically invoked on entering (or working in, at some point) a package directory and actually reading the output before you decide to remove any ebuild. jer
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
On Sun, 18 Jan 2015 21:44:05 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, I would like to commit the following flags as cpu_flags_x86_desc. The list combines global USE flags with some local USE flags I've been able to find. 3dnow - Use the 3DNow! instruction set 3dnowext - Use the Enhanced 3DNow! instruction set aes-ni - Enable support for Intel's AES instruction set (aes in cpuinfo) avx - Adds support for Advanced Vector Extensions instructions avx2 - Adds support for Advanced Vector Extensions 2 instructions fma - Use the Fused Multiply Add instruction set mmx - Use the MMX instruction set mmxext - Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) padlock - Use VIA padlock instructions popcnt - Enable popcnt instruction support sse - Use the SSE instruction set sse2 - Use the SSE2 instruction set sse3 - Use the SSE3 instruction set (pni in cpuinfo) sse4 - Enable SSE4 instruction support sse4_1 - Enable SSE4.1 instruction support sse4_2 - Enable SSE4.2 instruction support sse4a - Enable SSE4a instruction support ssse3 - Use the SSSE3 instruction set e... are you aware that these descriptions are close to useless ? 'foo - enable foo' - thanks for the information I couldn't have guessed... you already have more useful ones available: flag name=fma3Enables FMA3 optimizations: AMD processors starting with Piledriver architecture and Intel Haswell based processors or later./flag flag name=fma4Enables FMA4 optimizations: AMD processors starting with Bulldozer architecture./flag flag name=sse4_2Enables SSE4.2 optimizations: Nehalem-based Intel Core i7 or later./flag flag name=ssse3Faster floating point optimization for SSSE3 capable chips (Intel Core 2 and later chips)/flag and so on... Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
17.01.2015 03:56, Patrick Lauer пишет: On Friday 16 January 2015 18:29:08 hasufell wrote: Patrick Lauer: On 01/16/15 23:26, hasufell wrote: Patrick Lauer (patrick): patrick 15/01/16 04:16:55 Modified: ChangeLog Added:libuv-1.2.1.ebuild Log: Bump I expect people to ask me for review if they bump any of my packages. That includes QA team members. Are you always in such a bad mood? Do you, as QA team member, think that a review workflow improves quality? No. Bureaucracy does not improve quality by itself. We are talking about following the rules[1]. Did this bump fix some serious issue, that you need to fix without notifing maintainer, as our policies states? I did not see any mentions of bugs, related to this bump, even simple version bump bug. And not signs of issues fixed in ChangeLog message either. Thus - i understand hasufell's reaction. Do not get me wrong, Patrick. You, as QA team member, can touch other's packages without prior noticing, if fixing serious issues involved. But with great power comes great responsibility. Please, use your power more wisely next time. Ordinary version bump(unless we have some breakages in tree, because of really old versions in tree) is not the case of serious issue. You should probably file a bug on package maintainer next time, as ordinary developers usually do for packages, that are not maintained by them. And only if no reaction from maintainer for a reasonable time amount will follow - bump it yourself. [1] - http://wiki.gentoo.org/wiki/GLEP:48 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc
On Mon, 19 Jan 2015 08:13:46 +0800 Patrick Lauer patr...@gentoo.org wrote: So half of those are obsolete/dead, and the other half you need to do proper feature detection - why do we want that as useflags again? http://article.gmane.org/gmane.linux.gentoo.devel/94299
Re: [gentoo-dev] Things one could be upset about
On 01/19/15 17:47, Jeroen Roovers wrote: On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer patr...@gentoo.org wrote: * AutoRepoman catches on average maybe 2 user-visible breakages. Mostly removing stable on HPPA ;) Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours) Fix: Remind people that using repoman is not optional repoman doesn't check reverse dependencies for the package you're working on. If it were fast enough we could do that. pcheck from pkgcore was at one point down to under 3 minutes for a full tree scan, that's pretty much fast enough so that people could run it on almost every ebuild removal. repoman takes around 30 minutes when parallelized, on the fastest hardware I currently have access to. Or about 2 CPU-hours with a single thread ... that's prohibitively slow.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
2015-01-19 10:40 Jeroen Roovers napisał(a):
On Fri, 16 Jan 2015 15:26:55 +
hasufell hasuf...@gentoo.org wrote:
Patrick Lauer (patrick):
patrick 15/01/16 04:16:55
Modified: ChangeLog
Added:libuv-1.2.1.ebuild
Log:
Bump
I expect people to ask me for review if they bump any of my packages.
That includes QA team members.
The only (QA) problem I see is the pointless removal of the ebuild in
question and the subsequent addition of a pointless revision bump with
no clue as to why it was removed or why the revision bump was required
$ diff -u1 libuv-1.2.1.ebuild libuv-1.2.1-r1.ebuild
--- libuv-1.2.1.ebuild
+++ libuv-1.2.1-r1.ebuild
@@ -2,3 +2,3 @@
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-libs/libuv/Attic/libuv-1.2.1.ebuild,v
1.1 2015/01/16 04:16:55 patrick Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-libs/libuv/libuv-1.2.1-r1.ebuild,v 1.1
2015/01/16 15:47:31 hasufell Exp $
@@ -9,3 +9,3 @@
DESCRIPTION=A new platform layer for Node
-HOMEPAGE=https://github.com/joyent/libuv;
+HOMEPAGE=https://github.com/libuv/libuv;
SRC_URI=https://github.com/libuv/libuv/archive/v${PV}.tar.gz - ${P}.tar.gz
@@ -17,3 +17,6 @@
-DEPEND=virtual/pkgconfig
+DEPEND=
+ sys-devel/libtool
+ virtual/pkgconfig
+
@@ -24,4 +27,4 @@
sed -i \
- -e '/libuv_la_CFLAGS/s#-g##' \
- Makefile.am || die fixing CFLAGS failed!
+ -e '/CC_CHECK_CFLAGS_APPEND(\[-g\])/d' \
+ configure.ac || die fixing CFLAGS failed!
The broken libuv-1.2.1.ebuild was not disabling unwanted addition of -g to
CFLAGS.
The fix for this problem affected installed files, so revision bump was
required.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] amd64-fbsd profiles are now 'dev' profiles
Hi all, As I was the one wanting amd64-fbsd profiles 'stable' to ensure a sane deptree, and seeing the number of (re)keywording bugs growing and growing while I don't have time to process them and no-one else is doing it, I just switched them to 'dev' state. For users, this means they can no longer expect packages to have a correct dependency tree with ~amd64-fbsd keywords: packages can now have missing optional, or even mandatory, deps making them uninstallable in some cases. For developers, this means broken dependencies for amd64-fbsd changed from a repoman error to an optional warning; meaning that in most cases developers won't even notice their package has broken deps on this arch. While I don't think there is any general rule, what I would recommend is the following: - If you have a package whose amd64-fbsd keywords have been dropped between version N and N+1, keep version N in tree as long as it does not annoy you, then drop it. - If you introduce a new version that would create a broken deptree (and run repoman -d to notice it), keep ~amd64-fbsd keywords if the missing dep is optional, drop keywords otherwise. - Since, from my experience, most developers will not even notice broken deps on amd64-fbsd, filling (re)keywording bugs for amd64-fbsd is optional. Anyone wanting to restore its stable state will have to run a full check on the entire tree anyway. If anyone is interested in taking over the arch and restoring its stable status, you are very welcome, but for now it is just annoying more and more fellow developers in this state. Best regards, Alexis.
[gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Hello, As we've discussed multiple times, the following kind of dependencies is completely broken and can't work: || ( media-libs/libav:= media-libs/ffmpeg:= ) For this reason, I would like to employ the solution used by Exherbo. More specifically, use: libav? ( media-libs/libav:= ) !libav? ( media-libs/ffmpeg:= ) This has two advantages: 1. gives users more explicit control over whether they want to use libav or ffmpeg. Since the two have mutual blockers, right now random packages could have tried to force you to switch from one to the other. However, most often Portage would just give you terribly unreadable blockers. 2. Subslots work correctly. Rebuilds are forced when the chosen library is upgraded. Moreover, USE flag change causes a rebuild when user decides to change the ffmpeg provider. The new USE flag descriptions would be: ffmpeg - Enable ffmpeg- or libav-based audio/video codec support libav - Prefer libav over ffmpeg This implies that USE=ffmpeg is only present if ffmpeg/libav support is optional while USE=libav is present to provide the choice between ffmpeg and libav. While this isn't the most clear solution, it provides backwards compatibility with the current use of USE=ffmpeg. Any comments? -- Best regards, Michał Górny
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Any comments? Sounds good!
Re: [gentoo-dev] Things one could be upset about
On Sun, Jan 18, 2015 at 01:21:56PM +0100, Dirkjan Ochtman wrote: On Sat, Jan 17, 2015 at 9:00 PM, William Hubbs willi...@gentoo.org wrote: Why the heck do we ship both 3.3 and 3.4? I forget the exact situation with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only is a great option if that remains the default after installation (although it would be fine for just the initial stages). I'm going to be very blunt. I am sick of the finger being pointed only at releng for this. To be quite clear, I didn't intend at all to point the finger at anyone. I mostly reckon it's due to an unfortunate way things hang together, definitely not any one person or group to blame. I just really don't understand how it happens. Cheers, Dirkjan Hey Dirkjan, I didn't mean to imply that *you* personally were pointing the finger at anyone, sorry about the misunderstanding. William signature.asc Description: Digital signature
Re: [gentoo-dev] Things one could be upset about
On Mon, 19 Jan 2015 12:42:45 +0300 Sergey Popov pinkb...@gentoo.org wrote: 17.01.2015 18:51, Ciaran McCreesh пишет: On Sat, 17 Jan 2015 19:49:24 +0400 Сергей protsero...@gmail.com wrote: Any random user can tell you: -u means UPDATE, -D means DEEP (follow dependencies). And what do those actually mean? Do you need citation from 'man portage'? :-) Well no, because that doesn't answer the question... -D usually adds to deptree more deps, than usual 'world'(if we are still talking about 'emerge -uDN world') like deps of deps, etc, until full tree will be built. Maybe i am not totally correct You're not totally correct. And 'man portage' is telling me pretty much the same things Right, which brings us back to the original point: very few people actually understand what those options *really* do, so claiming that Portage has an intuitive or obvious commandline is rather questionable. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] proposed update to toolchain.eclass
On 1/18/15 10:50 PM, Anthony G. Basile wrote:
Hi everyone, I'd like to make a commit to toolchain.eclass in a few
days. mgorny noticed some code which can be improved. Basically gcc
creates fixed include files from system headers because of the
requirement that it have ansi c compliant headers. These are fixed via
shells scripts during the build process, but we just delete them
afterwards. Rather than generate and then delete them, just don't
generate them in the first place. Its bug number #536878. I've tested
on gcc-3 to the latest and both approaches yield the same results.
Sounds good.
Here's the patch so you don't have to go hunting for it:
diff -u -B -r1.647 toolchain.eclass
--- toolchain.eclass15 Nov 2014 08:45:33 -1.647
+++ toolchain.eclass18 Jan 2015 20:36:08 -
@@ -595,6 +595,13 @@
einfo ${f%%...}
done
fi
+
+# we don't want fixed includes :)
Please consider summarizing above in the comment (mostly to the effect
that fixed headers are deleted afterwards and are not needed on modern
systems). It's obvious it's just disabling the logic in given shell
scripts, but from the code itself it's not obvious why.
Paweł
+if tc_version_is_at_least 4.0; then
+echo : ${S}/fixincludes/fixinc.in || die
+else
+echo : ${S}/gcc/fixinc/fixincl.sh || die
+fi
}
guess_patch_type_in_dir() {
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Things one could be upset about
On 2015-01-19 07:28, Patrick Lauer wrote: On 01/19/15 17:47, Jeroen Roovers wrote: On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer patr...@gentoo.org wrote: * AutoRepoman catches on average maybe 2 user-visible breakages. Mostly removing stable on HPPA ;) Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours) Fix: Remind people that using repoman is not optional repoman doesn't check reverse dependencies for the package you're working on. If it were fast enough we could do that. pcheck from pkgcore was at one point down to under 3 minutes for a full tree scan, that's pretty much fast enough so that people could run it on almost every ebuild removal. repoman takes around 30 minutes when parallelized, on the fastest hardware I currently have access to. Or about 2 CPU-hours with a single thread ... that's prohibitively slow. I'd be interested to hear if pcheck has regressed significantly at all for you when running it now on a similar set up. Thanks, Tim pgpzx_hu442lz.pgp Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote: On Sat, 17 Jan 2015 18:33:45 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote: The problem isn't the constants, though. The problem is the resolution algorithm. There's not much point tweaking performance until the resolver is fixed to produce a correct answer... Oh, this was discussed so many times already... There is NO single correct solution to such problems. And some mathematically correct solutions are impractical (e.g. half of the tree rebuild), so other ones which are good enough are preferred. As long as imperfect solution works fine, I'm ok with it. From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). As the user the last thing I want is to have some USE flags changed without my permission ending up stuff I need to be omitted or stuff I don't want to see on my system to be installed. Of course if someone prefers USE flags to be randomly changed I don't mind if such option will exist (as proposed in bug #258371) as long as it is disabled by default. Best regards, Andrew Savchenko pgpqoWBdnzXUy.pgp Description: PGP signature
Re: [gentoo-dev] proposed update to toolchain.eclass
On 01/19/15 13:34, Paweł Hajdan, Jr. wrote:
On 1/18/15 10:50 PM, Anthony G. Basile wrote:
Hi everyone, I'd like to make a commit to toolchain.eclass in a few
days. mgorny noticed some code which can be improved. Basically gcc
creates fixed include files from system headers because of the
requirement that it have ansi c compliant headers. These are fixed via
shells scripts during the build process, but we just delete them
afterwards. Rather than generate and then delete them, just don't
generate them in the first place. Its bug number #536878. I've tested
on gcc-3 to the latest and both approaches yield the same results.
Sounds good.
Here's the patch so you don't have to go hunting for it:
diff -u -B -r1.647 toolchain.eclass
--- toolchain.eclass15 Nov 2014 08:45:33 -1.647
+++ toolchain.eclass18 Jan 2015 20:36:08 -
@@ -595,6 +595,13 @@
einfo ${f%%...}
done
fi
+
+# we don't want fixed includes :)
Please consider summarizing above in the comment (mostly to the effect
that fixed headers are deleted afterwards and are not needed on modern
systems). It's obvious it's just disabling the logic in given shell
scripts, but from the code itself it's not obvious why.
Paweł
Okay a more detailed comment will go in that will make it clear to
future maintainers.
+if tc_version_is_at_least 4.0; then
+echo : ${S}/fixincludes/fixinc.in || die
+else
+echo : ${S}/gcc/fixinc/fixincl.sh || die
+fi
}
guess_patch_type_in_dir() {
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, 19 Jan 2015 18:17:12 +0100 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: The broken libuv-1.2.1.ebuild was not disabling unwanted addition of -g to CFLAGS. The fix for this problem affected installed files, so revision bump was required. Yes, and I was talking about ChangeLog entries to that effect. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
On Mon, 19 Jan 2015 10:21:15 -0500 Rich Freeman ri...@gentoo.org wrote: On Mon, Jan 19, 2015 at 4:40 AM, Jeroen Roovers j...@gentoo.org wrote: The only (QA) problem I see is the pointless removal of the ebuild in question and the subsequent addition of a pointless revision bump with no clue as to why it was removed or why the revision bump was required: You'd probably do well to read: https://en.wikipedia.org/wiki/Clean_hands The TL;DR of that is People who live in glass houses shouldn't throw stones. I get that you're probably not being serious, but if for some reason you are I'd suggest letting somebody else in QA handle it. And, really, next time just talk to somebody before you go bumping their ebuilds. If they're not cooperative then you'll garner a lot more sympathy. This is staff quiz kind of stuff. I have no idea why you're telling me all that. I don't normally quote excessive context but in this case I really don't see how my text and your text connect. jer
Re: [gentoo-dev] Things one could be upset about
On Sat, 17 Jan 2015 18:33:45 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote: The problem isn't the constants, though. The problem is the resolution algorithm. There's not much point tweaking performance until the resolver is fixed to produce a correct answer... Oh, this was discussed so many times already... There is NO single correct solution to such problems. And some mathematically correct solutions are impractical (e.g. half of the tree rebuild), so other ones which are good enough are preferred. As long as imperfect solution works fine, I'm ok with it. From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] Things one could be upset about
On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský ope...@tightmail.com wrote: From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). This is only possible in carefully selected circumstances, and to get it to work more generally would require a lot of hinting from package maintainers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On Mon, Jan 19, 2015 at 4:47 AM, Jeroen Roovers j...@gentoo.org wrote: repoman doesn't check reverse dependencies for the package you're working on. Indeed, it doesn't even check forward dependencies which are blockers. kmod-19 was just stabilized accidentally despite having a blocker on all stable versions of systemd. That resulted in a big scramble to backport a fix to systemd (and incidentally discover that openrc suffered from the same problem, thus resulting in yet another rushed fix). It would have been helpful if repoman could have noticed this. -- Rich
Re: [gentoo-dev] Things one could be upset about
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2015 12:44 PM, Róbert Čerňanský wrote: On Sat, 17 Jan 2015 18:33:45 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote: The problem isn't the constants, though. The problem is the resolution algorithm. There's not much point tweaking performance until the resolver is fixed to produce a correct answer... Oh, this was discussed so many times already... There is NO single correct solution to such problems. And some mathematically correct solutions are impractical (e.g. half of the tree rebuild), so other ones which are good enough are preferred. As long as imperfect solution works fine, I'm ok with it. From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). Robert As a user, the last thing I want happening is Portage making USE decisions for me. I'm completely in support of an emerge *flag*, but not doing it unconditionally. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUvXBBAAoJEJUrb08JgYgHqsQH/1m/Dgu547RTcooHhZ+B4gt1 FvjPGy1qEKB4W2ErxDj6J6TLlP09ASIiJ/7hrndKonDNd1aP4gAi7tKI5XzetWVt cWYG3UWLhxJRvMc2y7kbOyDSIy68Sz/r1Bruwymqdn+N6ooqnHVK252OJgaMGQHP aDa+ibNAywE7t/CTWS6rQU/ilEHsXIps+c4gmvEGv5iWiCKxlQF5fNKfWjOGEr9c NN23RaSEJj7BCEfFaFgmjd7P0akz/yzg/sr8xuaaEwUv5/KFJp7SI/Q/6GzG48rg H6TiNIYm3Gs0ucEWISCZx+qon5EmkkSREaQ5xeqBBRklNN63evH1pttjFg9rX6o= =RjLq -END PGP SIGNATURE-
