Re: [gentoo-dev] /{,usr/}bin path changed. What is the right solution for scripts?
On Sunday 01 April 2007, Peter Volkov wrote: Hello. Path of some utilities in coreutils-6.7-r1 changed from /usr/bin to /bin and vice versa. This cause some scripts became broken as they relied on the full path to executable. The question is: does there exist best practice on how to avoid this problem in future? Should we set some default PATH in scripts or should we call command -p program? Or as this is mainly problem for scripts that work in cron we should suggest users to set PATH in crontab? Or may be we should fix coreutils to create all possible symlinks? TIA, IMHO I have always like the PATH in script approach, it seems like a reasonable solution to me. -- Guillermo A. Amaral, CSE # Free Open Source Advocate nick: guillermoamaral @ blog: http://blog.guillermoamaral.com/ @ site: http://www.guillermoamaral.com/ $ irc: [EMAIL PROTECTED] % gpg: http://downloads.guillermoamaral.com/public.asc pgpvuHUMn7tqH.pgp Description: PGP signature
Re: [gentoo-dev] /{,usr/}bin path changed. What is the right solution for scripts?
On Sunday 01 April 2007, Peter Volkov wrote: Hello. Path of some utilities in coreutils-6.7-r1 changed from /usr/bin to /bin and vice versa. This cause some scripts became broken as they relied on the full path to executable. The question is: does there exist best practice on how to avoid this problem in future? Traditionally, all programs needed to boot the machine into single-user mode, together with an editor, were placed in /bin or /sbin. This allowed an administrator to do simple tasks such as simple editing of files in /etc, checking and repairing filesystems, etc.. without having any other partitions being mounted. Now-a-days it's probably all a bit moot because we have have bootable CDs and not as important as it used to be, but I am profoundly irritated when I find that when I boot to single user mode on Gentoo/Linux that I have to unmount my non-/ partitions to file check them, and then - even more irritating - have to remember to remount them in order to get a clean reboot, even worse is that vi is unavailable when you are repair mode because it is in /usr/bin. Thus one has to make do with ed. :-( Should we set some default PATH in scripts or should we call command -p program? Or as this is mainly problem for scripts that work in cron we should suggest users to set PATH in crontab? Or may be we should fix coreutils to create all possible symlinks? -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /{, usr/}bin path changed. What is the right solution for scripts?
Hello. Path of some utilities in coreutils-6.7-r1 changed from /usr/bin to /bin and vice versa. This cause some scripts became broken as they relied on the full path to executable. The question is: does there exist best practice on how to avoid this problem in future? Should we set some default PATH in scripts or should we call command -p program? Or as this is mainly problem for scripts that work in cron we should suggest users to set PATH in crontab? Or may be we should fix coreutils to create all possible symlinks? TIA, -- Peter. One idea that comes to mind is /usr/bin/env $bin For cron, one would need to set the PATH to something sane though. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /{, usr/}bin path changed. What is the right solution for scripts?
On Sunday 01 April 2007, Alec Warner wrote: For cron, one would need to set the PATH to something sane though. i thought sane cron systems would setup a sane PATH for you: /sbin:/usr/sbin:/bin:/usr/bin -mike pgpKWhRZ0eMFs.pgp Description: PGP signature
Re: [gentoo-dev] clanlib-0.6 and friends masked for removal
On 4/1/07, Mike Frysinger [EMAIL PROTECTED] wrote: why ? are you not aware of portage's ability to unmask things ? (not knowing you that much, I can't tell whether this was a joke or not) I was expecting fixes proposed in bug #156496 to be looked over someday, and end up in the tree or be discarded. Now that it surely won't happen, I want to try them and see for myself. Denis. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Monthly Gentoo Council Reminder for April
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1500 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /{,usr/}bin path changed. What is the right solution for scripts?
On Sun, 01 Apr 2007 10:02:27 +0400 Peter Volkov [EMAIL PROTECTED] wrote: The question is: does there exist best practice on how to avoid this problem in future? Should we set some default PATH in scripts or should we call command -p program? A lot of Gentoo scriptlets such as gcc-config and others source /etc/init.d/function.sh which sets up a default $PATH for you if needed. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hello; I'm just a gentoo user who has been lurking for a while trying to find a useful way to help my linux distro. Gentoo was recommended to be as a good way to get into linux and to rapidly understand the difference between the way linux works and windows works. I have to say that for the two years of my university life that i have used Gentoo for it has taught my a lot. Now i have never had a problem with portage my self, but since this thread is in existence there are some definite issues. Myself as a user would very much have to support Duncan's post below and as a Computer Science grad would have to say that it makes sense to clearly define a PMS which should be swappable 1:1 with any other PMS. To help new users the basic command set should also be the same, tho of course each PMS can have its own advanced features. Finally my own personal view of this matter; Gentoo should have and support its own package manager, it makes sense since one of the key advantages of Gentoo is to just have to packages you need with just to support you need i.e. USE flags. Since this is a key goal of the gentoo project it makes sense to provide a 'default' PM which abides to the PMS. It also means that there will always be a secure, monitored, distribution maintained package manager which would guarantee the distributions basic functionality. Well there is my 'users' point of view; As a quick aside, could someone point me in the right direction to help out with Gentoo, I've got some skills in C and C++ tho my main language is Java, but I'm a quick learner :P Duncan wrote: I keep seeing references to an official package manager. Clearly, at this point, it's portage, in part because there was no other practical reference for deciding whether the ebuild or the handling of it was broken. If it worked in portage, therefore, by definition, it was fine. (Well, with certain exceptions where portage was held to have bugs, but whether it was a bug in portage or not had to be decided before one could then rule on whether it was a bug in the tree or not.) However, now that PMS is finally about to provide what should be a definitive description of current generation package behavior, with the announced intention to update this with new versions into the future as required, the dependence on portage as the reference will soon be going away. The announced intention for this, among other things, is to allow alternate package managers, such that it can still be clear when it's the package broken and when it's the package manager. So far, so good. However, with such a definitive package behavior reference, the question presents itself, with what looks to be several possible alternatives waiting, why must Gentoo have an official package manager at all, and indeed, what purpose, other than name recognition, does maintaining such an official manager have? I'd contend that with an appropriate package/tree spec, as soon as we have multiple package managers meeting that spec, then we /don't/ /need/ an official package manager. Perhaps one /recommended/ by default in the documentation, sure. Perhaps one that ships on the official Gentoo LiveCD installers, sure. However, all this arguing over official package manager is worthless, IMO. Let the alternatives each stand on their own merits, just as we do with all sorts of other choices, optionally with one recommended for newbies who don't have any reason of their own to prefer one over another and likely with one used to build official media, but without any of them recognized as the /official/ package manager, because there's simply no continuing need for such a thing, once the extents and limits of acceptable package behavior at a particular API level has been appropriately speced out. If this approach were taken, it wouldn't have to affect releng much at all, certainly short term, since they could continue using portage, which is assumed to continue to be one of the recognized and accepted alternatives. Longer term, it would only as they found reason to switch to other alternatives, and if they didn't find such reason, well... It would affect bugs very little as well, since there are already bugs where it ends up being a package manager regression, only now, such regressions would be measured against the package spec, rather than against past behavior of any particular package manager (except as necessarily encoded in that spec, for the first version, anyway), and there'd now be a definitive way to say for sure whether it was the package manager or the package. Documentation, there'd necessarily be some adjustment. However, the documentary focus could remain on the recommended package manager, referring to the individual manager's documentation if they'd made a choice other than the recommended choice. Certainly, it
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: However, now that PMS is finally about to provide what should be a definitive description of current generation package behavior, with the announced intention to update this with new versions into the future as required, the dependence on portage as the reference will soon be going away. The announced intention for this, among other things, is to allow alternate package managers, such that it can still be clear when it's the package broken and when it's the package manager. From what I've read of the PMS, it currently only describes the input format it would accept (namely the format for ebuild files and their contents). This question can be delayed until the PMS defines the operation of the package manager, including but not limited to the recording of installed package data. If the package managers do not agree on which packages are installed or how to uninstall them, then they are not yet interchangeable. I apologize if this point has already been raised elsewhere in the thread. I try not to get involved in threads like this, but accidentally read a reply and thought this might be a valuable response. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGD6/0u7rWomwgFXoRAiT9AKCV/+YGLba3owSWEt/cbOPbyC3YrgCfbboE +oqnTwPBGzD7ORY15VwOxoo= =I3ta -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /{,usr/}bin path changed. What is the right solution for scripts?
On Sun, 2007-04-01 at 00:01 -0700, Alec Warner wrote:
One idea that comes to mind is /usr/bin/env $bin
And here we return to the problem that one day /usr/bin/env, could
become /bin/env... Or that /usr/ sometimes is not mounted during boot.
Thus, well. Seems that have sane PATH in the beginning of script is the
best solution.
On Sun, 2007-04-01 at 03:09 -0400, Mike Frysinger wrote:
On Sunday 01 April 2007, Alec Warner wrote:
For cron, one would need to set the PATH to something sane though.
i thought sane cron systems would setup a sane PATH for you:
/sbin:/usr/sbin:/bin:/usr/bin
At least fcron does not have default PATH compiled in. It inherits PATH
from environment. When we start fcron from init.d system it has some
default path set from /etc/init.d/function.sh (as Roy pointed).
Well. Thank you all for your answers. At least now I know that I have
not overlooked something trivial and seems that the best solution is to
set
PATH={PATH}:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
in the beginning of all shell scripts and to avoid usage of full path to
executable.
--
Peter.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] /{,usr/}bin path changed. What is the right solution for scripts?
On Sun, 01 Apr 2007 19:15:13 +0400 Peter Volkov [EMAIL PROTECTED] wrote: On Sun, 2007-04-01 at 00:01 -0700, Alec Warner wrote: One idea that comes to mind is /usr/bin/env $bin And here we return to the problem that one day /usr/bin/env, could become /bin/env... Or that /usr/ sometimes is not mounted during boot. env not being in /usr/bin will break an awful lot of stuff. It's listed in many textbooks as being the safe way of doing things. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] /{, usr/}bin path changed. What is the right solution for scripts?
On Sun, 01 Apr 2007 19:15:13 +0400 Peter Volkov [EMAIL PROTECTED] wrote: On Sun, 2007-04-01 at 00:01 -0700, Alec Warner wrote: One idea that comes to mind is /usr/bin/env $bin And here we return to the problem that one day /usr/bin/env, could become /bin/env... Or that /usr/ sometimes is not mounted during boot. On Gentoo, env is in /bin and /usr/bin /usr/bin/env is present on every unix system I've ever been on (I kind of make it a habit to check) and probably a ton I've never used ;) However using env really only makes sense in the #!/usr/bin/env foo case. Pretty much every other case you should be setting PATH to something proper in your script. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Flourish Conference Reminder
I just wanted to remind everyone that the Chicago Flourish Conference is coming up this weekend. Friday, April 6th and Saturday April 7th. If you are planning on attending be sure to mark you calendars and be sure to register on the website. The main website should have information on how to get to the conference, if you have any questions or concerns please feel free to contact me. Registration opens at 8 am, the presentations will be begin at 10 am on both Friday and Saturday. Don't forget to check out the hack-a-thon and come join us after the even at IBM's HQ for the post-flourish social. -- Samir Faci UIC LUG President Blog extract from main website -- Question to the world of Free and Open Source Software: What are my prospects when I graduate? As many of you know by now, for the last few months here at UIC*, we - the ACM* and g/LUG*,- have been eagerly working to put together a conference to discus FLOSS (Free/Libre Open Source Software) as an engine of innovation. The Flourish Conf. will take place next 6-7 of April at the University of Illinois at Chicago. I am a self confessed gnu/Linux user, I love gnu/Linux, free software and even open source - sorry RMS!. I am also a CS student at the University of Illinois at Chicago, and curiously enough, even though most of our curricula is done in Unix - we even have 2 RedHat labs here, - it appears as if none of the big players within FLOSS ever come to hire at UIC. Why is that Microsoft comes here semester after semester snatching some of the most brilliant students on campus? Yet, I have yet to see FLOSS big players to come out here looking for people. These has made me wonder: Is there a professional future in FLOSS? ... and I know I'm not alone in my wonders. To answer these questions, we have invited quite a few of really smart people from different organizations: Google, IBM, Red Hat, and the FSF, and we are going to have a a chance to hear about the opportunities that FLOSS has to offer for our future. We will have two panels, a talk on GPL v3, a talk on Google's contribution and use of FLOSS, among many other really interesting talks, etc. We have also put together a series of technical talks on FLOSS related technologies and topics, and a couple other really interesting activities to give attendees a chance to meet and to be met: Friday's Social mixer, and Saturday's Hack-a-Thon. This is not only going to be a great time for students around Chicago, this is going to be a great chance for community members, and companies to come together and explore how FLOSS is shaping up our future! Come and join us! Roberto C. Serrano g/LUG @ UIC vice-president
[gentoo-dev] Re: [soc] Python bindings for Paludis
Mike Auty [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 01 Apr 2007 14:13:24 +0100: From what I've read of the PMS, it currently only describes the input format it would accept (namely the format for ebuild files and their contents). This question can be delayed until the PMS defines the operation of the package manager, including but not limited to the recording of installed package data. If the package managers do not agree on which packages are installed or how to uninstall them, then they are not yet interchangeable. I apologize if this point has already been raised elsewhere in the thread. I try not to get involved in threads like this, but accidentally read a reply and thought this might be a valuable response. Thanks. It is valuable (and hasn't been already raised to my observation). As I understand it, they wouldn't necessarily be dynamically interchangeable, that is, on a live system (at least not without running some sort of conversion utility, which may or may not exist and may or may not lose some information in the conversion, defaulting the missing values). Rather, one could choose one and run with it, and only change with some work and/or loss of data. Practically speaking, at minimum, it is assumed the world file would normally either remain the same format or be convertible (automatically or by hand), and the USE flags would be convertible, so if install data were lost in the switch, one could at worst rebuild empty-tree world (in whatever PM lingo) to get the database in the new format if necessary. Thus, it's not something one would wish to switch back and forth willy nilly, but switching would be possible, with a bit of work. Of course, that assumes a package manager that even has the concept of the world file, I'd guess a /relatively/ safe assumption (and some form of USE flag handling is required by the spec). For those that didn't, well, a rather more painstaking individual package rebuild may be necessary to do the conversion. However, one might suppose those would be corner cases, and if someone wanted to go to the trouble, well... The point being, however, that all this quarreling about official package managers doesn't /really/ have to happen. Arguing Ciaran's viewpoint for a moment, if portage really is /that/ bad and future challenged, if official restrictions /do/ end up eliminating all other competition for official manager, well, it's entirely possible there'll be an official manager, and then there'll be the one (or more) everyone actually uses, again making arguing over an official PM much ado about nothing. That's one extreme. At the other, the alternatives just never go mainstream, regardless of whether they are officially blessed. Again, much ado about nothing. In the middle, multiple managers prove functional and are chosen by a reasonable segment of Gentoo users, regardless of official blessing or not, and again, it matters little what the official status is. I just don't see why so many are spending so much time arguing over it, when regardless, people are going to make their choices, and official status won't matter so much when people do so, because the package spec and what works is going to be the defining factor, not some official blessing, except indirectly as that affects further package spec updates. If that makes any sense and isn't entirely circular... it does (and isn't) to me, anyway. Certainly more so than what to me is pretty much bickering over nothing. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Flourish Conference Reminder
What the fuck is this spamming about? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Flourish Conference Reminder
Sorry guys, I didn't think this would be considered spam, I was actually hoping some of the gentoo dev, if any are in the area would be interesting in participating and representing gentoo in the conference. Since this is was seen as spam by some, I apologize. -- Samir On 4/1/07, Seemant Kulleen [EMAIL PROTECTED] wrote: What the fuck is this spamming about?
Re: [gentoo-dev] Flourish Conference Reminder
Samir Faci wrote: Sorry guys, I didn't think this would be considered spam, I was actually hoping some of the gentoo dev, if any are in the area would be interesting in participating and representing gentoo in the conference. Since this is was seen as spam by some, I apologize. Well this is a list about development... The forums are probably better suited for you: forums.gentoo.org George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: The point being, however, that all this quarreling about official package managers doesn't /really/ have to happen. [...] I just don't see why so many are spending so much time arguing over it, when regardless, people are going to make their choices, and official status won't matter so much when people do so, because the package spec and what works is going to be the defining factor, not some official blessing, except indirectly as that affects further package spec updates. I agree that the title official is nothing more than a title or label and will most likely be applied to the most common/popular manager. I think the reason for the discussion is that arguably Gentoo has been goal-less or at the very least major-project-less, and developers with vision are nervously looking for the direction to push the project. Personally, I'm very happy with Gentoo as is, it's flexible, I can add the packages I might find when browsing the web and it does everything I need. I don't need a major direction, or a big change, or an upheaval, or pretty much anything else, and I believe many of the less vocal developers feel similarly. However, for those that are looking for a change (and sunrise and seeds both seem recent evidence that a body of developers are looking for a change), then I think the alternative package manager is a nice big area with big uncertainty, given that it's well developed source-based package management is arguably the unique selling point of Gentoo. I think if someone were writing a new portage that simply took over from the old one one day, there would be nowhere near as much discussion. Therefore, the issue at the heart of these threads is the possibility of splintering of the project. There are quite clearly two sides. Those that would like to see multiple package managers: their reasoning is that they'd like to offer an alternative, with features and designs that would be difficult to integrate into the existing code, and some decisions that would break with the current design (albeit slightly). The other side doesn't necessarily fear another, better package manager, but fears that allowing multiple package managers will start to cause incompatibilities and will divide both the user group and the developer group. Overlays are a feature capable of this division, and already it's given rise to the seeds idea, which again met with the same dissent: that of divided time and resources spent on a number of smaller Gentoos, each with less popularity, less time devoted to each, and the difficulty of re-integration with the main branch. Nobody actively wants to break the main tree, but no one has yet figured out a way of ensuring that users do not encounter disruption if they decide to use a different package manager. The PMS is a step to overcome this by defining a standard, or interface, to ensure compatibility. So how can we smooth the way between the two sides? The best I can come up with is a more complete specification. One that includes both the package format, and the local state required to store data. The Pros for this, are that package managers could become interchangeable, to the point that it would never matter which package manager were in use at the time. The cons for this idea, are that it would slow down the development, changes and feature additions to the various managers, as the changes must first pass through the specification and then finally be implemented. We've already seen (with the introduction of Manifest2) that changes to the tree and distribution mechanism are slow at best (I believe manifest signing is over two years old and still not in place for every package?). Requiring adherence to a specification, and maintaining that specification will be even more difficult and slow, but it would allow both sides to move on, and work together towards the new direction. So now the question is, are we willing to accept the cons for the pros, or do we need to find a different solution. If not, then other package managers should invest their time in ratifying a specification quickly, so that they can get down to coding to the specification. Also, those against a new manager, should get down to agreeing the specification so that managers with the possibility of fracturing are bound within a framework of acceptability. As I see it, that leaves both sides working towards the same direction, and should give impetus to both groups to come to a common point as fast as possible. If not, then probably we should return to the drawing board, but I concur that bickering and worrying about the future without pinpointing the problem and trying to tackle it, is far more futile than working towards a viable solution... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux)
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-04-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-04-01 23h59 UTC. Removals: media-tv/rivatv 2007-03-26 05:02:39 mr_bones_ x11-plugins/gkrellm-console 2007-03-26 15:57:27 lack x11-plugins/gkrellm-logwatch2007-03-26 16:00:18 lack x11-plugins/gkrellmouse 2007-03-26 16:00:18 lack x11-plugins/gkrellm-sensors 2007-03-26 16:00:18 lack x11-plugins/gkrellmwho 2007-03-26 16:00:18 lack x11-libs/gtkDPS 2007-03-26 19:25:23 cardoe net-p2p/kenosis 2007-03-27 22:49:01 leio games-sports/toycars2007-03-28 07:25:50 mr_bones_ net-p2p/freenet 2007-03-28 09:13:55 armin76 dev-java/avalon-logkit-bin 2007-03-28 14:43:32 betelgeuse app-misc/pyge 2007-03-28 20:13:23 dev-zero x11-base/opengl-update 2007-03-29 01:13:28 eradicator sys-devel/gcc-powerpc64 2007-03-29 14:10:36 corsair dev-embedded/picptk 2007-03-31 11:13:22 calchan Additions: dev-embedded/srecord2007-03-26 19:42:59 calchan dev-util/bugle 2007-03-26 22:28:31 jokey mail-filter/policyd-weight 2007-03-26 22:31:07 ticho net-mail/dbmail 2007-03-26 23:51:52 ticho profiles/default-linux/arm 2007-03-28 04:28:45 beandog dev-ml/ocamlduce2007-03-28 16:07:03 aballier www-servers/ocsigen 2007-03-28 17:20:45 aballier dev-java/commons-vfs2007-03-29 15:53:56 betelgeuse virtual/c++-tr1-memory 2007-03-29 19:47:55 kugelfang virtual/c++-tr1-type-traits 2007-03-29 20:04:18 kugelfang virtual/c++-tr1-functional 2007-03-29 20:13:46 kugelfang app-misc/hal-info 2007-03-30 05:51:04 steev dev-perl/Gtk2-MozEmbed 2007-03-30 15:01:06 mcummings net-misc/nxnode 2007-03-30 16:06:27 voyageur net-misc/nxserver-freeedition 2007-03-30 16:14:32 voyageur media-libs/freeimage2007-03-31 05:55:07 nyhm dev-ruby/ruby-yadis 2007-03-31 08:02:11 robbat2 dev-ruby/ruby-openid2007-03-31 08:04:30 robbat2 net-dialup/umtsmon 2007-03-31 09:05:35 mrness games-arcade/snake3d2007-03-31 09:36:23 tupone media-video/ffmpegthumbnailer 2007-03-31 10:14:12 drac net-news/hellanzb 2007-03-31 10:14:42 aballier net-wireless/fsam7400 2007-03-31 21:26:08 genstef dev-java/junit-addons 2007-03-31 23:39:58 betelgeuse sys-apps/usbmon 2007-04-01 00:23:49 robbat2 games-board/pysol-cardsets 2007-04-01 21:41:02 tupone -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-tv/rivatv,removed,mr_bones_,2007-03-26 05:02:39 x11-plugins/gkrellm-console,removed,lack,2007-03-26 15:57:27 x11-plugins/gkrellm-logwatch,removed,lack,2007-03-26 16:00:18 x11-plugins/gkrellmouse,removed,lack,2007-03-26 16:00:18 x11-plugins/gkrellm-sensors,removed,lack,2007-03-26 16:00:18 x11-plugins/gkrellmwho,removed,lack,2007-03-26 16:00:18 x11-libs/gtkDPS,removed,cardoe,2007-03-26 19:25:23 net-p2p/kenosis,removed,leio,2007-03-27 22:49:01 games-sports/toycars,removed,mr_bones_,2007-03-28 07:25:50 net-p2p/freenet,removed,armin76,2007-03-28 09:13:55 dev-java/avalon-logkit-bin,removed,betelgeuse,2007-03-28 14:43:32 app-misc/pyge,removed,dev-zero,2007-03-28 20:13:23 x11-base/opengl-update,removed,eradicator,2007-03-29 01:13:28 sys-devel/gcc-powerpc64,removed,corsair,2007-03-29 14:10:36 dev-embedded/picptk,removed,calchan,2007-03-31 11:13:22 Added Packages: dev-embedded/srecord,added,calchan,2007-03-26 19:42:59 dev-util/bugle,added,jokey,2007-03-26 22:28:31 mail-filter/policyd-weight,added,ticho,2007-03-26 22:31:07 net-mail/dbmail,added,ticho,2007-03-26 23:51:52 profiles/default-linux/arm,added,beandog,2007-03-28 04:28:45 dev-ml/ocamlduce,added,aballier,2007-03-28 16:07:03 www-servers/ocsigen,added,aballier,2007-03-28 17:20:45 dev-java/commons-vfs,added,betelgeuse,2007-03-29 15:53:56 virtual/c++-tr1-memory,added,kugelfang,2007-03-29 19:47:55 virtual/c++-tr1-type-traits,added,kugelfang,2007-03-29 20:04:18 virtual/c++-tr1-functional,added,kugelfang,2007-03-29 20:13:46 app-misc/hal-info,added,steev,2007-03-30 05:51:04 dev-perl/Gtk2-MozEmbed,added,mcummings,2007-03-30 15:01:06 net-misc/nxnode,added,voyageur,2007-03-30 16:06:27 net-misc/nxserver-freeedition,added,voyageur,2007-03-30 16:14:32 media-libs/freeimage,added,nyhm,2007-03-31 05:55:07 dev-ruby/ruby-yadis,added,robbat2,2007-03-31 08:02:11 dev-ruby/ruby-openid,added,robbat2,2007-03-31 08:04:30 net-dialup/umtsmon,added,mrness,2007-03-31 09:05:35 games-arcade/snake3d,added,tupone,2007-03-31 09:36:23 media-video/ffmpegthumbnailer,added,drac,2007-03-31 10:14:12
