2009-08-21 22:56:41 David Leverton napisaƂ(a):
> In EAPI 3, most commands and functions provided by the package
> manager automatically call die if they fail.  There's also a
> new "nonfatal" function that can be used to suppress this
> behaviour: by prefixing a function/command call with nonfatal,
> the automatic die behaviour is suppressed during the executation
> of that function/command.
> 
> The difficulty here is that it's not clear what nonfatal should
> do to explicit die and assert calls.  On the one hand, if
> nonfatal does suppress these functions, then nonfatal can be
> usefully used with eclass functions - silly hypothetical example:
> 
>     # eclass
>     escons() {
>         scons "$...@}" || die "scons failed"
>     }
> 
>     # ebuild
>     nonfatal escons || do_something_else
> 
> On the other hand, it could be risky to change the behaviour of
> existing functions like that:
> 
>     do_foo() {
>         cd foo || die "cd failed"
>         # something that would be dangerous if run in some other directory
>     }
> 
> If called as "nonfatal do_foo" and the cd failed, do_foo
> /wouldn't/ return a failure code - it would proceed with the rest
> of its body and wreak all manner of havoc.
> 
> One way around this would be to add either an option to die to
> explicitly tell it to respect nonfatal, or an alternative die
> function.  This would allow eclasses to choose to respect
> nonfatal when it's safe to do so, but without changing existing
> behaviour.  The disadvantage of this is that it would require
> changes to all eclass functions that could potentially use it,
> plus the slight ugliness of making them handle older EAPIs as
> well.
> 
> Another option would be to make die respect nonfatal by default,
> and add an option that doesn't.  This wouldn't require changes to
> eclasses that want the nonfatal behaviour, but it would require
> some care to make sure that it was used when necessary.  A
> potential advantage of this over the previous solution is that if
> the "force" option is implemented with an environment variable,
> it can be used regardless of EAPI - the previous example could be
> changed to something like
> 
>     do_foo() {
>         cd foo || DIE_FORCE=1 die "cd failed"
>         # something that would be dangerous if run in some other directory
>     }
> 
> Does anyone have any opinions on which of the four options (#1
> make die respect nonfatal, #2 make die always die, #3 add a new
> die variant that respects nonfatal, #4 make regular die respect
> nonfatal, and add a new variant that doesn't) we should go with?

I think that 'DIE_FORCE=1 die "${die_message}"' (which was invented by me) 
would be the
best option. It will allow to use nonfatal() with eclass functions with the 
smallest
number of required changes in eclasses.

I would like to also notice that (not yet approved by Council) definition of 
nonfatal()
in PMS was recently drastically changed without proper discussion with 
developers of
other package managers. [1] was sent about 20 minutes after discussion about 
nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev 
mailing list.

[1] 
http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml

-- 
Arfrever Frehtes Taifersar Arahesis
### Log session started at 2009-08-06T13:57:20 ###
[13:57:20] Arfrever [n=arfre...@gentoo/developer/arfrever] has joined #gentoo-portage
[13:57:20] Channel topic is: This is not a help/support channel || Ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || Portage resources: http://www.gentoo.org/proj/en/portage/index.xml#doc_chap6
[13:57:20] Topic was set by zmedico on 2009-06-07T06:54:17
[13:57:20] pratchett.freenode.net [...@*] has set channel mode +tnc
[13:57:20] Channel was created at 2006-11-26T07:42:44
[14:07:37] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: "No Ping reply in 90 seconds."
[14:11:27] scarabeus [n=sca...@net-2-2.jaw.cz] has joined #gentoo-portage
[14:37:51] sping_ [n=sp...@e179008226.adsl.alicedsl.de] has joined #gentoo-portage
[14:54:07] reavertm [n=reave...@gentoo/contributor/reavertm] has quit IRC: Remote closed the connection
[15:05:30] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:05:34] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Remote closed the connection
[15:05:50] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:06:05] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Client Quit
[15:08:02] slonopotamus [n=slono...@83.149.10.164] has quit IRC: Read error: 110 (Connection timed out)
[15:08:10] FuzzyRay [n=pvar...@gentoo/developer/FuzzyRay] has joined #gentoo-portage
[15:21:01] noisebleed [n=noise...@piggy.inescn.pt] has quit IRC: Remote closed the connection
[15:41:22] sping_ [n=sp...@gentoo/user/sping] is now known as sping_afk
[16:07:53] ali_bush [n=alist...@gentoo/developer/alibush] has quit IRC: Read error: 110 (Connection timed out)
[16:33:35] gargoyle-grin [n=rande...@gentoo/contributor/gargoyle-grin] has joined #gentoo-portage
[16:46:24] yugmix [n=yug...@cepci-02p14-94.ppp18.odn.ad.jp] has joined #gentoo-portage
[16:47:33] slonopotamus [n=slono...@80.90.124.131] has joined #gentoo-portage
[17:07:45] neurogeek||m [n=neuro...@gentoo/developer/neurogeek] has joined #gentoo-portage
[17:29:25] Eudyptula [n=eudyp...@pool-96-227-117-222.phlapa.east.verizon.net] has joined #gentoo-portage
[17:50:01] few [n=...@90.136.223.210] has joined #gentoo-portage
[18:08:32] noisebleed [n=noise...@kermit.inescn.pt] has joined #gentoo-portage
[18:13:59] few [n=...@90.136.223.210] has quit IRC: Remote closed the connection
[18:57:05] noisebleed [n=noise...@kermit.inescn.pt] has quit IRC: Remote closed the connection
[18:57:46] noisebleed [n=noise...@piggy.inescn.pt] has joined #gentoo-portage
[19:03:45] neurogeek__ [n=neuro...@201.208.72.207] has joined #gentoo-portage
[19:04:47] neurogeek||m [n=neuro...@gentoo/developer/neurogeek] has quit IRC: Nick collision from services.
[19:05:15] neurogeek__ [n=neuro...@201.208.72.207] is now known as neurogeek||m
[19:13:16] igli [n=i...@fu/coder/igli] has joined #gentoo-portage
[19:21:30] javaJake [n=javaj...@unaffiliated/javajake] has joined #gentoo-portage
[20:50:53] noisebleed [n=noise...@piggy.inescn.pt] has quit IRC: Remote closed the connection
[20:56:28] slonopotamus [n=slono...@80.90.124.131] has quit IRC: Remote closed the connection
[20:56:39] slonopotamus [n=slono...@80.90.124.131] has joined #gentoo-portage
[21:12:07] ali_bush [n=alist...@gentoo/developer/alibush] has joined #gentoo-portage
[21:35:17] few [n=...@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[21:43:36] Gef` [n=g...@abo-76-63-68.mts.modulonet.fr] has joined #gentoo-portage
[21:46:16] <Arfrever> zmedico: I have 2 questions about nonfatal().
[21:46:16] <Arfrever> In ebuilds using EAPI <3, should nonfatal() be not defined, or should it be defined and call e.g. 'die "nonfatal not supported in this EAPI"'?
[21:46:16] <Arfrever> In ebuilds using EAPI >=3, when 'nonfatal ${command}' is called and ${command} fails, should it be silent, or should ewarn be used to print a warning?
[21:46:49] <zmedico> nonfatal should die in <3
[21:47:41] <zmedico> if nonfatal fails, I think it should warn on stderr, but not ewarn
[21:47:51] <zmedico> that way they can send it to /dev/null
[21:47:57] <zmedico> and it won't be logged
[21:48:45] <zmedico> maybe pms says something about that?
[21:53:01] <Arfrever> zmedico: PMS only says about non-zero exit status...
[21:53:22] <zmedico> ok, stderr warning seems good to me
[21:53:27] <zmedico> that's pretty standard
[21:53:45] <chithead> what happens if one puts "nonfatal die"? ;)
[21:53:58] <Arfrever> chithead: Warning.
[22:01:52] <dleverton> Arfrever: the intention was that nonfatal wouldn't apply to die itself, only builtin commands that might call die when they fail
[22:03:35] <Arfrever> dleverton: IMHO e.g. `nonfatal econf` should work :) .
[22:03:44] <chithead> dleverton: so "nonfatal die" would die, but "nonfatal nonfatal die" would not?
[22:04:04] <dleverton> Arfrever: right, that would just return an error status if econf fails
[22:04:26] <dleverton> chithead: no, because "nonfatal die" calls die regardless of whether it fails or not :-P
[22:06:04] <Arfrever> dleverton: PMS is unprecise, so we can implement nonfatal() however we want :) .
[22:06:59] <igli> ugh that is such a nasty syntax
[22:07:02] igli hides
[22:07:29] <dleverton> Arfrever: for one thing it's about to be changed to clarify that, for another thing, if you notice something like that it's better to get it clarified than to allow obvious potential incompatibilities to sneak in
[22:08:08] <dleverton> igli doesn't like HOFs :-(
[22:09:43] <dleverton> But in any case, thanks Arfrever and chithead for uncovering that
[22:14:46] <Arfrever> dleverton: `nonfatal ${function_from_eclass}` should work without modifying all functions defined in eclasses.
[22:15:47] <dleverton> Possibly
[22:16:11] <dleverton> Feel free to mention that on the gentoo-pms@ thread if you think it's a strong enough case for changing it
[22:16:28] <Arfrever> dleverton: PMS doesn't disallow it from working.
[22:16:44] <Arfrever> dleverton: My implementation of nonfatal() will support it.
[22:16:49] <dleverton> It will soon, if you don't argue against it
[22:17:02] <ABCD> what is `nonfatal foo` supposed to do if foo is defined as `foo() { (( $# == 1 )) || die "need 1 argument"; .... }`?
[22:17:32] <Arfrever> dleverton: You cannot drastically change behavior of functions defined in PMS without council decision.
[22:17:50] <igli> doFoo --or-die "${f...@]}"
[22:18:05] <dleverton> It's not a "drastic change", it's removing an accidental ambiguity
[22:18:36] <chithead> oh my, what have I started :)
[22:18:44] <dleverton> You could also argue that you can't apply your own interpretation of PMS without council decision
[22:19:13] <dleverton> chithead: it's better this way than if we'd only noticed when half the tree was relying on one or the other version ;-)
[22:19:58] <dleverton> But again, if you have strong feelings, it's best to get it discussed and agreed before people start using it
[22:20:13] <Arfrever> dleverton: There is no agreement that the ambiguity should be removed in a way suggested by you.
[22:20:47] <dleverton> Well, that's why patches get sent to the list for comments before being pushed
[22:22:08] <ABCD> I haven't read PMS recently, but does it allow for a function called under nonfatal to know that it was called under nonfatal?
[22:22:22] <ABCD> (if not, I think it probably should)
[22:22:54] <Arfrever> ABCD: It doesn't disallow it.
[22:23:02] <igli> a lib function could check it, but it's a pita for no reason imo.
[22:23:41] <ABCD> how would that function find out without 1) calling "die", or 2) violating PMS?
[22:24:01] <ABCD> (assume this is an eclass function, for instance)
[22:24:06] <dleverton> Arfrever: it doesn't disallow the package manager from running rm -rf / at random points, either
[22:24:58] <igli> man bash /FUNCNAME
[22:26:57] <ABCD> igli: that wasn't exactly what I had in mind (plus, "nonfatal" possibly could be implemented as an alias, which would cause that not to work)
[22:29:56] <igli> nonfatal is an alias? interesting
[22:30:05] <igli> Gentoo bash is hilarious
[22:30:08] igli [n=i...@fu/coder/igli] has left #gentoo-portage: "Have a good one ;-)"
[22:31:37] <dleverton> I'll never understand that guy
[22:31:39] Naib [...@fu/hw/naib] has joined #gentoo-portage
[22:36:53] <zmedico> ABCD: an alias is ok if it's only allowed in src_* phases. otherwise the expansion in environment.bz2 could cause problems depending on which package manager is used.
[22:39:00] <ABCD> zmedico: I was only refering to possibilities (as in, that which PMS does not explicitly prohibit, could be used by an implementation, no matter how hard that makes everyone else life :) )
[22:39:00] <Arfrever> zmedico: I almost implemented it (as function in isolated-functions.sh).
[22:39:27] <Arfrever> zmedico: How should the failure message be formatted?
[22:40:13] <zmedico> Arfrever: idk, just do it however you like and we can always change it
[22:51:09] slonopotamus [n=slono...@80.90.124.131] has quit IRC: "Leaving"
[22:51:24] <Arfrever> zmedico: Committed in r13936.
[22:51:34] <zmedico> great, thank you
[23:01:11] <Tommy[D]> zmedico: could it be that the dependency calculation for already installed packages is somewhat borked? i told portage to "emerge -e world", got around 15 failed, but after that, still many left at "emerge -pvuDN world"
[23:01:55] <zmedico> Tommy[D]: they'd probably be removed by --depclean
[23:02:05] <zmedico> which is normal
[23:02:39] <Tommy[D]> zmedico: no, for example, the comple font set, which i had installed was not remerged (with a changed useflag)
[23:02:49] <Tommy[D]> *complete
[23:04:08] <zmedico> Tommy[D]: sounds like bug 280394 but I'm not aware of any change that would cause it
[23:04:10] <Willikins> zmedico: https://bugs.gentoo.org/280394 "sys-apps/portage-2.2_rc35 fails to update @system @world - packages to be updated are not found/updated - leaves packages out-dated!"; Gentoo Linux, Core system; NEW; tor...@gmx.net:dev-port...@g.o
[23:04:39] <zmedico> best thing is to do emerge -puvDN world --debug
[23:05:04] <zmedico> and try to find a specific package that should have been pulled in but wasn't
[23:05:11] <Tommy[D]> zmedico: it happens both to emerge -e and emerge -avuDN, in both cases, the ebuilds are shown in the depgraph, but somewhere during run are dropped
[23:06:49] <zmedico> hmm, it's just the reinstalls?
[23:07:44] <Tommy[D]> thats what i currently test since i want to try all installed packages with lib32 useflag
[23:09:16] <zmedico> weird. I'll see if I can reproduce it when I do my updates.
[23:09:32] <zmedico> maybe it's something in your patch
[23:11:25] <Tommy[D]> i currently reduce the list by updating by hand, once the list is smaller, i can look when those dropping is done
[23:13:30] jlec1 [n=j...@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-portage
[23:13:51] <jlec1> zmedico: is this a portage unicode bug? bug 280600
[23:13:53] <Willikins> jlec1: https://bugs.gentoo.org/280600 "sys-libs/db creates localized strings in /usr/include/db.h; this prevents emerging python-3.1"; Gentoo Linux, Core system; NEW; olek...@butovo.com:bug-wrangl...@g.o
[23:14:13] <jlec1> I don't know who I wrangle it to.
[23:14:22] <jlec1> +should
[23:15:23] <Arfrever> jlec1: It's a duplicate of bug #280001.
[23:15:26] <Willikins> Arfrever: https://bugs.gentoo.org/280001 "dev-lang/python-3.1 fails to build with sys-libs/db headers containing non-UTF-8 characters"; Gentoo Linux, Unspecified; RESO, FIXE; a...@store20.com:pyt...@g.o
[23:15:47] <Arfrever> jlec1: But you can assign this bug to sys-libs/db maintainers.
[23:15:58] <Arfrever> s/this/this new/
[23:17:06] <jlec1> Will do so
[23:19:06] <javaJake> Arfrever: how do you find those dups?
[23:19:21] <Arfrever> javaJake: I fixed the original bug.
[23:19:27] <javaJake> Ah :)
[23:21:45] <Tommy[D]> zmedico: maybe a problem with resuming? i just started a bigger list of packages, then after the first compile error it found nothing to resume and stopped
[23:24:24] <Arfrever> zmedico: FYI: A=1 true ; echo $A
[23:24:26] <Arfrever> :)
[23:31:24] <zmedico> Tommy[D]: hmm, maybe so. there was a change in the resume code
[23:33:03] <zmedico> --resume still seems to work here though
[23:44:46] Gef` [n=g...@abo-76-63-68.mts.modulonet.fr] has quit IRC: Client Quit
### Log session terminated at 2009-08-07T00:00:00 ###
### Log session started at 2009-08-21T00:00:00 ###
[00:01:30] <zmedico> Arfrever: pong
[00:14:01] ABCD [n=a...@gentoo/contributor/abcd] has quit IRC: Read error: 104 (Connection reset by peer)
[00:14:15] ABCD [n=a...@gentoo/contributor/abcd] has joined #gentoo-portage
[00:21:11] <Arfrever> zmedico: Can I commit http://dpaste.com/83369/ ?
[00:23:22] <dleverton> Arfrever: unless you do so with the aid of your time machine, that's not going to convince anyone who didn't already agree with you
[00:25:06] <Arfrever> dleverton: I know that nothing will convince Ciaran etc.
[00:25:51] <dleverton> The most you can say after commiting that is that it's been intentional, documented behaviour as of 2009-08-20, and therefore it can be added to PMS for the next EAPI bump
[00:26:28] <Arfrever> dleverton: It was always intentional, but it was accidentally undocumented.
[00:27:36] <Arfrever> Today is 2009-08-21 :) .
[00:28:22] dma` [n=...@cpe-069-132-191-004.carolina.res.rr.com] has quit IRC: Read error: 110 (Connection timed out)
[00:28:50] <zmedico> Arfrever: looks good, thanks
[00:29:00] <Arfrever> zmedico: Thanks :) .
[00:31:20] mpagano [n=mpag...@gentoo/developer/mpagano] has quit IRC: "KVIrc Insomnia 4.0.0, revision: 3412, sources date: 20090703, built on: 2009/08/17 01:52:28 UTC http://www.kvirc.net/";
[00:32:33] <dleverton> The commit messages was "add an option to grab* so that if they're given a directory they'll recursively find all files in it and treat them like one big file. Also make use
[00:32:37] <dleverton> of this option for most of the config files."
[00:32:57] <dleverton> Doesn't sound like it was intentional to allow it in the tree to me
[00:33:00] <idl0r> zmedico: wrt VER_REGEX, any ideas how to use it in C? :) http://dpaste.com/83378/
[00:33:03] <dleverton> But of course, you already know that
[00:33:19] <idl0r> the example there doesn't match anything :(
[00:34:12] igli chuckles
[00:36:24] <zmedico> idl0r: I don't know, maybe there's some info in regex.h that will help you figure it out
[00:37:16] <zmedico>  /usr/include/regex.h
[00:37:32] <zmedico> says [:digit:] is supported
[00:38:11] <zmedico> idl0r: maybe you need some extra square brackets, like http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:digit:
[00:38:34] <zmedico> I didn't type that link
[00:38:45] <zmedico> I guess my irc client expanded it
[00:38:54] <zmedico> http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:digit:
[00:39:00] <zmedico> funky
[00:39:20] <zmedico> anyway, that's [:digit:]
[00:39:32] <zmedico> with two sets of [] brackets
[00:43:27] <idl0r> ah, thats it
[00:43:29] <idl0r> ty :)
[00:43:47] <zmedico> cool
[00:44:29] <idl0r> so: "^(cvs\\.)?([[:digit:]]+)((\\.[[:digit:]]+)*)([a-z]?)((_(pre|p|beta|alpha|rc)[[:digit:]]*)*)(-r([[:digit:]]+))?$"
[00:48:03] djanderson [n=djand...@hltncable.pioneerbroadband.net] has quit IRC: Read error: 110 (Connection timed out)
[00:51:13] <javaJake> Egad, what's that for?
[00:51:25] <javaJake> If you don't mind me asking
[00:51:51] <igli> (-r([[:digit:].]+)) # for prefix, so long as you're checking it
[00:52:23] <igli> (you have to check stuff in any event, ime)
[00:53:09] <igli> javaJake: match a CPV with one system call ;)
[00:53:22] <javaJake> Nice
[00:53:24] javaJake grabs
[00:53:24] <igli> well a few, but in general one.
[00:53:55] <igli> s/cvs/vcs ;)
[00:54:23] <igli> damn that's just version
[00:54:26] <igli> you can do whole CPV
[00:55:26] <igli> declare -r CPV='^((.*-.*)|virtual)/(.*)-(cvs\.)?([0-9]+)((\.[0-9]+)*)([a-z]?)((_(pre|p|beta|alpha|rc)[0-9]*)*)(-r([0-9.]+))?$'
[00:59:09] dma` [n=...@cpe-069-132-191-004.carolina.res.rr.com] has joined #gentoo-portage
[01:11:56] <javaJake> From an ebuild, how do I detect whether or not I'm running on an OSX system?
[01:12:11] <javaJake> I'm running on a prefix'ed system, if that matters. (Shouldn't. :)
[01:13:19] <zmedico> javaJake: use kernel_Darwin
[01:14:12] <javaJake> ...which is not set on my system.
[01:14:17] <javaJake> Prefix must matter, then :/
[01:15:12] <zmedico> what is KERNEL set to?
[01:15:31] <zmedico> that should USE_EXPAND to kernel_$KERNEL
[01:15:43] <javaJake> Not set
[01:15:52] <javaJake> According to emerge --info and env
[01:16:03] <zmedico> you're looking in the wrong place
[01:16:11] <zmedico> try `portageq envvar KERNEL`
[01:16:18] <zmedico> it should be set in the profile
[01:16:26] <javaJake> Darwin :)
[01:16:32] <zmedico> cool
[01:29:17] gargoyle-grin [n=rande...@gentoo/contributor/gargoyle-grin] has quit IRC: "Leaving."
[01:30:32] <Arfrever> Calchan: Nothing needs to be reverted.
[02:13:48] ferringb_ [n=ferri...@c-24-130-139-50.hsd1.ca.comcast.net] has joined #gentoo-portage
[02:18:47] Obeliks [i=obel...@gentoo/contributor/Obeliks] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:47] chithead [n=chith...@gentoo/user/chithead] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] jmbsvicetto [i=jmbsv...@gentoo/developer/jmbsvicetto] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] Willikins [i=nob...@gentoo/bot/Willikins] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] spb [i=step...@freenode/developer/exherbo.spb] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] r0bertz [n=zhan...@gentoo/developer/r0bertz] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:50] krushia [n=krus...@pool-71-168-96-174.cncdnh.east.myfairpoint.net] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:50] tanderson [n=gento...@gentoo/developer/gentoofan23] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:19:53] jmbsvicetto [i=jmbsv...@gentoo/developer/jmbsvicetto] has joined #gentoo-portage
[02:19:53] Willikins [i=nob...@gentoo/bot/Willikins] has joined #gentoo-portage
[02:19:53] spb [i=step...@freenode/developer/exherbo.spb] has joined #gentoo-portage
[02:19:53] r0bertz [n=zhan...@gentoo/developer/r0bertz] has joined #gentoo-portage
[02:19:53] krushia [n=krus...@pool-71-168-96-174.cncdnh.east.myfairpoint.net] has joined #gentoo-portage
[02:19:53] tanderson [n=gento...@gentoo/developer/gentoofan23] has joined #gentoo-portage
[02:25:29] ferringb [n=ferri...@c-24-130-139-50.hsd1.ca.comcast.net] has quit IRC: Nick collision from services.
[02:25:30] ferringb_ [n=ferri...@c-24-130-139-50.hsd1.ca.comcast.net] is now known as ferringb
[02:40:58] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has joined #gentoo-portage
[02:41:21] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has quit IRC: Remote closed the connection
[02:42:43] mpagano [n=mpag...@gentoo/developer/mpagano] has joined #gentoo-portage
[03:33:24] mpagano [n=mpag...@gentoo/developer/mpagano] has quit IRC: "cya"
[04:46:44] reavertm_ [n=reave...@bdl237.neoplus.adsl.tpnet.pl] has joined #gentoo-portage
[04:49:20] reavertm [n=reave...@gentoo/contributor/reavertm] has quit IRC: Read error: 60 (Operation timed out)
[04:50:12] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has joined #gentoo-portage
[04:50:12] Obeliks [i=obel...@who.knows.what.possessed.us] has joined #gentoo-portage
[04:50:12] chithead [n=chith...@gentoo/user/chithead] has joined #gentoo-portage
[04:54:52] zong_sharo [n=weec...@92.53.109.174] has quit IRC: "WeeChat 0.2.6.2"
[05:05:12] zong_sharo [n=weec...@92.53.109.174] has joined #gentoo-portage
[05:14:34] javaJake [n=javaj...@unaffiliated/javajake] has quit IRC: "night"
[05:14:52] smorg [n=quas...@97-116-4-14.mpls.qwest.net] has quit IRC: Remote closed the connection
[05:23:39] djanderson [n=djand...@hltncable.pioneerbroadband.net] has joined #gentoo-portage
[05:52:02] |t4bz| [n=tre...@ppp121-45-169-216.lns11.adl2.internode.on.net] has joined #gentoo-portage
[06:13:48] t4bz [n=tre...@ppp121-45-39-202.lns10.adl2.internode.on.net] has quit IRC: Read error: 101 (Network is unreachable)
[06:14:40] igli [n=i...@fu/coder/igli] has quit IRC: Remote closed the connection
[06:33:57] reavertm_ [n=reave...@bdl237.neoplus.adsl.tpnet.pl] has quit IRC: Remote closed the connection
[06:44:58] djanderson [n=djand...@hltncable.pioneerbroadband.net] has quit IRC: Client Quit
[07:17:31] slonopotamus [n=slono...@83.149.10.180] has joined #gentoo-portage
[07:40:54] few [n=...@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[08:22:17] slonopotamus_ [n=slono...@83.149.9.36] has joined #gentoo-portage
[08:30:51] Masa [n=sfmas...@12.186.21.238] has joined #gentoo-portage
[08:31:23] Masa [n=sfmas...@12.186.21.238] has left #gentoo-portage: "Leaving"
[08:40:35] slonopotamus [n=slono...@83.149.10.180] has quit IRC: Read error: 110 (Connection timed out)
[08:58:38] rafaelmartins [n=raf...@unaffiliated/rafaelmartins/x-162351] has quit IRC: Remote closed the connection
[09:08:10] wired_ [n=wi...@musici.static.otenet.gr] has joined #gentoo-portage
[09:45:41] wired_ [n=wi...@gentoo/developer/wired] is now known as wired
[09:52:04] wired [n=wi...@gentoo/developer/wired] has quit IRC: "ZNC - http://znc.sourceforge.net";
[09:57:04] slonopotamus_ [n=slono...@83.149.9.36] has quit IRC: Connection timed out
[09:57:15] wired_ [n=wi...@musici.static.otenet.gr] has joined #gentoo-portage
[10:04:20] wired_ [n=wi...@gentoo/developer/wired] is now known as wired
[10:06:38] wired [n=wi...@gentoo/developer/wired] has quit IRC: "ZNC - http://znc.sourceforge.net";
[10:07:11] wired_ [n=wi...@gentoo/developer/wired] has joined #gentoo-portage
[10:11:39] wired_ [n=wi...@gentoo/developer/wired] is now known as wired
[10:24:56] Tommy[D] [i=...@gateway/gpg-tor/key-0x35899067] has joined #gentoo-portage
[11:55:05] hkBst [n=hk...@gentoo/developer/hkbst] has joined #gentoo-portage
[12:36:15] smorg [n=quas...@97-116-4-14.mpls.qwest.net] has joined #gentoo-portage
[13:17:46] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: "No Ping reply in 90 seconds."
[13:18:20] scarabeus [n=sca...@gentoo/developer/scarabeus] has joined #gentoo-portage
[14:38:55] reavertm [n=reave...@bdl237.neoplus.adsl.tpnet.pl] has joined #gentoo-portage
[15:34:53] slonopotamus [n=slono...@83.149.10.134] has joined #gentoo-portage
[15:38:06] few [n=...@port-ip-213-211-233-28.reverse.mdcc-fun.de] has quit IRC: Read error: 110 (Connection timed out)
[15:56:07] PSYCHO___ [n=sca...@gentoo/developer/scarabeus] has joined #gentoo-portage
[16:08:25] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: Read error: 110 (Connection timed out)
[16:09:13] PSYCHO___ [n=sca...@gentoo/developer/scarabeus] is now known as scarabeus
[16:11:15] few [n=...@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[16:38:43] gargoyle-grin [n=rande...@gentoo/contributor/gargoyle-grin] has joined #gentoo-portage
[17:04:09] CCIEChad|Away [i=cciec...@ip72-209-20-27.ri.ri.cox.net] has joined #gentoo-portage
[17:05:32] CCIEChad [i=cciec...@gentoo/contributor/cciechad] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] mpagano_ [n=m...@gentoo/developer/mpagano] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] peper [n=pe...@gentoo/developer/paludis.lackey.peper] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] sungami [n=sung...@unaffiliated/sungami] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] alip [i=a...@unaffiliated/alip] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] keytoaster [n=tob...@gentoo/developer/keytoaster] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] puggy [n=pu...@ngsrvm01.ediamond.ox.ac.uk] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:06:02] keytoaster [n=tob...@gentoo/developer/keytoaster] has joined #gentoo-portage
[17:06:02] alip [i=a...@unaffiliated/alip] has joined #gentoo-portage
[17:06:02] sungami [n=sung...@unaffiliated/sungami] has joined #gentoo-portage
[17:06:02] puggy [n=pu...@ngsrvm01.ediamond.ox.ac.uk] has joined #gentoo-portage
[17:06:02] mpagano_ [n=m...@gentoo/developer/mpagano] has joined #gentoo-portage
[17:06:11] sungami [n=sung...@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[17:06:11] sungami [n=sung...@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[17:06:24] keytoaster [n=tob...@gentoo/developer/keytoaster] has quit IRC: SendQ exceeded
[17:06:50] peper [n=pe...@gentoo/developer/paludis.lackey.peper] has joined #gentoo-portage
[17:07:06] sping_ [n=sp...@e179002115.adsl.alicedsl.de] has joined #gentoo-portage
[17:07:39] keytoaster [n=tob...@gentoo/developer/keytoaster] has joined #gentoo-portage
[17:10:14] slonopotamus [n=slono...@83.149.10.134] has quit IRC: "Leaving"
[17:10:37] ABCD_ [n=a...@gentoo/contributor/abcd] has joined #gentoo-portage
[17:11:52] sungami_ [n=sung...@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[17:12:13] Sput [n=sputn...@quassel/developer/sput] has quit IRC: Broken pipe
[17:12:33] <reavertm> Arfrever: you added 'file or dirs' in manual section of /etc/make.profile - is the right place?
[17:12:35] sungami [n=sung...@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[17:12:57] Sput [n=sputn...@quassel/developer/sput] has joined #gentoo-portage
[17:14:10] <reavertm> (portage manual in svn)
[17:27:43] ABCD [n=a...@gentoo/contributor/abcd] has quit IRC: Success
[17:34:55] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has quit IRC: Read error: 113 (No route to host)
[17:46:09] kallamej [n=kalla...@gentoo/developer/kallamej] has quit IRC: "brb"
[18:11:02] sping_ [n=sp...@gentoo/user/sping] has quit IRC: Remote closed the connection
[18:11:34] r0bertz [n=zhan...@gentoo/developer/r0bertz] has quit IRC: Read error: 131 (Connection reset by peer)
[18:13:02] <Arfrever> reavertm: The /etc/make.profile/ section describes files supported in directories of profiles.
[18:13:13] r0bertz [n=zhan...@gentoo/developer/r0bertz] has joined #gentoo-portage
[18:15:47] <Arfrever> reavertm: /etc/make.profile is usually a symlink to appropriate profile in ${PORTDIR}/profiles.
[18:17:42] <Tommy[D]> Arfrever: it can also be a dir containing a parents file ;)
[18:19:46] mitsutaka [n=mitsu...@ns1.miraclelinux.com] has joined #gentoo-portage
[18:22:11] dma` [n=...@cpe-069-132-191-004.carolina.res.rr.com] has quit IRC: Read error: 60 (Operation timed out)
[18:28:02] AmazingPudding [i=dreee...@gentoo/developer/bonsaikitten] is now known as DrEeevil
[18:32:02] <reavertm> I'd rather add explicit info for manual entry regarding every package.* or use.* (wherever it really applies) in profile and  /etc/portage sections
[18:32:22] <reavertm> just to avoid confusion what's 'file or dir' and what's not
[18:45:55] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: Remote closed the connection
[18:46:04] pva [n=...@gentoo/developer/pva] has joined #gentoo-portage
[18:52:42] scarabeus [n=sca...@gentoo/developer/scarabeus] has joined #gentoo-portage
[19:09:42] sping_ [n=sp...@gentoo/user/sping] has joined #gentoo-portage
[19:26:18] few [n=...@port-ip-213-211-233-28.reverse.mdcc-fun.de] has quit IRC: "Verlassend"
[19:33:30] slonopotamus [n=slono...@80.90.124.131] has joined #gentoo-portage
[19:44:01] <darkside_> Arfrever: concerning your recent commit. can you please modify it like so: http://dpaste.com/83664/ ?
[19:54:38] <Arfrever> darkside_: Yes.
[19:56:05] <reavertm> http://dpaste.com/83668/ - stable portage segfaulted here (during rebuilding of some random kde package), strange...
[19:56:22] <reavertm> sorry, it's 2.2_rc38, not stable (but stable python)
[20:00:44] <Arfrever> darkside_: r14116.
[20:02:41] <darkside_> ty
[20:12:22] rafaelmartins [n=raf...@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[20:14:38] sungami_ [n=sung...@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[20:15:43] sungami [n=sung...@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[20:33:05] Polynomial-C [n=pol...@gentoo/developer/Polynomial-C] has joined #gentoo-portage
[20:59:39] CCIEChad|Away [i=cciec...@gentoo/contributor/cciechad] has quit IRC: Read error: 104 (Connection reset by peer)
[21:00:49] CCIEChad [i=cciec...@ip72-209-20-27.ri.ri.cox.net] has joined #gentoo-portage
[21:06:54] <CCIEChad> does anyone know when the next rc release of 2.2 is expected?
[21:08:21] <Arfrever> CCIEChad: Maybe zmedico :) .
[21:11:00] <CCIEChad> just curious I'm using SVN on my dev machine and the improvement in the handling of error messages and dep handling on svn are amazing. I have converted some windows users to gentoo who run ~portage but I didn't want to have to get them on SVN portage
[21:13:00] <CCIEChad> you guys have been doing great work I haven't tested but I swear it even seems faster
[21:24:35] slonopotamus [n=slono...@80.90.124.131] has quit IRC: "Leaving"
[21:34:45] slonopotamus [n=slono...@80.90.124.131] has joined #gentoo-portage
[21:34:51] <zmedico> CCIEChad: I'm releaseing 2.2_rc39 today
[21:35:28] <CCIEChad> zmedico: great thank you man
[21:35:40] <zmedico> you're welcome
[21:40:22] <tanderson> zmedico: ooh, does that have the controversial patch in it?
[21:41:05] <Arfrever> tanderson: It's not controversial for majority of people.
[21:41:23] <tanderson> Arfrever: having a majority doesn't make it controversial.
[21:41:31] <tanderson> Arfrever: is it in there is my question.
[21:41:46] <tanderson> besides, we don't know how many people feel one way or the other about it
[21:42:39] <reavertm> what's controversial?updating manual?
[21:43:05] <Arfrever> tanderson: Many people would object to reverting this change, so it probably won't be reverted (at least soon).
[21:43:13] <tanderson> reavertm: updating the portage docs.
[21:44:08] <tanderson> Arfrever: sure. Portage can support that and it's documentation should be accurate to what it does.
[21:44:35] <Arfrever> And now documentation is more accurate than it was earlier.
[21:44:49] <tanderson> But we shouldn't be modifying pms to every portage change because we need a little procedure or EAPI is useless
[21:44:55] <tanderson> zmedico: can I query btw?
[21:44:59] <zmedico> tanderson: I was planning to add a note saying that it's not part of the PMS spec
[21:45:05] <tanderson> zmedico: ok
[21:45:32] <zmedico> tanderson: yeah, query is fine any time
[21:46:36] <Arfrever> tanderson: This feature started to exist before EAPI=0 was introduced. PMS developers haven't included this feature in PMS due to accidental lack of mentioning this feature in Portage documentation.
[21:49:47] <Arfrever> tanderson: AFAIK documentation of EAPI=0 has been already changed after Council approved EAPI=0.
[21:50:31] <dleverton> Arfrever: my reading of the logs says that it was introduced a couple of months after EAPI 0, but that's not the main point
[21:50:47] tanderson [n=gento...@gentoo/developer/gentoofan23] has quit IRC: "Lost terminal"
[21:51:05] gentoofan23 [n=gento...@gentoo/developer/gentoofan23] has joined #gentoo-portage
[21:51:13] <dleverton> The spec has been mostly-approved, so while it's not completely frozen, it seems unfair to make changes like this that would badly break existing code that was written to the spec
[21:51:30] gentoofan23 [n=gento...@gentoo/developer/gentoofan23] is now known as tanderson
[21:51:49] <dleverton> Even assuming the omission from the docs originally was purely an accident, people have still written code based on what was actually documented
[21:52:17] <zmedico> it's the community's decision
[21:52:34] <zmedico> if the consensus is that it's worth changing, then it's changing
[21:52:38] <zmedico> if not, it's not
[21:52:42] <zmedico> that simple :)
[21:53:10] <jmbsvicetto> dleverton: one point that is worthy to consider (and please don't take it as any kind of attack to PMS) is that there has yet to be a final approval by the Council of the doc - at least as far as I can remember
[21:53:12] <reavertm> features adoption should be through controlled process (PMS), but in this case I thing it's beneficial to push through
[21:54:28] <Arfrever> dleverton: As jmbsvicetto said, this feature was introduced many months before EAPI=0 will be finally approved :) .
[21:55:08] <dleverton> Not the point
[21:55:59] <dleverton> EAPI 0 isn't absolutely frozen, purely because it's not realistic to expect a 100% perfect spec to be written retroactively, and therefore it's likely that there will be the need for small changes for a long time
[21:56:09] hays__ [n=h...@unaffiliated/hays] has joined #gentoo-portage
[21:56:11] <dleverton> But that doesn't mean it's OK to add big new features like that
[21:56:35] <Arfrever> dleverton: It's a small, old feature :) .
[21:56:56] <dleverton> By that argument, you could say that use deps were introduced before EAPI 0 is finally approved, therefore EAPI 0 should have use deps
[21:57:14] <dleverton> It's big in the sense that code written to the current spec will break badly
[21:57:54] <dleverton> And as for "old", all the documentation until recently said that it was only for use in config files.  Even if that was just an oversight, it's hardly fair to penalise people who wrote code assuming the docs were correct
[21:58:43] <zmedico> all is fair in love and war :)
[21:59:02] dleverton wishes certain people wouldn't keep treating this like a war....
[21:59:35] <dleverton> (Not anyone in this discussion, I don't think)
[22:00:14] <reavertm> dleverton: you certainly have some reusable class in paludis code and it should not be *very* hard to implement it just right away and get over with
[22:00:51] <dleverton> It wouldn't be hard to add it to a new EAPI either, and use a magic infra script to handle it until the main profiles/ can use the new EAPI
[22:00:53] <reavertm> besides I doubt it would be introduced in tree immediately
[22:01:00] <tanderson> I personally like a slow conversion where you put the actual support in PMS for EAPI 4 (or we could even rush it into EAPI 3 as that's a ways off) and then have an infra script
[22:02:24] <dleverton> That sounds like the best idea to me, too
[22:02:41] dacook [n=sch...@fw0nk.net] has quit IRC: "leaving"
[22:03:10] <tanderson> dleverton: given that EAPI 3 still isn't coming out for awhile, do you see anything against putting such a thing in EAPI 3 ?
[22:03:18] <tanderson> It's not that much of a change admittedly
[22:03:31] <dleverton> Sounds fine
[22:03:53] <Arfrever> tanderson: ciaranm likes slow conversations only when he likes given idea. ciaranm (after notification probably from dleverton) recently drastically changed definition of nonfatal() in PMS without agreement of developers of other package managers.
[22:03:57] <dleverton> Some people won't be too happy if it's opened up for new features in general, but just this one should be OK
[22:04:31] <dleverton> Arfrever: that was just clarifying the wording, not a "drastic change"
[22:04:40] <tanderson> Arfrever: can I have a link to the pms commit please?
[22:04:48] <dleverton> And you had the chance to disagree on the mailing list
[22:05:02] <Arfrever> dleverton: There was no agreement that it was clarification.
[22:05:25] <Arfrever> dleverton: I wasn't subscribed to that mailing list, when he posted that patch.
[22:05:36] <Arfrever> (I subscribed some time later.)
[22:06:16] <Arfrever> dleverton: Anyway such drastic change should be first discussed on gentoo-dev mailing list, which has more interested subscribers.
[22:06:49] <dleverton> Feel free to bring it up if you think the other behaviour is better
[22:06:55] <dleverton> There are arguments both ways
[22:07:08] <tanderson> Doesn't look like a drastic change to me fwiw
[22:07:28] <tanderson> Noone on the gentoo pms team had a problem with it either
[22:08:10] <Arfrever> It disallows to usefully use nonfatal() with functions from eclasses without modifying these functions.
[22:08:21] <Arfrever> tanderson: ciaranm didn't explain consequences.
[22:08:57] <dleverton> It's debatable whether we want to change the behaviour of existing eclass functions without modifying them
[22:09:23] <reavertm> if that commit changes expected behaviour, then should be reverted
[22:09:30] <dleverton> For example, if a function dies as the non-last statement, nonfatal won't cause it to return an error, it'll just proceed with the rest of the function
[22:10:26] <dleverton> reavertm: depends who's doing the expecting
[22:11:13] <reavertm> indeed
[22:14:27] <reavertm> and that's the problem
[22:15:04] <Arfrever> tanderson: See http://dpaste.com/83744/
[22:15:28] <tanderson> found it already, thanks though
[22:15:44] <Arfrever> ciaranm posted the patch about 15-20 minutes after discussion about nonfatal() began.
[22:15:57] pva [n=...@gentoo/developer/pva] has quit IRC: Read error: 60 (Operation timed out)
[22:17:55] <Arfrever> Anyway my point is that ciaranm, dleverton etc. are unfair in PMS development.
[22:19:02] <dleverton> You had the chance to object (even if you couldn't reply directly to the original mail, no-one would have objected if you'd started a new thread with an explanation of why)
[22:19:11] <dleverton> Anyway, I'm going to raise the issue on -dev@
[22:19:23] <zmedico> Arfrever: btw, what does the DT stand for in those QA_* variables?
[22:20:05] <zmedico> (and thanks for doing that stuff)
[22:21:30] <Arfrever> AFAIK .dynamic tag (i.e. a tag in .dynamic section)
[22:22:23] <zmedico> ah, ok. thanks
[22:22:38] <Arfrever> dleverton: I was planning to raise this issue on gentoo-dev mailing list, but I was busy with other things :) .
[22:23:10] <dleverton> Arfrever: OK
[22:25:34] <zmedico> Arfrever: comparing the QA_PRESTRIPPED to the QA_SONAME code, do we need to add a sed -e "/^\$/d" to removed empty lines in the QA_SONAME code?
[22:25:38] <Arfrever> dleverton: Do you still plan to raise this issue on gentoo-dev mailing list, or will you give me some time to write an e-mail about it?
[22:26:05] <dleverton> Arfrever: I was just writing up a mail now, I'll let you see it before I send it, in case there's anything you think is horribly wrong
[22:26:43] <Arfrever> dleverton: Behavior desired by you will be probably horribly wrong :) .
[22:27:14] <dleverton> :-P
[22:27:16] <dleverton> We'll see
[22:27:47] <Arfrever> dleverton: Please attach IRC logs.
[22:28:01] <Arfrever> (With mentioned timezone.)
[22:28:12] <dleverton> Arfrever: I intended the mail to be purely about the merits of the different possible behaviours
[22:28:31] <Arfrever> dleverton: My IRC log is in UTC+2.
[22:28:36] <zmedico> Arfrever: nevermind that last question, I see that it doesn't matter
[22:29:22] <zmedico> QA_PRESTRIPPED uses [[ -s $log ]]
[22:29:32] <zmedico> and that's the difference
[22:29:38] Zoolooc [n=freds...@p549526a4.dip0.t-ipconnect.de] has joined #gentoo-portage
[22:33:32] <Arfrever> zmedico: I think that sed -e "/^\$/d" should be added to QA_{SONAME,DT_NEEDED} to avoid potential empty lines between files in eqawarn message.
[22:33:48] <zmedico> oh, good idea
[22:40:12] <dleverton> Arfrever, anyone else who cares: http://dpaste.com/83757/
[22:40:43] rafael_martins [n=raf...@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[22:42:15] <Arfrever> dleverton: 'die --force' is a good idea.
[22:42:40] <dleverton> Yeah, that's a possibility, I'll add that too
[22:43:51] <reavertm> I don't see any use case for nonfatal
[22:44:47] <reavertm> if someone wants to "nonfatal <sth>" then probably <sth> should not die itself (and if it does, then it should be fixed)
[22:44:56] <dleverton> reavertm: I think the main thing is just to die with a more informative message than the default, but there are other possibilities
[22:45:41] kallamej [n=kalla...@gentoo/developer/kallamej] has joined #gentoo-portage
[22:45:44] <dleverton> Arfrever: http://dpaste.com/83762/
[22:45:47] <Arfrever> dleverton: The only problem which would happen if eclasses aren't modified to support die() from older EAPIs is that die message would include "--force" prepended. New versions of package managers can silently ignore --force in older EAPIs.
[22:46:44] reavertm just waiting to options like --force, --really-force, --no,seriously-really-force-this-time,seriously..
[22:47:01] <Arfrever> dleverton: "--force building failed" isn't too ugly :) .
[22:47:34] <dleverton> It's not terribly, but it would be a bit messy to see it frequently
[22:47:38] <dleverton> *terrible
[22:48:08] <Arfrever> New versions of package managers wouldn't print --force even in older EAPIs.
[22:48:21] <dleverton> Possibly
[22:48:54] <Arfrever> dleverton: DIE_FORCE=1 die "building failed" would avoid this problem :) .
[22:49:07] <dleverton> That could work
[22:50:17] <reavertm> nonfatal shoo || DIE_FORCE=1 die "building failed"
[22:50:31] <reavertm> seriously you want to allow that?
[22:51:01] <Arfrever> dleverton: Please consider changing that example to: cd foo || DIE_FORCE=1 die "cd failed"
[22:52:52] <dleverton> Arfrever: http://dpaste.com/83767/
[22:53:53] rafaelmartins [n=raf...@unaffiliated/rafaelmartins/x-162351] has quit IRC: Read error: 110 (Connection timed out)
[22:53:59] mpagano [n=mpag...@gentoo/developer/mpagano] has joined #gentoo-portage
[22:54:08] <Arfrever> dleverton: OK. Please send it.
[22:55:23] rafael_martins [n=raf...@unaffiliated/rafaelmartins/x-162351] has quit IRC: "http://gentoo-br.net";
[22:56:36] rafaelmartins [n=raf...@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[22:59:13] <dleverton> Arfrever: sent, thanks for the feedback
[22:59:31] slonopotamus [n=slono...@80.90.124.131] has quit IRC: Read error: 104 (Connection reset by peer)
[23:05:12] slonopotamus [n=slono...@80.90.124.131] has joined #gentoo-portage
[23:42:15] zmedico [n=zmed...@gentoo/developer/zmedico] has quit IRC: Remote closed the connection
[23:46:59] zmedico [n=zmed...@gentoo/developer/zmedico] has joined #gentoo-portage
[23:58:15] dma` [n=...@cpe-069-132-191-004.carolina.res.rr.com] has joined #gentoo-portage
### Log session terminated at 2009-08-22T00:00:00 ###

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to