Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
El sáb, 29-09-2012 a las 22:34 +0200, Michał Górny escribió: On Sat, 29 Sep 2012 21:20:00 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió: On Sat, 29 Sep 2012 17:45:07 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: There isn't so much a problem with the current python-distutils-ng eclass but rather it's to expand it to a more comprehensive replacement for both distutils and python eclasses. In order to do that efficiently, most of the core functionality should be moved so that the new distutils is more like a wrapper to the new python. This could certainly be done by patching the existing eclass, but mgorny wants to use new eclass names instead of keeping the current one. Hence the rename. I think that's about it.. In that case we are missing 95% of the features of python.eclass. Please list the features. Preferably, order them by usefulness, with exact use cases. Personally, I usually run: - python_clean_py-compile_files - Clean py-compile files to disable byte-compilation allowing us to drop all various ways of doing this that were living in the tree some time ago. Hmm, what's the problem with compiling them? Do you mean some case when the results of the compilation are different from the way done by the eclass? Well, if I don't misremember, we currently prefer to compile them at postinst phase instead of during src_compile, but maybe this is no longer needed (no idea :( ) - python_convert_shebangs - but, I guess this is handled in a different way in your eclass, no? :/ Depends on what you need. To be honest, I haven't added any code for custom script handling yet, just the usual distutils case. A package which does not explicitly support multiple Python implementations is a completely different things, needing more discussion first and which actually may be handled through a separate eclass if most code of python-r1 proves useless for it. I was thinking on a lot of packages still being only compatible with python2... I guess will need to still use python.eclass for them then signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?
Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
El dom, 30-09-2012 a las 10:58 +0200, Fabian Groffen escribió:
On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?
Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
Then, I guess having such function would still be useful :) Thanks for
the info
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen grob...@gentoo.org wrote:
On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?
Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
Hmm, so python-distutils-ng was wrong from the beginning and nobody
cared to point it out?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On 30-09-2012 15:28:47 +0200, Michał Górny wrote:
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
Hmm, so python-distutils-ng was wrong from the beginning and nobody
cared to point it out?
I'm not reviewing each and everything in detail, sorry. It's just
that Pacho raised the point in this thread that made me recall the
above.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen grob...@gentoo.org wrote:
On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?
Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
I'm afraid you are wrong here.
I've just tested an ebuild using distutils (flaggie) and autotools
(pygobject) and both install .pyc files with correct paths (i.e. with
DESTDIR stripped).
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On Sat, 29 Sep 2012 22:48:00 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 08:39 PM, Michał Górny wrote: On Sat, 29 Sep 2012 16:37:15 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Sat, Sep 29, 2012 at 4:26 PM, hasufell hasuf...@gentoo.org wrote: That still does not explain the reasons why this work was initiated. If there is any way to fix the current eclass, that should be preferred. I tend to agree. Michał, let me first say I value the time you have invested to make the eclasses better. However, at this point I have a strong feeling that we have more people willing to write code to fix things than we have people building consensus on what features/policies/mechanisms we need to make it easy to write high-quality ebuilds for Python/distutils. I would prefer discussions on problems that the current ebuilds have and discussions on how to solve them, not at the code level, but that the mechanism level. The main issue: noone wants to even touch python.eclass or anything nearby. The second issue: python-distutils-ng isn't good enough. It has too many things hard-wired. I think I have already pointed enough problems with it. Not that many people cared to respond. It's sad that people don't care to respond when you point the issues out but then complain when you do something to fix them. Did you CC gentoo-dev? I cannot find the tread. Maybe. People interested in Python should be either on the Python ml or on the python@ alias, I believe. [example needed] ?? I meant that not all tree ebuilds use the same python-eclass implementation which IS a problem. Adding another implementation does not really improve that situation. As long as they can inter-operate correctly, I don't see any problem. Please list the features. Preferably, order them by usefulness, with exact use cases. As I said, I think the python herd already did a list on this. Btw. could you give exact examples on how to convert widely used python ebuilds with your eclasses? E.g. dev-python/pygobject dev-python/setuptools or dev-libs/boost? I have prepared and tested an ebuild for pygobject and setuptools here: http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=tree;f=dev-python;h=557b96c041bb6da969574dd75dcdfd4022ba636b;hb=refs/heads/python-r1 I will take a look at boost a while later, since I have to have much more time to compile it :P. How can I convert shebangs consistently and recursively? Converting shebangs applies to packages supporting multiple Python implementations or those not doing so? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
I'm on the list, obviously, so PLEASE stop Cc-ing me!
On 30-09-2012 15:57:16 +0200, Michał Górny wrote:
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me). In the worst
case it returns Bad marshalling data.
I'm afraid you are wrong here.
I've just tested an ebuild using distutils (flaggie) and autotools
(pygobject) and both install .pyc files with correct paths (i.e. with
DESTDIR stripped).
Could be, if it uses relative paths, but they won't be absolute then
either. From some experiments I did, I saw Python ignoring wrong paths
(entire cache?), or updating the pyc/pyo files. Regardless whether or
not the data is wrong, the discussion is more if it hurts (and makes
sense).
Back then, we found it hurt us (Bad marshalling data) when using
binpkgs. Not sure if it still does today with Python 2.7. Somehow we
reached a consensus with the Python maintainer at that time that cache
stuff shouldn't be in VDB, also because it depends on system and perhaps
Python version. Since embedded systems might not even want it (it's
just cache afterall, wasting their sometimes precious disk space), it
had to be out of the package contents for them as well.
That's how we came to the situation as it was before python eclass
rewrites. I'd much prefer Python to write its cache to some
/var/cache/python dir so it can create whatever it wants, but on a
place which is not of any concern, as its obvious one can throw it away,
and doesn't pollute the live fs. But Python doesn't work that way.
Whatever the new way will be, for whatever reason, please make sure it
is consistent. And be aware that this doesn't just mean changing
eclasses, since this rule is effectuated in certain ebuilds too
(dev-lang/python itself being the most obvious example).
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] making USE=upnp a global flag
Le mercredi 19 septembre 2012 à 10:19 +0200, Michał Górny a écrit : Just to make it clear: - USE=upnp for upnp-igd or nat-pmp, - USE=dlna for the video magic and so on. Do I understand correctly? No, TV makers and others advertise UPnP as DLNA (digital living network appliance) but that actually refers to both port forwarding (eg. used in consoles) and to media streaming (eg. PC to TV). Both flags should most likely start with dlna, then we need to figure out a suffix :) I propose dlna-av and dlna-network. See [1] if somebody else feels inspired. [1] http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance#DLNA_technology_components -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] making USE=upnp a global flag
On Sun, Sep 30, 2012 at 11:44 AM, Gilles Dartiguelongue e...@gentoo.org wrote: Le mercredi 19 septembre 2012 à 10:19 +0200, Michał Górny a écrit : Just to make it clear: - USE=upnp for upnp-igd or nat-pmp, - USE=dlna for the video magic and so on. Do I understand correctly? No, TV makers and others advertise UPnP as DLNA (digital living network appliance) but that actually refers to both port forwarding (eg. used in consoles) and to media streaming (eg. PC to TV). Both flags should most likely start with dlna, then we need to figure out a suffix :) I propose dlna-av and dlna-network. See [1] if somebody else feels inspired. [1] http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance#DLNA_technology_components -- Gilles Dartiguelongue e...@gentoo.org Gentoo Personally, I would prefer that the USE flags be named for the protocol/feature they enable (upnp-foo) rather than the organization that certifies devices (dlna-foo). Maybe I'm over-simplifying.
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On 09/30/2012 07:12 AM, Fabian Groffen wrote: Back then, we found it hurt us (Bad marshalling data) when using binpkgs. Not sure if it still does today with Python 2.7. Somehow we reached a consensus with the Python maintainer at that time that cache stuff shouldn't be in VDB, also because it depends on system and perhaps Python version. Since embedded systems might not even want it (it's just cache afterall, wasting their sometimes precious disk space), it had to be out of the package contents for them as well. They can use INSTALL_MASK=*.py[co] if they need to. In portage we have a default COLLISION_IGNORE=*.py[co] setting, so that there are no related issues with file collisions for *.py[co] if the user removes the INSTALL_MASK setting later. -- Thanks, Zac
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sat, Sep 29, 2012 at 05:05:09PM +0100, Ciaran McCreesh wrote: On Tue, 25 Sep 2012 15:46:14 -0700 Brian Harring ferri...@gmail.com wrote: Fun fact; peoples usage of labels in exherbo is thus: build+run: set of deps run: set of deps/conditionals/etc That's largely because there are a lot of former Gentoo developers there who all said oh, yeah, I forgot we could do it the other way when this was pointed out... I analyzed *all* exheres on git.exherbo. To be crystal clear, these include your packages. You yourself didn't use nested labels. So either the author of labels 'forgot' he could use it, or just didn't find the nesting actually useful. Considering I've not found any examples where nesting /would/ be useful, I'm inclined to agree w/ y'alls usage- that nesting doesn't matter. So... real world usage removes one of the core arguments of labels, leaving it just as it's a new syntax/aesthetically more pleasing in comparison to dep:build? ( blah ) form. Not expecting you'll agree with that statement based on the facts of y'alls own repo... so if you're going to retort, bust out actual examples from eithe trees, where nesting would be preferable to the form people use now please; else just drop it (-your- own usage of labels disproves your claim; thus why I want actual examples now if that point will be debated any further). Specification in terms of rendering has a huge problem, though. Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does this do? || ( dep:build? ( a ) dep:run? ( b ) ) Honestly, I was waiting for you to bring this up :) You're conflating two different things here; 1) someone being a dumb ass and writing what's effectively a || ( atom) block, just doing so in a manner w/out any reason to do so. 2) Your ongoing jihad against || (), specifically the occasionally valid complaint that build/rdepend different means the resolver can get stuck in certain pathways when slots are involved, abi, etc. Either way, in my proposal, I'm not going to single that out and try blocking it. The rendered version of it is still stable, albeit if it's build/run it's unlikely to be desired if there is ABI involved (for non ABI, specifically self-bootstrapping codebases, I suspect someone could come up with a valid construct- sed has something similar if memory serves). The rendered version ends up as ( a b ), in effect... It doesn't end up as || ( a (at build time) b (at runtime) ). Er, I assume you left out some chars there. The rendered version there isn't ( a b ); in old form it is: DEPEND=|| ( a ) RDEPEND=|| ( b ) This is why I label it a stupid use of syntax, but not ultimately harmful. Which is stupid, but syntactically correct. Nor is this a new issue, thus I don't particularly agree with your approach of trying to sink the proposal via an orthogonal problem. No, you're introducing a new kind of weirdness for || ( ) here. Na uh, you're the smelly face! As I said, and via correcting your misrendering, this isn't introducing anything truly new here; people can/have done '|| ( a )'; it's a stupid construct, and for paludis it means it /does/ treat that as an OR block (for hte rest, we do the more obvious tree collapses during parsing, folding a ( b ) down into a b, same for a || ( b ) into a b since they're the same thing). Either way, via http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt , I think it's pretty clear labels in real world usage aren't bringing anything to the tabel that we wouldn't have via my proposal; that leaves labels as just a different syntax (perhaps aesthetically more pleasing at first glance, but the label stacking bit via exheres analysis is proven to be something people explicitly go out of their way to protect against; meaning the aesthetics have a mental model cost). It's not go out of their way to protect against. It's there's an easy way of making sure everything is composable. Your misappropriation of use flags doesn't have that. Again, you're pulling a na uh, you're the smelly face counter argument. Bluntly, you want something that is academically possible, but pragmatically/realistically unneeded- meaning the gains are basically not there, but the costs most definitely are. Now, for exherbo were y'all lack actual versioned format (exheres-0 has changed heavily since it's inception), and chucked everything and did it from scratch (right? or do I need to do a copyright analysis in addition?)... the situation differs. You can invent whatever syntax you want, since you're starting from scratch, changing the mental mode for parsing is fine. We however are *not* starting from scratch. This shifts what we'll accept for costs/gains ratio; frankly, the fact y'all don't make use of those claimed 'gains' makes me think y'all tried something and it
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 30 Sep 2012 13:14:53 -0700 Brian Harring ferri...@gmail.com wrote: That's largely because there are a lot of former Gentoo developers there who all said oh, yeah, I forgot we could do it the other way when this was pointed out... I analyzed *all* exheres on git.exherbo. To be crystal clear, these include your packages. You yourself didn't use nested labels. So either the author of labels 'forgot' he could use it, or just didn't find the nesting actually useful. That's a rather disingenuous claim, considering how none of the packages I maintain have any non-trivial dependencies... You could equally well say that every single package I maintain makes use of nested labels in every single place where they're relevant. So... real world usage removes one of the core arguments of labels, leaving it just as it's a new syntax/aesthetically more pleasing in comparison to dep:build? ( blah ) form. Not expecting you'll agree with that statement based on the facts of y'alls own repo... so if you're going to retort, bust out actual examples from eithe trees, where nesting would be preferable to the form people use now please; else just drop it (-your- own usage of labels disproves your claim; thus why I want actual examples now if that point will be debated any further). It's not just that it's more aesthetically pleasing. There are two arguments favouring labels over use abuse. The first is that it doesn't have perverse behaviour associated with it like your misappropriation of use conditionals does. If you put labels deep in a tree, it's well defined. If you put your conditionals anywhere except the top level, crazy stuff happens. The second is that it starts the conceptual shift from cat/pkg is a build dep, and cat/pkg is a run dep to cat/pkg is a dep that is required for build and run. Bluntly, you want something that is academically possible, but pragmatically/realistically unneeded- meaning the gains are basically not there, but the costs most definitely are. No, I want something where things that are different look different. Dependency types are nothing like use flags, so they shouldn't look the same. Either way, this is gentoo, we're talking about the ebuild format; just the same as everyone shredded mgorny's ass for proposing we mangle atom syntax w/out gain, and proposal you push for the deptree changing, has to have significant gains for changing the existing form; aesthetics at a cost aren't enough. The gain is that you have a syntax designed for what's being represented, not an existing syntax abused to sort of (but not quite, because it's still defined in terms of rendering down) do new things. Really, all it takes to see that your syntax is bad is one tiny little example: dep:build? ( dep:run? ( cat/pkg ) ) There shouldn't be any need to add in a repoman check to catch that kind of thing. The problem is entirely caused by bad syntax design. Implementing labels is not difficult, and the extra cost is worth it to get a good design. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing GLEP-62 itself
On Sat, Sep 29, 2012 at 11:55:22AM +0200, Micha?? G??rny wrote: On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. What kind of addressing? The user interaction works like usual -- portage lists a bunch of flags, some of them may have additional hammers or sickles to mean that they will not trigger the rebuild. Nothing more is required. What is even more important, there is nothing new to learn for the user. In fact, he doesn't need anything new from UI. He will just set the flag like he did 10 years ago. 1) REQUIRED_USE interaction. That's a rats nest, trust me on that one. If your proposal is to just to have people tweak, get yelled at by the pm, tweak, etc, well, on behalf of users, thanks a lot. 2) While hard to comment since your 'updated' glep wasn't fully updated- now is self inconsistent (minimally, trace backwards compatibility; fix it in full next time)... you're not exactly covering how this will go; best I can figure, you just want to shove yet another coloring (great for color blind people) or syntax markup on emerge -pv style output, somehow indicating runtime toggable or not; this is getting picked at because that display already is a crapfest and overloaded. 3) You're ignoring cycles here; specifically suggested dep based cycles that influence the originating node, and how that is represented- this isn't counting representing during --tree mode what is brought in where/when because of it. 4) Finally, and more damningly, you're ignoring apps like porthole. You need to think long/hard about how *exactly* porthole is going to indicate to users what optionals are there- more importantly, what those optionals induce/require (that's where it truly gets ugly and your lack of dep resolver knowledge, and unwillingness to do a patch and learn the basics there become infuriating); || () or blockers w/in suggested alone are going to make things painful. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... As others have said, we're not stacking it. Using it in eclasses is whacky and should be avoided. End of the story. It's your proposal there boss. That's a stupid decision, but as said, your proposal to run into the ground if you'd like. However. I suggest you actually document that in your proposal that it breaks from the stacking norm. Also, drop the backwards compatibility claim at the bottom. It was bullshit before, the fact I keep having to picking
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, Sep 30, 2012 at 09:30:18PM +0100, Ciaran McCreesh wrote: On Sun, 30 Sep 2012 13:14:53 -0700 Brian Harring ferri...@gmail.com wrote: That's largely because there are a lot of former Gentoo developers there who all said oh, yeah, I forgot we could do it the other way when this was pointed out... I analyzed *all* exheres on git.exherbo. To be crystal clear, these include your packages. You yourself didn't use nested labels. So either the author of labels 'forgot' he could use it, or just didn't find the nesting actually useful. That's a rather disingenuous claim, considering how none of the packages I maintain have any non-trivial dependencies... You could equally well say that every single package I maintain makes use of nested labels in every single place where they're relevant. Admittedly, that was a punch nearing the belt or a bit below; that said it's not disenguous. Reality is, our current form can handle deps generally fine- what you label as trivial is the vast majority- I argue effectively all. And I intentionally gave you a way to disprove that; find real world dependency examples to disprove it. So... real world usage removes one of the core arguments of labels, leaving it just as it's a new syntax/aesthetically more pleasing in comparison to dep:build? ( blah ) form. Not expecting you'll agree with that statement based on the facts of y'alls own repo... so if you're going to retort, bust out actual examples from eithe trees, where nesting would be preferable to the form people use now please; else just drop it (-your- own usage of labels disproves your claim; thus why I want actual examples now if that point will be debated any further). It's not just that it's more aesthetically pleasing. There are two arguments favouring labels over use abuse. The first is that it doesn't have perverse behaviour associated with it like your misappropriation of use conditionals does. If you put labels deep in a tree, it's well defined. If you put your conditionals anywhere except the top level, crazy stuff happens. This statement of yours however is fairly disenguous; label behaviour when nested suffers the same mental parsing oddity (wait, we're in build context, and this is test? Wtf happens there?). With 'use abuse' however, the situation is clear: dep:build,run? ( x? ( dep:test? ( blah ) foon ) monkeys ) Means that 'blah' target doesn't show up. Which is the *same* as what happens if someone did thus in our existing syntax: x? ( !x? ( blah ) ) Worth noting, you didn't ban that from exherbo; you left that to sort itself out, same as I'm doing for dep:blah flags. Were I punching below the belt, the word 'hypocritical' would likely be involved. The second is that it starts the conceptual shift from cat/pkg is a build dep, and cat/pkg is a run dep to cat/pkg is a dep that is required for build and run. Fairly weak argument at best; you're claiming that via labels, contextually they know it's these deps in comparison to via dep:build contextually they know it's exposed only in build. Same difference. Bluntly, you want something that is academically possible, but pragmatically/realistically unneeded- meaning the gains are basically not there, but the costs most definitely are. No, I want something where things that are different look different. Dependency types are nothing like use flags, so they shouldn't look the same. I'll buy that argument, and to some degree- agree. I just view that as academic wankery without real world gain. So like I said, academically possible, but pragmatically/unrealistically unneded. No amount of arguing is going to dissuade me on that view either, although real world tree examples *might*- aka, stop talking, go analyzing. Either way, this is gentoo, we're talking about the ebuild format; just the same as everyone shredded mgorny's ass for proposing we mangle atom syntax w/out gain, and proposal you push for the deptree changing, has to have significant gains for changing the existing form; aesthetics at a cost aren't enough. The gain is that you have a syntax designed for what's being represented, not an existing syntax abused to sort of (but not quite, because it's still defined in terms of rendering down) do new things. Really, all it takes to see that your syntax is bad is one tiny little example: dep:build? ( dep:run? ( cat/pkg ) ) x? ( !x? ( cat/pkg ) ) Outlaw that in paludis/exherbo, and *perhaps* I'd listen to you. You're going into broken record mode; the fact people can do stupid shit if they're willingly trying to abuse the syntax isn't much of an argument- especially considering the PM can handle it either way, rendering it out to a noop. There shouldn't be any need to add in a repoman check to catch that kind of thing. The problem is entirely caused by bad syntax design. Implementing labels is
[gentoo-dev] About disabling DISABLE_DEPRECATED
Hi all,
as discussed this morning on #-desktop, I found out while reading
commits from April that we have quite a few ebuilds in tree doing this
manually.
The problem is that in those ~153 instances of the same command, some do
take care of problems such as i18n env, some don't, some delete whole
lines, some replace with $(NULL) or even other values.
I think it is high time we provide a reference solution for this, even
if the solution should be to push upstream to fix there build system as
usual.
You'll find in attachement a prototype patch from gnome2-utils eclass.
It does not take care of packages providing
--disable-deprecations{,-flags} on purpose for now since I have not
found a MACRO and hence a reliable way to make sure this works in
upstream tarballs. Some packages do have such configure switch but it
does not always work.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Index: eclass/gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.107
diff -u -B -r1.107 gnome2.eclass
--- eclass/gnome2.eclass 27 Sep 2012 16:35:41 - 1.107
+++ eclass/gnome2.eclass 30 Sep 2012 09:58:09 -
@@ -94,6 +94,9 @@
# Prevent scrollkeeper access violations
gnome2_omf_fix
+ # Disable all deprecation warnings
+ gnome2_disable_deprecation_warning
+
# Run libtoolize
if has ${EAPI:-0} 0 1 2 3; then
elibtoolize ${ELTCONF}
Index: eclass/gnome2-utils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2-utils.eclass,v
retrieving revision 1.29
diff -u -B -r1.29 gnome2-utils.eclass
--- eclass/gnome2-utils.eclass 27 Sep 2012 16:35:41 - 1.29
+++ eclass/gnome2-utils.eclass 30 Sep 2012 09:59:43 -
@@ -424,3 +424,40 @@
gnome2_query_immodules_gtk3() {
${EPREFIX}/usr/bin/gtk-query-immodules-3.0 --update-cache
}
+
+# @FUNCTION: gnome2_disable_deprecation_warning
+# @USAGE: gnome2_disable_deprecation_warning
+# @DESCRIPTION:
+# Disable deprecation warnings commonly found in glib based packages.
+# Should be called from src_prepare.
+gnome2_disable_deprecation_warning() {
+ local retval=0
+ local fails=( )
+
+ ebegin Disabling deprecation warnings
+ # The sort is important to ensure .am is listed before the respective .in for
+ # maintainer mode regeneration not kicking in due to .am being newer than .in
+ for makefile in $(find ${S} -name Makefile.in \
+ -o -name Makefile.am -o -name Makefile.decl | sort); do
+
+ if ! grep -qE (DISABLE_DEPRECATED|GSEAL_ENABLE) ${makefile}; then
+ continue
+ fi
+
+ LC_ALL=C sed -e 's:-D[A-Z_]\+_DISABLE_DEPRECATED:$(NULL):g' \
+ -e 's:-DGSEAL_ENABLE:$(NULL):g' \
+ -i ${makefile}
+
+ if [[ $? -ne 0 ]]; then
+ # Add to the list of failures
+ fails[$(( ${#fails[@]} + 1 ))]=${makefile}
+
+ retval=2
+ fi
+ done
+ eend ${retval}
+
+ for makefile in ${fails[@]} ; do
+ eerror Failed to disable deprecation warnings in $makefile
+ done
+}
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On Sun, Sep 30, 2012 at 10:58:06AM +0200, Fabian Groffen wrote:
On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?
Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )
The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them. They are currently
outside of VDB. pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths. Python sometimes
regenerates the files when it runs. It may as well just ignore them
(since they are newer but non-matching, unclear to me).
.pyc should be compatible within slotted python versions;
recompilation occurs if .pyc/.pyo mtime differs from the originating
.py. Via EAPI=3 mtime gurantees, that should be addressed- below
that, compilation via pkg_postinst is necessary due to the lack of
mtime guarantees.
In the worst case it returns Bad marshalling data.
Examples wanted for this. If this occurs, that's a python bug- one
exception... portage (figures). They install into a non
/usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is
exposed/accessed for py2.7 for example.
That said, a .pyc/.pyo from an older python version causing a blow up
in a differing python version hasn't occurred since the 2.3 - 2.4
transition (if memory serves).
Either way, examples desired please.
~harring
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@gmail.com wrote: Reality is, our current form can handle deps generally fine- what you label as trivial is the vast majority- I argue effectively all. We could do away with half of the current feature set if we were only interested in making things nice for the vast majority of cases... This statement of yours however is fairly disenguous; label behaviour when nested suffers the same mental parsing oddity (wait, we're in build context, and this is test? Wtf happens there?). No, label behaviour is local, and scope independent. Means that 'blah' target doesn't show up. Which is the *same* as what happens if someone did thus in our existing syntax: x? ( !x? ( blah ) ) Worth noting, you didn't ban that from exherbo; you left that to sort itself out, same as I'm doing for dep:blah flags. Were I punching below the belt, the word 'hypocritical' would likely be involved. That's not fixing an existing screw-up, which is not the same at all as adding a new screw-up. The second is that it starts the conceptual shift from cat/pkg is a build dep, and cat/pkg is a run dep to cat/pkg is a dep that is required for build and run. Fairly weak argument at best; you're claiming that via labels, contextually they know it's these deps in comparison to via dep:build contextually they know it's exposed only in build. Same difference. It's rather a big deal now that we have := dependencies. No, I want something where things that are different look different. Dependency types are nothing like use flags, so they shouldn't look the same. I'll buy that argument, and to some degree- agree. I just view that as academic wankery without real world gain. So like I said, academically possible, but pragmatically/unrealistically unneded. Labels are almost as easy to implement as your filtering model, and they come with the benefit of a better syntax for developers. Even if labels are noticably more work to implement, which I'm not convinced is the case, it's worth paying that price a couple of times in package manglers rather than having developers pay the price of worse syntax in thousands of ebuilds. Filtering is a whole new mechanism anyway. But here's the thing: when you sell something as pragmatic, what you're really saying is it's wrong, I know it's wrong, and I'm going to pretend that wrong is a good thing. Getting it wrong should be something you do only after you're sure you can't afford get it right; it shouldn't be something you're proud of. In my proposal, I am addressing labels; will fold in your claims, but those claims basically are shit- however, if you *did* find a conflicting nested example that wasn't contrived, preferablly multiple, I'd like those examples so I can include them into the proposal (give labels a fair hand, basically). You already have an example in your proposal, in the form of mplayer's X? ( ) dependencies. But that's missing the point. Even if you pretend complicated dependencies don't exist, labels are still by far the better proposal. Your argument boils down to it's more pragmatic to do a quick and dirty implementation in Portage and thus force the technical debt onto every single ebuild than it is to do it cleanly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
Pardon the belated response; responding to emails that are quick where possible, but lagging on -dev. Missed this one however... On Wed, Sep 19, 2012 at 09:16:02AM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/12 09:09 AM, Michael Orlitzky wrote: On 09/19/2012 06:59 AM, Duncan wrote: Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: On 16 September 2012 21:15, Brian Harring ferri...@gmail.com wrote: So... basically, people are already doing this manually with their own intermediate vars. And this works fine, so it doesn't warrant a cosmetic change. @ferringb: yngwin has a point that I've not seen addressed. What /is/ wrong with the whole CDEPEND intermediate var idea? It seems to work and /I/ don't know of any problems with it (and it would appear, neither does yngwin), yet you talk about it as if there's something wrong with it. And while we're at it, do DEPEND=$RDEPEND ... style solutions have the same problems (or lack thereof)? The problem appears as we introduce more DEPEND variables (which is what prompted the proposal, IIRC). If we have ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some (i.e. not total) sharing going on then the COMMON_DEPEND pattern starts to fall apart. You potentially need, AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND (COMMON_DEPEND) This obviously gets worse as more DEPEND vars are introduced. Well not really, no -- the additional *DEPENDs that are being proposed (or at least mentioned) for new EAPI will either remove atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so tersely that a COMMON_DEPEND or other intermediate variable won't really be necessary for them. It depends on the dep type actually, and how we're viewing those deps- if they must be complete or not. Consider test depends for example. Either we can specify it as in addition to depend- which sucks, because it's entirely possible for a DEPEND target to not be required for TDEPEND. While that's a corner case, it's actually easy to address; just require TDEPEND to be comprehensive for the test phase. Thus DEPEND and TDEPEND suddenly share a lot, and TDEPEND shares part of RDEPEND. Moving on to a real world example... PDEPEND. Currently a full graph resolution requires pulling RDEPEND and PDEPEND, collapsing them, and ensuring they're fullfilled for anything that is already installed (ie, PDEPEND is required after the transaction is completed). In our current separated var setup, this as said, this requires the PM to track/handle it separately. However, were PDEPEND to be complete/full- that would mean the PM could just render for dep:post and know this is what is necessary outside of the transactional block of building/installing it. So RDEPEND and PDEPEND actually share a *shitton*- they're the same contents in 97% of the tree. Meaning dep:run,post? for 97% of the tree, w/ 3% needing to have an addition dep:post? section. Offhand, comprehensive deps make things easier for devs- it gives them the ability to be crystal-freaking-clear as to what's needed at each stage; via them doing so, it means the resolver has a greater space to dig itself out of fucked up situations if necessary. Additionally, it actually makes life easier for PM authors. If we had TDEPEND (test), this is how things would go; note this is written for just an install, not a replacement (replace is similar, just noisier deflecting from my point): 1) ensure DEPEND is satisfied 2) run phases setup - compile 3) ensure TDEPEND is satisfied; Implicitly, DEPEND in the process (if there is a cycle induced by TDEPEND + DEPEND being required, we have no way out of it). 4) run install phase 5) ensure RDEPEND is satisfied. No longer care about TDEPEND/DEPEND. 6) run pkg_preinst, merge, pkg_postinst. 7) a transaction is opened up, that must be completed before the PM exits; before that exit, RDEPEND must still be satisfied, as must PDEPEND. With what I'm suggesting. 1) ensure dep:build is satisfied 2) run phases setup - compile 3) Ensure dep:test is satisfied. If cycle breaking is necessary, anything in dep:build but not dep:test can be pulled. 4) install phase 5) ensure dep:run is satisfied. Again, if cycle breaking is necessary, punt whatever isn't in dep:run as necessary to break that cycle. 6) pkg_preinst, merge, pkg_postinst. 7) transactional block; ensure dep:post is satisfied before exiting said transaction. That's for install; for the PM considering a pre-installed pkg, it converts from; 1) ensure RDEPEND and PDEPEND are satisfied to 1) ensure dep:post is satisfied. Tbh, I'm not sure I'm communicating these gains as well as I could be; at first glance, I'm pretty sure people will say what's the difference? because the gains/difference there are subtle.
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote: But here's the thing: when you sell something as pragmatic, what you're really saying is it's wrong, I know it's wrong, and I'm going to pretend that wrong is a good thing. Getting it wrong should be something you do only after you're sure you can't afford get it right; it shouldn't be something you're proud of. No, when I say pragmatic, what I'm actually saying is that people who can't focus on cost/gain, by large, haven't had real jobs (else they would've had that perfectionism/decreasing gains ground out of them sooner or later), and are spending their time whacking off chasing a mythical 'perfect' solution. Academic wankery, is the short version. You're good at technical, but you frequently do the academic wanking crap which leads to things dead-ending... plus wasted time because to you, 'pragmatic' is a dirty word (compromise? Heaven forbid!). In my proposal, I am addressing labels; will fold in your claims, but those claims basically are shit- however, if you *did* find a conflicting nested example that wasn't contrived, preferablly multiple, I'd like those examples so I can include them into the proposal (give labels a fair hand, basically). You already have an example in your proposal, in the form of mplayer's X? ( ) dependencies. I said nested conflicting labels. Meaning build: x? ( dar run: blah ) which isn't the case for any of mplayer deps. Actual examples from the tree where a conflicting nested label is preferable. That isn't one of 'em, and you're unwillingness/inability to point out real world examples is just digging a deeper ditch for your argument. But that's missing the point. Even if you pretend complicated dependencies don't exist, labels are still by far the better proposal. Your argument boils down to it's more pragmatic to do a quick and dirty implementation in Portage and thus force the technical debt onto every single ebuild than it is to do it cleanly. My argument boils down to thus: We are not exherbo- we do not have the luxury of chucking out syntax and pulling NIH renaming of things for shits and giggles. Especially if the new syntax is directly translatable into a tweak of our existing syntax (a tweak that we should do anyways- recall I built this off of fixing USE_EXPAND). Your argument boils down to it's not labels, ignore that it's aesthetic knob polishing (you can do the same w/ our existent syntax, thus the analogy of waxing it I truly mean), use labels because I'll berate you incessently till you accede. Beauty of open source, you want it, go do it. If in, what, 4 years? 3? You've not been able to get off your ass, write a proposal, hell, do a portage patch (you've *never* done portage patches of any worth, bluntly- I know this since in the past I used to fix shit you requested), you lose your voice in the matter. Considering your points boil down to aesthetic academic wanking at this point... put up, or shut up, really is that simple. As said, you come up w/ real world examples, I'll include them; else persist and I'll just fold the academic wankery description of labels into the glep if you'd truly like me to (or you piss me off enough I do so to be a dick). ~harring
[gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
Brian Harring posted on Sun, 30 Sep 2012 15:15:18 -0700 as excerpted: The point I'm trying to make here is that each dep phase should be authorative; in doing so, you start getting a lot of potential subsets (DEPEND is a subset of TDEPEND, TDEPEND isn't completely, but mostly a subset of RDEPEND as RDEPEND is a likely a superset of DEPEND; PDEPEND is a superset of RDEPEND). So... you could do COMMON_DEPEND, COMMON_TDEPEND, COMMON_RDEPEND in the ebuild. Or you could just use a syntax form that allows you to directly inline that up front, rather than having to muck around w/ intermediate vars. Thanks /very/ much! You said you weren't sure you were being clear, but this is the first time I've /really/ understood what must surely be the root, at any reasonable level at all. Let me see if I've got it right: Yes, in some ways all we're dealing with here is optics, but the _problem_ is that with the proposed proliferation in detailed depend- types, what is now a simple CDEPEND and thus conceptually easy to handle, breaks into 10/20/50/whatever-large-number different shards, and what's conceptually easy to handle /now/ becomes many many times more difficult to handle, both conceptually for package maintainers and practically for iterative resolution in the PMs, due to the interplay of all the resulting *CDEPENDs. The proposed solution to that explosion in conceptual complexity not only changes the optics, but by making most of those detail-depend-types absolute/authoritative, allows both package managers (the programs, machine) and package maintainers (the humans) to consider each depend- type separately, thus decreasing both conceptual complexity to a once again manageable level for package maintainers (humans), and practical complexity for package managers (machine), increasing efficiency, reducing resolution time and probably eventually memory/installed-db/ cache size as well. Of course now I better understand Ciaran's argument for labels as well, since it would extend the absolute/authoritative principle even further, into the actual deps specification method in ebuilds/eclasses, thereby reducing conceptual context load even further via more explicitly absolute deps at the local level. But like you, in practice I don't see that going anywhere in gentoo, in the near/short-intermediate future, primarily due to political realities, but practically, also due to the conceptual leap it'd require from devs (as Ciaran himself points out in response to your statistical analysis of exherbo's repo, former gentoo devs simply don't tend to take advantage of this aspect of labels in exherbo either; the conceptual leap is in practice simply too much). Thus, while academically, his label approach is arguably better in terms of efficiency of absolutes, in practice, there's little or no difference between how it's used, and how your filtering approach will be used. Further, given the conceptual distance between labels and gentoo's current approach, with filters falling in between and political reality, the pragmatic filters approach at least has /some/ chance of passing the dev-debate stage and being approved, implemented and actually available for use in something like a reasonable timeframe (say EAPI-6, in a year's time, a bit more for actual in-tree use, given the historic EAPI-a-year processing). But exherbo style labels support altho academically better, given political reality, in all likelihood would take at least 2-3 years to pass and be usable in-tree. And even then, its practical use as demonstrated in exherbo wouldn't take advantage of the differences for another couple years after that, at least. Given that, having use of the useful pragmatic approach in a year's time or so seems best, as opposed to an arguably (as you've pointed out, no practical demonstration of it in exherbo yet, at least that you've been able to find) more academically ideal approach in three, without any real benefit over the pragmatic for five or more. Besides, this isn't actually a -problem- as there's nothing which really requires one to use such helpers; ebuild writers just, well, can. :) Getting to this point; yes, people could hack around it manually. Pretty sure that hasn't been in doubt. That's clearer now. Yes, people could continue to hack around it via CDEPENDS, etc. But the number of common vars (or alternative RDEPEND=$DEPEND ... assignments) and the resulting conceptual load on the human maintainer is set to increase exponentially as the number of depend-types increases linearly. At some point it's just no longer practically maintainable, and the whole process breaks down. What the single dependencies variable aims to do in both the filtering and labels forms is prevent that ultimate conceptual overload and resulting process breakdown by allowing direct compound assignments, thus eliminating the intermediate assignments and their exponential
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-30 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-09-30 23h59 UTC. Removals: games-roguelike/falconseye 2012-09-25 15:33:13 mr_bones_ app-misc/lolcat 2012-09-26 22:25:31 hasufell www-apache/mod_ap2_snmp 2012-09-30 17:49:32 flameeyes app-admin/prelude-lml 2012-09-30 17:56:40 flameeyes app-admin/prelude-manager 2012-09-30 17:56:41 flameeyes dev-libs/libprelude 2012-09-30 17:56:41 flameeyes dev-libs/libpreludedb 2012-09-30 17:56:42 flameeyes net-analyzer/prewikka 2012-09-30 17:56:42 flameeyes Additions: dev-ruby/paint 2012-09-24 18:50:17 hasufell app-misc/lolcat 2012-09-24 18:51:47 hasufell app-crypt/libsecret 2012-09-25 10:06:41 tetromino sci-mathematics/pymc2012-09-26 17:16:53 heroxbd games-misc/lolcat 2012-09-26 22:25:10 hasufell games-strategy/spaz 2012-09-27 08:17:05 pinkbyte gnome-extra/nemo2012-09-28 06:37:30 tetromino dev-ruby/curb 2012-09-29 06:04:44 flameeyes dev-ruby/configliere2012-09-29 06:17:36 flameeyes dev-java/soylatte-jdk-bin 2012-09-29 11:08:58 grobian dev-cpp/threadpool 2012-09-29 23:14:37 robbat2 dev-ruby/timers 2012-09-30 09:01:54 graaff media-plugins/gimp-lensfun 2012-09-30 10:35:57 hwoarang media-gfx/iscan-plugin-gt-x820 2012-09-30 22:14:39 flameeyes net-analyzer/nagios-check_glsa2 2012-09-30 23:35:51 flameeyes -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: games-roguelike/falconseye,removed,mr_bones_,2012-09-25 15:33:13 app-misc/lolcat,removed,hasufell,2012-09-26 22:25:31 www-apache/mod_ap2_snmp,removed,flameeyes,2012-09-30 17:49:32 app-admin/prelude-lml,removed,flameeyes,2012-09-30 17:56:40 app-admin/prelude-manager,removed,flameeyes,2012-09-30 17:56:41 dev-libs/libprelude,removed,flameeyes,2012-09-30 17:56:41 dev-libs/libpreludedb,removed,flameeyes,2012-09-30 17:56:42 net-analyzer/prewikka,removed,flameeyes,2012-09-30 17:56:42 Added Packages: dev-ruby/paint,added,hasufell,2012-09-24 18:50:17 app-misc/lolcat,added,hasufell,2012-09-24 18:51:47 app-crypt/libsecret,added,tetromino,2012-09-25 10:06:41 sci-mathematics/pymc,added,heroxbd,2012-09-26 17:16:53 games-misc/lolcat,added,hasufell,2012-09-26 22:25:10 games-strategy/spaz,added,pinkbyte,2012-09-27 08:17:05 gnome-extra/nemo,added,tetromino,2012-09-28 06:37:30 dev-ruby/curb,added,flameeyes,2012-09-29 06:04:44 dev-ruby/configliere,added,flameeyes,2012-09-29 06:17:36 dev-java/soylatte-jdk-bin,added,grobian,2012-09-29 11:08:58 dev-cpp/threadpool,added,robbat2,2012-09-29 23:14:37 dev-ruby/timers,added,graaff,2012-09-30 09:01:54 media-plugins/gimp-lensfun,added,hwoarang,2012-09-30 10:35:57 media-gfx/iscan-plugin-gt-x820,added,flameeyes,2012-09-30 22:14:39 net-analyzer/nagios-check_glsa2,added,flameeyes,2012-09-30 23:35:51 Done.
