Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On 04/23/2010 08:14 AM, James Cloos wrote: HvD == Harald van Dijk true...@gentoo.org writes: HvD Let's say this is in the tree: HvD foo.eclass: HvD DEPEND=dev-lang/python:2.6 HvD bar-1.ebuild: HvD inherit foo HvD Let's say this is in your overlay: HvD foo.eclass: HvD DEPEND=|| ( dev-lang/python:3.1 dev-lang/python:2.6 ) HvD Now you install bar. How should portage know that it must regenerate the HvD metadata cache, to see that it doesn't need to install python 2.6 if you HvD already have 3.1? It shouldn't bother. :) Really, that isn't the kind of change that I find I need to make. Different users have different needs. The user who reported this bug needed the opposite behavior: http://bugs.gentoo.org/show_bug.cgi?id=276264 And it should never regenerate the metadata cache (ie portage/metadata/cache). Again, different users have different needs and the user in bug #276264 really needed to regenerate the cache. The docs used to -- and probably still do -- recommend regenerating that cache after certain changes. Which is a drasticly bogus suggestion unless you have a *very* fast system. It's a somewhat bogus suggestion if you are not modifying eclasses in the same way as the user from bug #276264. Note that it's possible to enable eclass-overrides without discarding $PORTDIR/metadata/cache. It seems like that might work for your use case (don't forget that this won't necessarily be appropriate for every user). For the user in bug #276264, it's more appropriate to discard $PORTDIR/metadata/cache and run emerge --regen (with --jobs if he wants to use multiple cpu cores in parallel). Even across a dialup straw, an emerge --sync is orders of magnitude faster. Different things give different results. It may work for your use case but not for others. If the ebuild calls a class which has been overridden by a local class, and the original class set DEPENDs or the like, then as it reads in the new class file it should just use those values in place of the ones in the cache. And that's the behavior that you'll get if you don't discard $PORTDIR/metadata/cache (which would be inappropriate for the user in bug #276264). -JimC -- Thanks, Zac
[gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. I think it's a good idea to strongly encourage it, but actually forcing it through cvs? No thanks. I'm not tracking down another dev just to fix a spelling mistake. :P -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On 04/25/2010 01:06 PM, Ryan Hill wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. I think it's a good idea to strongly encourage it, but actually forcing it through cvs? No thanks. I'm not tracking down another dev just to fix a spelling mistake. :P How did the spelling mistake get there in the first place? A review system should reduce having them in the first place. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 1) Why is it of any relevance whether or not the quizzes test this policy? 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? - Alistair [1] It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 2010.04.24 18:40, Petteri Räty wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. Regards, Petteri In industry, the practice is called peer review. Its generally thought to be a GoodThing as its part of the process of trapping errors as early as possible in the process, where they have lowest cost. We cannot easily attribute cost in terms of money, so think about it in developer and user hours wasted as errors 'escape'. Industry also recognises the need that any process needs to be tailored to the circumstance so the peer review process is not enforced. Project groups are permitted to assess the risk of screwing up against the cost of a fix. (That's overly simplistic). In short, following industry best practice, the peer review process should be strongly encouraged but we should stop short of using tools to enforce it. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgprYCIfBGTiU.pgp Description: PGP signature
[gentoo-dev] [RFC][NEW] Utility to find orphaned files
Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. [Attached] Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com find-orphaned-0.01.tar.bz2 Description: application/bzip
[gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On Sun, 25 Apr 2010 13:11:11 +0300 Petteri Räty betelge...@gentoo.org wrote: On 04/25/2010 01:06 PM, Ryan Hill wrote: I think it's a good idea to strongly encourage it, but actually forcing it through cvs? No thanks. I'm not tracking down another dev just to fix a spelling mistake. :P How did the spelling mistake get there in the first place? A review system should reduce having them in the first place. People make mistakes. Anyways my point is that requiring a peer review for trivial changes is just unneeded bureaucracy. Even for non-trivial changes, it doesn't make sense to force someone who knows their eclass inside out and knows what they're doing to get a review from someone else who may not have a clue. I'm not saying that peer-review shouldn't be done; it's a very good idea, especially if you're new, or unsure of your changes, or you have a team consisting of more than one person. In fact I would support a policy that said eclasses need to be reviewed before committing. But enforcing it through cvs is never going to fly. Just use common sense. If we were having ongoing issues with people breaking eclasses then I could see where you're coming from. But as it is, it's a non-problem. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On Sun, Apr 25, 2010 at 4:36 AM, Ryan Hill dirtye...@gentoo.org wrote: On Sun, 25 Apr 2010 13:11:11 +0300 Petteri Räty betelge...@gentoo.org wrote: On 04/25/2010 01:06 PM, Ryan Hill wrote: I think it's a good idea to strongly encourage it, but actually forcing it through cvs? No thanks. I'm not tracking down another dev just to fix a spelling mistake. :P How did the spelling mistake get there in the first place? A review system should reduce having them in the first place. People make mistakes. Anyways my point is that requiring a peer review for trivial changes is just unneeded bureaucracy. Even for non-trivial changes, it doesn't make sense to force someone who knows their eclass inside out and knows what they're doing to get a review from someone else who may not have a clue. I'm not saying that peer-review shouldn't be done; it's a very good idea, especially if you're new, or unsure of your changes, or you have a team consisting of more than one person. In fact I would support a policy that said eclasses need to be reviewed before committing. But enforcing it through cvs is never going to fly. Just use common sense. Sure it will; you just need to create the tools with flexibility in mind. For instance: 1) Require peer review on all eclasses 2) Do not require peer review for changes less than N lines 3) enable a commiter to over-ride the review with some kind of option (--force or similar) 4) enable an eclass-owner to opt-out of the review process entirely with some kind of flag. I am not aware of how robust the pre-commit hooks in cvs are so I cannot comment on how easy these things are to implement. -A If we were having ongoing issues with people breaking eclasses then I could see where you're coming from. But as it is, it's a non-problem. -- fonts, by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On 04/25/2010 07:36 AM, Ryan Hill wrote: People make mistakes. Agreed - at work I've often found a quality mindset that is 100% focused on preventing mistakes, and I've found that these kinds of systems are almost equally as focused on preventing them from being fixed (three minutes to fix a bug, three weeks to document and release the fix - then we wonder why the system has hundreds of trivial open bugs with no ROI for fixing them). A good quality system isn't just about preventing mistakes - it needs to be about fixing them too. The system that prevents typos from getting into the tree shouldn't get in the way of those typos being fixed. There needs to be a balance. Scripts running on repository servers don't have a sense of balance, so they aren't the answer. Nor is cutting off hands any time a dev messes up unless it becomes a pattern or there is malicious intent. However, a systematic review process is probably a good thing most of the time, and published policies supporting this are a good thing. Rich
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/26/2010 01:42 AM, Alistair Bush wrote: On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 1) Why is it of any relevance whether or not the quizzes test this policy? I doubt recruits read all of our documentation while answering the quizzes. This would just enforce behavior. 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? http://devmanual.gentoo.org/eclass-writing/index.html Before updating eutils or a similar widely used eclass, it is best to email the gentoo-dev list. [1] It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here. Yeah it's not spelled that clearly there. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
Angelo Arrifano schrieb am 25.04.2010 13:18:
Hello developers developers and developers,
Ever wondered how much crap is left in your X-years old Gentoo box?
I just developed a python utility to efficiently find orphaned files in
the system. By orphaned files I mean the files that are present on
system directories and don't belong to any installed package.
The package builds a virtual filesystem (cache) on the RAM using python
hash tables. Then it uses the cache to find the ownership of files
inside user-specified dirs.
Building the cache takes less than 10 seconds here in a system with 1366
installed packages.
This is not intended to be a finished program yet, I'm looking forward
for your constructive commentaries.
What about searching the complete file system but using an exclude file where
you can put directories and files which should not be searched. It is tedious to
tell every path on the command-line. Also for instance if you specify /lib it
will also search under /lib/modules and I am sure you do not consider all
contents there as unneeded.
You also need to consider that your tool will return other false positives like
byte compiled python modules and perl header files. In general everything an
ebuild does in phases where it adds files to file-system but files are not
stored to CONTENTS (pkg_{pre,post}inst). At this point the files are needed but
not recognized by the package manager. If the ebuild does not take care of this
files when removing (pkg_{pre,post}rm) the package they will remain on the
file-system and are now unneeded.
I have written something in perl which I recently tried to implement in python
(not the same functionality like the perl version yet). I am not a good perl or
python programmer but it fits my needs especially the perl version as I know a
bit more perl than python.
I attach both versions and a sample exclude file. Maybe it will be of help.
--
Daniel Pielmeier
cruft.tar.bz2
Description: BZip2 compressed data
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-04-2010 13:10, Petteri Räty wrote: On 04/26/2010 01:42 AM, Alistair Bush wrote: On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? http://devmanual.gentoo.org/eclass-writing/index.html Before updating eutils or a similar widely used eclass, it is best to email the gentoo-dev list. The important bit there is widely used eclass. I agree with having peer review, but as others argued I don't agree with the recent trend to make it increasingly harder to commit stuff to the tree. To expand on the above, by widely used eclass I interpret eutils, autotools, base and similar eclasses because even though some eclasses like the kde4 eclasses are used by many ebuilds, it's mostly a team's eclass and not a general eclass shared by everyone. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL1F5OAAoJEC8ZTXQF1qEPNf4QAIoyr8IELeixBJDHvv2ACaMw omUQj5nbjFB1Xc7Die4dT7TkUfJ2/QddMcG1I/CNTNEdRtJAR31UDS2Lbm7gOj11 wpd+g7mDQuJZdW3873YXkThoynqS3xzfpZocxb2s+adxyXF6Mh65+N+ZT515HMh8 DujqxGHxjA4Cqn/zGe6ClqfRwxfGZkYkA/eQfX9m7TSJHTwxK4sijhFNphSsA89E qyVW0Y18mrf0pVBpUaQ4kfCuwp0HWOIoubSCIo47KFINfL4TteaX1NTOP9JzEIDH saCUURHQw2nWTsPDNjvL6euvriyTZpm0lhHR86j87maDVeGFDn0PZ8Cs/ypCVhxJ 1MxdL7NvyUptHO6UGUvluqZzh4zTDEsotCRWzyshEPAy51q+rWbMLPVeDZfkVgl8 /0VlhNFgdoxuowOEK4AiTWifp5oa5RO03K5Hyfze2IfFXArva7Znb5oCGeHoEBqn Kr5trpgIqyW+v3XifurbuOSoU7BDTlzH3WrkCRJq0pP5Hogtod0wf1tAy/wQ+F+3 yUphi3tzMFMlFoqBE5pfjyTa22vi/RjNVgH3sie6HD8qZsmKJIILb2Y3NrloCzlB WYdCP0+dfFOafqFMpAFUuI3E7zrKacQK7mshLE9vTNa+dh6LVASn2WIaLdtse1GK sUN2ESxQteslTvu7v6r/ =GLm6 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
Hello, On Sun, 25 Apr 2010 13:18:25 +0200 Angelo Arrifano mik...@gentoo.org wrote: Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. There is a tool that does that, qfile from app-portage/portage-utils. Check the -o, --orphans* List orphan files option. It's not as straight forward as it could be, as it checks only for files specified as arguments or read from file. But you can trivially use it like: # find /dir/you/want/to/check/for/orphans | qfile -o -f - Best, Yuri.
Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
On 25-04-2010 17:34, Yuri Vasilevski wrote: Hello, On Sun, 25 Apr 2010 13:18:25 +0200 Angelo Arrifano mik...@gentoo.org wrote: Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. There is a tool that does that, qfile from app-portage/portage-utils. Check the -o, --orphans* List orphan files option. It's not as straight forward as it could be, as it checks only for files specified as arguments or read from file. But you can trivially use it like: # find /dir/you/want/to/check/for/orphans | qfile -o -f - Best, Yuri. Based on the comments so far, I'll try to make my PoC a better tool. My primary objective is to make this some kind of disk cleanup utility for Gentoo boxens. I don't expect Gentoo systems to be *that* polluted but sometimes we all have to do ugly things to fix broken systems real fast. - If you know what I mean. There are other things that came to my mind, like using stored hashes to check the system files integrity (as in security). My next steps in regard to this utility will be: * Follow harring suggestion and use available PM API. * Make the application handle symlinks so we start getting a more informative output. * To store the generated cache on disk and to only regenerate it if needed. Regards, - Angelo
Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
On Sun, Apr 25, 2010 at 1:18 PM, Angelo Arrifano mik...@gentoo.org wrote: Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. i have refactored findcruft (search the forums) two years ago (see http://git.xnull.de/cgit/findcruft2/), maybe you can take a look at it, especially the false-positives handling. HTH, Bene
[gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On Sun, 25 Apr 2010 05:01:17 -0700 Alec Warner anta...@gentoo.org wrote: On Sun, Apr 25, 2010 at 4:36 AM, Ryan Hill dirtye...@gentoo.org wrote: said eclasses need to be reviewed before committing. But enforcing it through cvs is never going to fly. Just use common sense. Sure it will; you just need to create the tools with flexibility in mind. For instance: 1) Require peer review on all eclasses 2) Do not require peer review for changes less than N lines 3) enable a commiter to over-ride the review with some kind of option (--force or similar) 4) enable an eclass-owner to opt-out of the review process entirely with some kind of flag. I am not aware of how robust the pre-commit hooks in cvs are so I cannot comment on how easy these things are to implement. Well, I didn't mean technically. ;) But we could achieve the same general effect of the above without installing padlocks on cvs. Just let projects or teams establish their own review policies like they already do. For example, if you commit changes to toolchain.eclass without consulting Mike, you'll soon find an email in your inbox. If you mess with wxwidgets.eclass without running it by me you'll find your commit reverted. On the other hand, anyone in the font, X, or tex herds can modify font.eclass. Let people establish rules suited to their project's workflow and enforce them as they see fit. Again, if there were some evidence this isn't working then it should be presented. Otherwise I don't see any reason to change the status quo. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-04-25 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-04-25 23h59 UTC. Removals: dev-libs/libxml 2010-04-20 15:51:48 mr_bones_ games-util/loki_setupdb 2010-04-20 15:52:41 mr_bones_ xfce-extra/xfce4-indicator-plugin 2010-04-20 16:03:02 ssuominen media-libs/jpgalleg 2010-04-20 16:05:57 ssuominen games-emulation/goosnes 2010-04-20 16:07:09 ssuominen dev-java/openjms-bin2010-04-21 16:43:19 betelgeuse games-fps/quake3-urbanterror2010-04-21 22:07:48 mr_bones_ dev-java/kaffe 2010-04-23 10:54:56 caster Additions: dev-ruby/async_sinatra 2010-04-19 18:09:22 flameeyes dev-lang/orc2010-04-21 15:38:51 ssuominen kde-misc/basket 2010-04-22 17:38:12 spatz sys-fs/mhddfs 2010-04-24 03:21:59 beandog www-misc/surl 2010-04-25 13:40:58 wired dev-libs/udis86 2010-04-25 17:41:38 chithanh -- 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: dev-libs/libxml,removed,mr_bones_,2010-04-20 15:51:48 games-util/loki_setupdb,removed,mr_bones_,2010-04-20 15:52:41 xfce-extra/xfce4-indicator-plugin,removed,ssuominen,2010-04-20 16:03:02 media-libs/jpgalleg,removed,ssuominen,2010-04-20 16:05:57 games-emulation/goosnes,removed,ssuominen,2010-04-20 16:07:09 dev-java/openjms-bin,removed,betelgeuse,2010-04-21 16:43:19 games-fps/quake3-urbanterror,removed,mr_bones_,2010-04-21 22:07:48 dev-java/kaffe,removed,caster,2010-04-23 10:54:56 Added Packages: dev-ruby/async_sinatra,added,flameeyes,2010-04-19 18:09:22 dev-lang/orc,added,ssuominen,2010-04-21 15:38:51 kde-misc/basket,added,spatz,2010-04-22 17:38:12 sys-fs/mhddfs,added,beandog,2010-04-24 03:21:59 www-misc/surl,added,wired,2010-04-25 13:40:58 dev-libs/udis86,added,chithanh,2010-04-25 17:41:38 Done.
