Re: [gentoo-user] modifying locally an ebuild
For a _great_ place to read about ebuilds go to: http://dev.gentoo.org/~plasmaroo/devmanual/ It has next to everything :) -- Naga -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
Fernando Canizo schreef: El 30/ago/2005 a las 22:36 -0300, Holly me decía: Normally what one would do is place all modified ebuilds in your PORTDIR_OVERLAY ... Thank you very much. You should take advice from Nick and make it a howto. I'm surely going to translate to spanish and put it in my blog, maybe i would add something if i get to make it work ;) Thanks, and more power to you! I can't make it work but it's after 2 AM and maybe i just need to read some docs. ebuild says: # ebuild /usr/local/portage/mail-client/mutt/mutt-conan-1.5.8-r2.ebuild digest !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified: !!!None !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified: !!!None doebuild(): aux_get() error reading mail-client/mutt-conan-1.5.8-r2; aborting. The probelm here is (likely) that the name of the package (for the purposes of the ebuild) is 'mutt-conan', not mutt. The format for an overlay folder (like Portage) is cat-egory/package-name/package-name.and-version.ebuild so your ebuild should likely be in /usr/local/portage/mail-client/mutt-conan/mutt-conan-1.5.8-r2.ebuild rather than just 'mutt'. I get caught by that one all the time to create the manifest file (so that Portage knows what files are associated with the ebuild, and can calculate their MD5 sums to check them for corruption when emerging). I did it by hand, first time, when modified ebuild in /usr/portage The thing is, that ebuilds in your overlay aren't overwritten or touched in any way by Portage, so you don't have to keep 'redoing' the ebuild every time you emerge sync. Cool, that's what i wanted. But i have to fix version in /etc/portage/packages.mask if i want to forbid mutt being upgraded, have i? Not necessarily, because your package is called mutt-conan, not mutt. So all you have to do is not emerge mutt-- as long as you don't emerge a package that depends on mutt, which I don't know if there are any, you should be good to go. If your package was called mutt, you could mask all versions above the one you used, just like you would for any other ebuild, but I wouldn't do that myself, because then how will you know if the package was upgraded (possibly folding in your changes, or, if not, nonetheless incorporating features that you might want in your modified ebuild anyway). In other words, not masking the original package makes it easier to know when to update your overlay ebuild, imo. You might want to check your virtuals, though, and/or package.provided, to let Portage know that mutt is provided by mutt-conan. If the ebuild in Portage hasn't changed, your modified ebuild will always be newer; if the ebuild in Portage has changed, it's quite likely that whatever patch or functionality you were waiting for has been merged into the main tree upstream, or backported into the ebuild, so you have an easy migration path back into main Portage (and of course, if you care enough about the application and its patchset to modify an ebuild and put it in your overlay, checking the ChangeLog of any updated ebuilds is not an onerous task). Well, i've not synced for a while, but i think sooner or later will do. Emm... the patch isn't going to be upstream soon if ever. I asked for some behaviour in mutt-user mailing list and someone give me this patch. Now i'm asking there to put it in the core, but that could not happen. Is this a behaviour that a significant portion of the mutt userbase might want? Or are you just weird ;) ? If you're just weird, use your overlay and be happy. If you think it might be useful to other mutt users, submit it to b.g.o (make sure to explain the circumstances so they don't go irritating upstream with a patch that upstream has no interest in). Or, if there's an unofficial 'mutt users' site or two, you could offer it to them to host, so that non-gentoo mutt users would have access to it as well. Or, if there's some way to 'modularize' mutt, you could look into turning the patch into a 'plugin' (if such things exist, I know nothing about mutt), so that it would be optional to those who wanted to use it. So that's the userland solution, but yes, if you want the patch included in Portage (which is likely to happen anyway, if it's a patch from upstream), the place to submit it for inclusion (preferably with the modified ebuild attached as well), would be bugs.gentoo.org (b.g.o). Well, maybe i try it, the patch is so simple that even if never gets to mutt core, i think it wouldn't do any damage to maintain it in gentoo. I can do that. :) Yes, you can. Isn't Gentoo great? Did you know yesterday that even you could contribute to development? $DEITY, I *love* that ! Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
On Wed, 31 Aug 2005 13:39:04 +0200, Holly Bostick wrote: Or, if there's some way to 'modularize' mutt, you could look into turning the patch into a 'plugin' (if such things exist, I know nothing about mutt), so that it would be optional to those who wanted to use it. Or you could add a USE flag, so the patch was only applied for those who want it. -- Neil Bothwick without C people would code in Basi, Pasal and Obol pgpRnjAb2WsJO.pgp Description: PGP signature
Re: [gentoo-user] modifying locally an ebuild
Neil Bothwick schreef: On Wed, 31 Aug 2005 13:39:04 +0200, Holly Bostick wrote: Or, if there's some way to 'modularize' mutt, you could look into turning the patch into a 'plugin' (if such things exist, I know nothing about mutt), so that it would be optional to those who wanted to use it. Or you could add a USE flag, so the patch was only applied for those who want it. I thought of that, but since I don't know what the patch is or does, I didn't know if that would be appropriate. Though, come to think of it, if there's local USE flags like GAPING_SECURITY_HOLE (forgot what ebuild that's on, but saw it again yesterday during a light world update, makes me laugh), or -insecure-drivers, I suppose that the patch could have its own USE flag, no matter what it does. But do you know the answer to Nick's question about what I said earlier? In a 'conflict' between two ebuilds of the same name and version, one in Portage and one in the overlay, does the choice of which one is used if I emerge the relevant package rely on which one is most recent(ly modified), or the location-- i.e., will the overlay ebuild always beat the Portage ebuild even if the Portage build is newer (because it was updated without changing the version number), or will the newer ebuild always win out, whether it's in overlay or main Portage? I think it's the latter, but I was tired when I wrote that, and offhand don't remember where to look it up to verify. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
El 31/ago/2005 a las 03:37 -0300, Nick me decía:
no no, you put the epatch command in your ebuild file (your own version
that you put in PORTAGE_OVERLAY.) Then the patch gets applied to the
mutt source file before compilation.
Ah... Already did that! In my modified ebuild what i did was to copy
lines from other patches and then adecuate them.
I don't understand this either, if i put something un *my* portage
tree the mirrors get infested?
no. lets start again.
there are two places that portage can get the patch from.
1. If it is small you can put it in ${FILESDIR} which is, in our case:
/usr/local/portage/mail-client/mutt/files/cool-all-mutt.patch
Then it is only on your system. If your revised ebuild gets accepted
into portage then the patch file will also get in the portage tree and
every gentooista will eventually get it via emerge sync.
2. If it is large, or if it is, for example, a commonly available public
patch (for example that some third party has published) then you can
instruct portage to download it from the net by specifying a SRC_URI,
viz:
SRC_URI=http://some.place.net/pub/patches/mutt/cool-all-mutt.patch;
You can do that in your private OVERLAY ebuild, and as you say you found
the patch on the net, that may be the best way to do it.
Cool, that's what i'll do.
Again, if your revised ebuild gets accepted and if the powers that be
get with it, the patch file might also get into the gentoo mirrors,
meaning that it is easier to get with more redundancy.
I'm gonna try to file the bug report asking for it to be in portage
this afternoon. (got to go running now)
--
Fernando Canizo - http://www.lugmen.org.ar/~conan/
QOTD:
I drive my car quietly, for it goes without saying.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
El 31/ago/2005 a las 08:39 -0300, Holly me decía: The probelm here is (likely) that the name of the package (for the purposes of the ebuild) is 'mutt-conan', not mutt. The format for an overlay folder (like Portage) is cat-egory/package-name/package-name.and-version.ebuild so your ebuild should likely be in /usr/local/portage/mail-client/mutt-conan/mutt-conan-1.5.8-r2.ebuild rather than just 'mutt'. I get caught by that one all the time And i get caught even after reading this. But now i read a second time and get that the *directory* where the ebuild remains *must* have the same name as the package. I didn't pay attentio to this: /usr/local/portage/ ... /mutt-conan/ ... But before realizing that i just changed the name back to *mutt* alone and the command run sucessfull. So i decided to let that way since emerge will tell from where comes the ebuild, as you say. I can't wait to see this tested, i'm doing a sync right now and gonna unfix mutt version in packages.mask so this afternoon will check what happens when i try to 'emerge mutt' (surely gonna be a new version) Is this a behaviour that a significant portion of the mutt userbase might want? Or are you just weird ;) ? Well, you use thunderbird, so maybe you're more like a mouse user. This is the thing: in mutt you can flag a message as important (you got only one flag), also you have a 'ctrl-d' command that deletes a full thread. Sometimes threads get off-topic (an unconstructive flame for example) and when i realize that, and don't like the new topic i just 'ctrl-d' them. But what if i've flagged some message? It means that it's important to me, so i wanted to remain undeleted. The actual behaviour of mutt just delete everything. That's what the patch provides me, and with a single line of code. Simple. And David (the autor) do it so well that even added a new option for it to be in '~/muttrc' and let the default to be the old behaviour. So i think this patch can get to portage easily. By the way, if anyone interested, this is it: http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.8.dgc.flagsafe.1 If you think it might be useful to other mutt users, submit it to b.g.o Doing this later. :) Yes, you can. Isn't Gentoo great? Did you know yesterday that even you could contribute to development? $DEITY, I *love* that ! Yeah! I think it's time to read Nagatoro link now. -- Fernando Canizo - http://www.lugmen.org.ar/~conan/ #if 0 linux-2.2.16/fs/buffer.c -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
On Wed, 31 Aug 2005 14:42:16 +0200, Holly Bostick wrote: But do you know the answer to Nick's question about what I said earlier? In a 'conflict' between two ebuilds of the same name and version, one in Portage and one in the overlay, does the choice of which one is used if I emerge the relevant package rely on which one is most recent(ly modified), or the location-- i.e., will the overlay ebuild always beat the Portage ebuild even if the Portage build is newer (because it was updated without changing the version number), or will the newer ebuild always win out, whether it's in overlay or main Portage? The overlay takes priority, even if the file date in the main portage tree is newer. It's easy to test. copy a directory from the main tree to your overlay, touch the latest ebuild in the main tree and emerge -pv the package. You'll see that emerge picks the overlay version. I noticed this when I wrote my own ebuild for a package and then someone put it in portage. The first I new was when they released an r1 ebuild and emerge --update world picked it up. When you think about it, the very name overlay indicates that this is how it should work. -- Neil Bothwick I have had a perfectly wonderful evening, but this wasn't it. pgpj8srpnXHJb.pgp Description: PGP signature
Re: [gentoo-user] modifying locally an ebuild
Neil Bothwick schreef: On Wed, 31 Aug 2005 14:42:16 +0200, Holly Bostick wrote: But do you know the answer to Nick's question about what I said earlier? In a 'conflict' between two ebuilds of the same name and version, one in Portage and one in the overlay, does the choice of which one is used if I emerge the relevant package rely on which one is most recent(ly modified), or the location-- i.e., will the overlay ebuild always beat the Portage ebuild even if the Portage build is newer (because it was updated without changing the version number), or will the newer ebuild always win out, whether it's in overlay or main Portage? The overlay takes priority, even if the file date in the main portage tree is newer. OK, now that I'm thinking about it more (given that I'm actually awake now), I do remember that I had to remove my overlay build of taskjuggler in order to emerge the one that had been included in Portage. So I was mistaken. It can happen, sorry ;) . Which is why, of course, I asked you, Neil (because you know, like, everything, just about :D ). It's easy to test. copy a directory from the main tree to your overlay, touch the latest ebuild in the main tree and emerge -pv the package. You'll see that emerge picks the overlay version. You should know better than using the phrase 'it's easy' and the command 'touch' whatever in the same sentence when you're talking to me :) . I kinda know how to 'touch', and I just learned how to 'grep' simple strings (the operative word being 'simple'). It *is* easy, but honestly, I'm well known to be the village idiot when it comes to the CLI, so your easy test doesn't come naturally to me at all. :P But it's good to be reminded of how such things can quickly be done. Repeat it often enough, and it might even get caught in the sieve that can be my brain. I noticed this when I wrote my own ebuild for a package and then someone put it in portage. The first I new was when they released an r1 ebuild and emerge --update world picked it up. Yes, I think that's what happened to me with taskjuggler as well. When you think about it, the very name overlay indicates that this is how it should work. I suppose there's no way to avoid there being *some* issue-- this way, you have to actively watch Portage to see if today is perhaps the happy day that your overlay build is obsoleted; the other way, Portage would be obsoleting your overlay build arbitrarily. I don't see either of these as optimal conditions (since the goal, imo, is to be using Portage builds and as few overlay builds as possible, and neither of these conditions gives you a painless way to Return To Portage, as it were), but I agree that the way it's currently done is the better of two sub-optimal choices. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
Fernando Canizo schreef: Is this a behaviour that a significant portion of the mutt userbase might want? Or are you just weird ;) ? Well, you use thunderbird, so maybe you're more like a mouse user. Yes, but I'm getting over it. Also I need to know how to work with at least one CLI email client in the event that I don't have X available (I have a fallback no-X alternative backend set up for most basic functionality, exept email-- and heaven knows I never want to have to try and read my ISP's webmail via lynx/elinks). This is the thing: in mutt you can flag a message as important (you got only one flag), also you have a 'ctrl-d' command that deletes a full thread. Sometimes threads get off-topic (an unconstructive flame for example) and when i realize that, and don't like the new topic i just 'ctrl-d' them. But what if i've flagged some message? It means that it's important to me, so i wanted to remain undeleted. The actual behaviour of mutt just delete everything. That's what the patch provides me, and with a single line of code. Simple. And David (the autor) do it so well that even added a new option for it to be in '~/muttrc' and let the default to be the old behaviour. So i think this patch can get to portage easily. By the way, if anyone interested, this is it: http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.8.dgc.flagsafe.1 That really sounds incredibly useful. I can't imagine why upstream wouldn't include that functionality. But obviously I know nothing about Mutt, much less Mutt development goals. If you think it might be useful to other mutt users, submit it to b.g.o Doing this later. Glad to hear it. I'm sure I'll want it if I ever get around to using Mutt. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
On Wed, 31 Aug 2005 16:06:17 +0200, Holly Bostick wrote: When you think about it, the very name overlay indicates that this is how it should work. I suppose there's no way to avoid there being *some* issue-- this way, you have to actively watch Portage to see if today is perhaps the happy day that your overlay build is obsoleted; the other way, Portage would be obsoleting your overlay build arbitrarily. As long as your build is working the portage one wouldn't really obsolete it. However, if you've altered an ebuild to suit your needs, you don't want it replacing by the portage one just because the dev has corrected a typo in a comment, altering the file's date. I don't see either of these as optimal conditions (since the goal, imo, is to be using Portage builds and as few overlay builds as possible, and neither of these conditions gives you a painless way to Return To Portage, as it were), but I agree that the way it's currently done is the better of two sub-optimal choices. I suppose it would be possible to write a script that compares the ebuild of everything you have installed from an overlay with the main portage tree and warns you if there's been an update. -- Neil Bothwick Blessed be the pessimist for he hath made backups. pgpruXNlp4Omo.pgp Description: PGP signature
Re: [gentoo-user] modifying locally an ebuild
Fernando Canizo schreef: Hi all, I find a cute patch to mutt and to use it i modified the ebuild and the pertinent files so now re-emerging mutt builds mutt with this patch. Later i fixed the actual version of mutt so an upgrade cannot erase it. What i would like to know is how can i do this i a 'gentoo way'. I have listen that there are something called SLOTs, but never used so far (never need them?) Or the only way is to propose the add of the patch to portage? Normally what one would do is place all modified ebuilds in your PORTDIR_OVERLAY (Portage directory overlay), which location can be set in /etc/make.conf (default is /usr/local/portage). /usr/local/portage has the same structure as the 'normal' portage tree, meaning that your ebuild would need to be placed in /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild, and the currently-existing patch files would need to be copied to /usr/local/portage/mail-client/mutt/files, along with your additional patch. You would then use the command ebuild /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild digest to create the manifest file (so that Portage knows what files are associated with the ebuild, and can calculate their MD5 sums to check them for corruption when emerging). At that point, because your ebuild is newer than the one in Portage, when you emerge mutt, your overlay ebuild is considered most recent, and you will see it when you attempt to emerge as follows (this example of course uses a different ebuild because mutt isn't in my overlay): emerge -pv unace cfg-update 1.7.1 : Building checksum index... (takes a few seconds) done! These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-arch/unace-2.2 178 kB [1] Total size of downloads: 178 kB Portage overlays: [1] /usr/local/portage [2] /usr/local/bmg-main As you see, the emerge data is footnoted with a [1], and the legend says that the ebuild comes from my first overlay, in /usr/local/portage. The thing is, that ebuilds in your overlay aren't overwritten or touched in any way by Portage, so you don't have to keep 'redoing' the ebuild every time you emerge sync. If the ebuild in Portage hasn't changed, your modified ebuild will always be newer; if the ebuild in Portage has changed, it's quite likely that whatever patch or functionality you were waiting for has been merged into the main tree upstream, or backported into the ebuild, so you have an easy migration path back into main Portage (and of course, if you care enough about the application and its patchset to modify an ebuild and put it in your overlay, checking the ChangeLog of any updated ebuilds is not an onerous task). If the program has been updated, but your patch still isn't there, then you can just copy and modify the updated ebuild and files. So that's the userland solution, but yes, if you want the patch included in Portage (which is likely to happen anyway, if it's a patch from upstream), the place to submit it for inclusion (preferably with the modified ebuild attached as well), would be bugs.gentoo.org (b.g.o). That's where most of the ebuilds in my overlay come from :) . The nice things about submitting the modified ebuild in this way are that 1) it makes less work for the devs (they don't have to write the ebuild, only check/correct yours); 2) if for some reason they are delayed in, or don't want to, include the ebuild into Portage (as is the case with the unace ebuild in the example above), it's still available for those crazy or desperate enough to want to use it anyway. 3) it helps people willing to debug to do so-- I'm fairly sure that those of us who contributed to debugging the taskjuggler ebuild helped the ebuild become better, faster, so that it was recently included in Portage (though I can't compile it for some reason, gotta revisit that bug, actually). Hope that helps answer your question. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
On Wed, 31 Aug 2005 03:36:57 +0200
Holly Bostick wrote:
Fernando Canizo schreef:
Hi all,
I find a cute patch to mutt and to use it i modified the ebuild and
the pertinent files so now re-emerging mutt builds mutt with this
patch. Later i fixed the actual version of mutt so an upgrade cannot
erase it.
What i would like to know is how can i do this i a 'gentoo way'. I
have listen that there are something called SLOTs, but never used so
far (never need them?)
Or the only way is to propose the add of the patch to portage?
[snip]
If the ebuild in Portage hasn't changed, your modified ebuild will
always be newer; if the ebuild in Portage has changed, it's quite likely
that whatever patch or functionality you were waiting for has been
merged into the main tree upstream, or backported into the ebuild, so
you have an easy migration path back into main Portage (and of course,
if you care enough about the application and its patchset to modify an
ebuild and put it in your overlay, checking the ChangeLog of any updated
ebuilds is not an onerous task).
If the program has been updated, but your patch still isn't there, then
you can just copy and modify the updated ebuild and files.
[snip]
Good post Holly, you should make it into a howto.
2 things spring to mind:
1. i thought that overlay always beats normal portage, but you are
saying newer ebuild file wins (ie if the official ebuild has been
updated but not renamed it will beat what is in overlay. ) - do you have
any reference for that (I sure don't, its just how I thought it worked)
2. Fernando might like to note that the way to introduce a patch to a
package (rather than an amendment to the ebuild) is to use the epatch
command. Commonly the line looks like this:
epatch ${FILESDIR}/cool-all-mutt.patch
In that case the patch is in the files directory below the ebuild file.
If the patch is large or publicly available, you are better NOT to put
it in the portage tree but have it downloaded from a mirror with e
SRC_URI command. If you want an example of this take a look at the
vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
the other day)
--
gentoo-user@gentoo.org mailing list
--
Nick Rout [EMAIL PROTECTED]
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
El 30/ago/2005 a las 22:36 -0300, Holly me decía: Normally what one would do is place all modified ebuilds in your PORTDIR_OVERLAY ... Thank you very much. You should take advice from Nick and make it a howto. I'm surely going to translate to spanish and put it in my blog, maybe i would add something if i get to make it work ;) I can't make it work but it's after 2 AM and maybe i just need to read some docs. ebuild says: # ebuild /usr/local/portage/mail-client/mutt/mutt-conan-1.5.8-r2.ebuild digest !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified: !!!None !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified: !!!None doebuild(): aux_get() error reading mail-client/mutt-conan-1.5.8-r2; aborting. to create the manifest file (so that Portage knows what files are associated with the ebuild, and can calculate their MD5 sums to check them for corruption when emerging). I did it by hand, first time, when modified ebuild in /usr/portage The thing is, that ebuilds in your overlay aren't overwritten or touched in any way by Portage, so you don't have to keep 'redoing' the ebuild every time you emerge sync. Cool, that's what i wanted. But i have to fix version in /etc/portage/packages.mask if i want to forbid mutt being upgraded, have i? If the ebuild in Portage hasn't changed, your modified ebuild will always be newer; if the ebuild in Portage has changed, it's quite likely that whatever patch or functionality you were waiting for has been merged into the main tree upstream, or backported into the ebuild, so you have an easy migration path back into main Portage (and of course, if you care enough about the application and its patchset to modify an ebuild and put it in your overlay, checking the ChangeLog of any updated ebuilds is not an onerous task). Well, i've not synced for a while, but i think sooner or later will do. Emm... the patch isn't going to be upstream soon if ever. I asked for some behaviour in mutt-user mailing list and someone give me this patch. Now i'm asking there to put it in the core, but that could not happen. So that's the userland solution, but yes, if you want the patch included in Portage (which is likely to happen anyway, if it's a patch from upstream), the place to submit it for inclusion (preferably with the modified ebuild attached as well), would be bugs.gentoo.org (b.g.o). Well, maybe i try it, the patch is so simple that even if never gets to mutt core, i think it wouldn't do any damage to maintain it in gentoo. I can do that. Hope that helps answer your question. Sure it does! -- Fernando Canizo - http://www.lugmen.org.ar/~conan/ Renning's Maxim: Man is the highest animal. Man does the classifying. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] modifying locally an ebuild
El 31/ago/2005 a las 00:23 -0300, Nick me decía:
2. Fernando might like to note that the way to introduce a patch to a
package (rather than an amendment to the ebuild) is to use the epatch
command. Commonly the line looks like this:
You're saying that i can emerge mutt, run epatch command and then
re-emerge and assumes the patch? It sounds crazy for me, maybe i don't
understand.
epatch ${FILESDIR}/cool-all-mutt.patch
I see that command in ebuilds, but where is it? I can't find it in my
installation, but somewhere must be since it gets used.
If the patch is large or publicly available, you are better NOT to put
it in the portage tree but have it downloaded from a mirror with e
SRC_URI command. If you want an example of this take a look at the
vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
the other day)
I don't understand this either, if i put something un *my* portage
tree the mirrors get infested?
(hum... better get some sleep now, i'm understanding less after each
minute)
--
Fernando Canizo - http://www.lugmen.org.ar/~conan/
lighthouse, n.:
A tall building on the seashore in which the government
maintains a lamp and the friend of a politician.
--
gentoo-user@gentoo.org mailing list
