Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sun, 05 Aug 2007 01:56:47 +0200
Jurek Bartuszek <[EMAIL PROTECTED]> wrote:
> Just thinking aloud - why not add some (QA?) notice in the summary
> when dodoc (and possibly other do*'s) fails? One would be instructed
> to file a new bug when he sees it *and*, after all, the package will
> have still been merged successfuly.
That's already in place. dodoc does the following:
echo "dodoc: ${x} does not exist" 1>&2
and anything in stderr is reported as a QA notice. All done. BAM!
Kind regards,
JeR
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] kxdocker (and associated packages is being purged)
The following packages have been masked pending removal in 30 days (roughly): kde-misc/kxdocker-configurator kde-misc/kxdocker-i18n kde-misc/kxdocker-dcop kde-misc/kxdocker kde-misc/kxdocker-trayiconlogger kde-misc/kxdocker-resources Reasons: - no developed by upstream [1] - no active maintainer [2] These are still available in the xeffects overlay for those who want them [3]. [1] http://www.xiaprojects.com/www/prodotti/kxdocker/main.php?action=download [2] https://bugs.gentoo.org/show_bug.cgi?id=124159#c3 [3] http://www.gentoo.org/proj/en/overlays/userguide.xml -- Daniel Black <[EMAIL PROTECTED]> Gentoo Foundation pgpvljmlQRs82.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-2 stablisation plans
On Tue, 2007-07-24 at 21:31 +0300, Alon Bar-Lev wrote: > Just an issue I thought a long while ago... > What about adding USE flags for all optional networking components... > So that they installed without manually merging them one by one? Too many use flags - simply install the package. In the future, once the API for out network scripts doesn't change then we will punt the scripts to the packages. I don't want baselayout to rival PHP in terms of USE flags - heh. Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Tiziano Müller wrote: > Chris Gianelloni schrieb: >> - arch-specific patches/dependencies - If someone is requesting KEYWORD >> changes on a package and it requires a patch or additional dependencies >> for your architecture, you are not only permitted, but really are >> required to make the necessary changes to add support for your >> architecture. > And what is going to happen with the patch? Should go upstream, but > who's responsible for that? > Er, the maintainer; if s/he's not bothered about the package compiling on different archs, should s/he really be maintaining it? I doubt upstream would appreciate that from a distro -- and it's not hard to file a quick bug with a link to the gentoo one; a quick comment on the gentoo one and any interested users can help upstream to triage it. >> - metadata.xml changes > With limitations. > Maintainer sounds like a definite no-no. Any others? >> - Version bumps where the only requirement is to "cp" the ebuild > Just "cp"'ing the ebuilds is the reason that so many ebuilds are still a > nightmare and full of little nasty bugs. > > This is a complete no-go since there are so many things a careful > maintainer has to consider (besides checking the packages changelog, the > dependencies, the license, the docs, etc. he should also check the > ebuild). > Yeah but if they can compile it and it works as an app (however that's defined, this /is/ usr-land) what's the harm in bumping and allowing others to test it? (This is unstable, I hope..) If they can't be bothered to do that, how can they possibly claim to be testing it? (And why are they even touching it if they're not interested? ;) [I dunno how make test fits into this, either, as tests were broken for synfig.] If the maintainer doesn't like it, well s/he's already got the new version working on one arch/ machine (plus whichever user bugged the dev.) I can't see anyone really bemoaning a new tester ;P -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Vlastimil Babka wrote: > > dodoc calls should have || die and USE=doc should be tested before > commiting a bump, IMHO > Would it not be easier to roll the || die into dodoc? I know some eclass functions die on error, but I haven't been able to find out what the definitive list is, or at least the policy on how it's decided whether a call should die. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Petteri Räty wrote: > Steev Klimaszewski kirjoitti: >> Vlastimil Babka wrote: >> >>> dodoc calls should have || die and USE=doc should be tested before >>> commiting a bump, IMHO >>> >> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die >> because TODO wasn't around. Vote against || die - it doesn't affect >> anything aside from misc docs not being installed, if its really that >> important, most people hit the website anyway. (But yes, they should be >> corrected and tested before committing) >> > > And is the average ebuild 3 hours and haven't you heard about FEATURES > noauto? The || die is there for maintainers to spot when version > bumping. If you commit a version that's broken with missing TODO and || > die you should think about if you are doing everything right... > Just thinking aloud - why not add some (QA?) notice in the summary when dodoc (and possibly other do*'s) fails? One would be instructed to file a new bug when he sees it *and*, after all, the package will have still been merged successfuly. Best regards, Jurek Bartuszek -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Gilles Dartiguelongue wrote: Le samedi 04 août 2007 à 16:23 -0500, Andrew Gaffney a écrit : The LiveCD is intended to replace the separate GRP and universal CDs when combined with the installer. The installer uses the packages installed on the CD to do the new install. I'm not sure how many times this has been brought up on this list. You people need to pay attention ;) err, sorry I'm here since 9th june only. I should have check the archives :) I guess I'll let it slide this time, then :) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Le samedi 04 août 2007 à 16:23 -0500, Andrew Gaffney a écrit : > The LiveCD is intended to replace the separate GRP and universal CDs when > combined with the installer. The installer uses the packages installed on the > CD > to do the new install. I'm not sure how many times this has been brought up > on > this list. You people need to pay attention ;) > err, sorry I'm here since 9th june only. I should have check the archives :) -- Gilles Dartiguelongue <[EMAIL PROTECTED]> Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] default desktop profile
Gilles Dartiguelongue wrote: Le samedi 04 août 2007 à 09:08 +0300, Samuli Suominen a écrit : On Fri, 03 Aug 2007 14:28:26 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: We disabled it to try to get the size of the x86/amd64 LiveCDs down. Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Glad to hear that. Then maybe we could add some stages to livecd? Replace evolution with something usable like claws-mail to do so. why would you need a mailer at all on a livecd ? Is the livecd intended to provide a full desktop experience whichever desktop is chosen or is it just provided as a way to have something to do while you are installing and/or tools to fix your install ? if it's not intended to be a full desktop experience (garnome does it very well for gnome afaik) then you could install only gnome-light for a start. The LiveCD is intended to replace the separate GRP and universal CDs when combined with the installer. The installer uses the packages installed on the CD to do the new install. I'm not sure how many times this has been brought up on this list. You people need to pay attention ;) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Samuli Suominen wrote: On Fri, 03 Aug 2007 14:28:26 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: We disabled it to try to get the size of the x86/amd64 LiveCDs down. Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Glad to hear that. Then maybe we could add some stages to livecd? Replace evolution with something usable like claws-mail to do so. The saved space (~105MB with my test build right after 2007.0) would only allow for one stage tarball (the i686 2007.0 stage3 was 103MB, for example), and then we'd be right back where we were with keeping the ISO under 700MB. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Luis Medinas wrote: On Fri, 2007-08-03 at 14:28 -0700, Chris Gianelloni wrote: Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Sad to know that our livecd will be xfce based. I think the current live cd gnome based provides a much better environment than xfce and that is good for the users who will preform and instalation. Of course you don't need to build all gnome for the livecd and i bet there will be enough space for another tools (a graphical package manager!?). The main reason that releng has decided to replace gnome with xfce for the LiveCD is space. We (Kugelfang, wolf31o2, and I) had a hell of a time this last release getting the x86/amd64 LiveCDs under 700MB, mostly because many packages (including gnome) grew a bit since the last release. With no differences other than s:gnome-base/gnome:xfce-base/xfce4:, the resulting ISO dropped ~105MB. That's a *lot* of breathing room and a *lot* less headaches for the people building the media. Unless you can magically pull some space out of your butt, don't complain :P -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Steev Klimaszewski kirjoitti: > Vlastimil Babka wrote: > >> dodoc calls should have || die and USE=doc should be tested before >> commiting a bump, IMHO >> > > Sorry, I didn't realize my 3 hour compile of $APPLICATION should die > because TODO wasn't around. Vote against || die - it doesn't affect > anything aside from misc docs not being installed, if its really that > important, most people hit the website anyway. (But yes, they should be > corrected and tested before committing) > And is the average ebuild 3 hours and haven't you heard about FEATURES noauto? The || die is there for maintainers to spot when version bumping. If you commit a version that's broken with missing TODO and || die you should think about if you are doing everything right... Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Chris Gianelloni schrieb: - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. And what is going to happen with the patch? Should go upstream, but who's responsible for that? - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. This isn't simple. I know a couple of packages where there's more than one upstream and there might be a good reason to not use the original one. But I admit that this is corner case. - metadata.xml changes With limitations. - Version bumps where the only requirement is to "cp" the ebuild Just "cp"'ing the ebuilds is the reason that so many ebuilds are still a nightmare and full of little nasty bugs. This is a complete no-go since there are so many things a careful maintainer has to consider (besides checking the packages changelog, the dependencies, the license, the docs, etc. he should also check the ebuild). Cheers, Tiziano -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Commitlog-mailinglist
Lars Weiler wrote: > * Robin H. Johnson <[EMAIL PROTECTED]> [07/08/03 16:20 -0700]: >> X-VCS-Repository: gentoo-x86 >> X-VCS-Directories: profiles/ licenses/ >> X-VCS-Files: profiles/foo licenses/bar > > Everything implemented :-P At least for all commits to > gentoo-x86. > > Well, I reactivated the commitlog-script (quite the same we > use for the gentoo-doc-cvs-list) and added some more > Headers to it. Currently I'm testing it with messages sent > to my own address as it seems that the old commit-list is > deactivated. > > With the new VCS-server it should not cause any overhead and > with a real MTA on that machine those messages will be > queued even if our mailserver is not running. > > So, if you want, we can reactivate that list. Pylon, you rock! Now that everything's working, let's get the -commits list reactivated. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2007-08-02 at 20:35 -0700, Donnie Berkholz wrote: > > Update your knowledge, the normal radeon driver works nice for both. =) I will I was following radeon developmen for a while. But last I looked a few months ago, they were still a ways off from having DRI fully supported with my hardware. Which is now ruffly 2-3 years old Xpress200m. So I am sticking with ati-drivers, and only use radeon if and when I have problems there. Which has been quite some time. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2.6.22 stable plans
On Saturday 04 August 2007, William L. Thomson Jr. wrote: > On Fri, 2007-08-03 at 00:14 -0400, Mike Frysinger wrote: > > my point though wasnt to knock ati (although it was fun), the point was > > that i do not believe any closed source driver in our tree should ever be > > grounds for preventing stabilization of a kernel ebuild > > Yes, I don't like that it's closed source either. But closed or open > source. It seems odd to have packages in our stable tree that don't work > with each other? Doesn't that kinda go against the point of our stable > tree? then dont stabilize the closed source packages, problem solved > I personally don't use genkernel, but I believe those updating their > systems via emerge world, and then running genkernel later against the > new kernel. Will likely have it fail, and then report bugs against our > stable tree. boy thats sure a pickle when we cant do s**t about it (maybe *this* time we can fix it, but that is not always the case) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Vlastimil Babka wrote: dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO Sorry, I didn't realize my 3 hour compile of $APPLICATION should die because TODO wasn't around. Vote against || die - it doesn't affect anything aside from misc docs not being installed, if its really that important, most people hit the website anyway. (But yes, they should be corrected and tested before committing) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Jeroen Roovers wrote: On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. Another good candidate is correcting errors in anything dodoc is tasked to install. When a TODO or other metafile goes missing in the course of development, I often find ebuilds that still mention them. When I haven't done my arch commit yet, I often correct the error after I check whether the file has simply been moved, by either correcting the path or removing the filename from the dodoc call. dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Fri, 2007-08-03 at 00:14 -0400, Mike Frysinger wrote: > On Thursday 02 August 2007, William L. Thomson Jr. wrote: > > On Thu, 2007-08-02 at 20:05 -0400, Mike Frysinger wrote: > > > sounds good to me ... so to tie back to the source of the thread, crappy > > > closed source vendor drivers are not a valid reason to hold up > > > stabilization of a kernel > > > > Who ever said they were crappy? Maybe the documentation on usage is > > crappy, but drivers have consistently gotten much better. These days > > pretty solid IMHO for my uses. > > last time i used the drivers they sucked hard ... maybe it's gotten better; i > dont know -- i tossed all my ati in favor of nvidia Well ati's stuff has gotten much better over the last year. But really IMHO from my experience. It's entirely about your xorg.conf. Wrong config or etc and it will totally blow. In that regard nVidia seems to be way more tolerant, and maybe detects stuff at runtime, ati requires to be configed in xorg.conf. > my point though wasnt to knock ati (although it was fun), the point was that > i > do not believe any closed source driver in our tree should ever be grounds > for preventing stabilization of a kernel ebuild Yes, I don't like that it's closed source either. But closed or open source. It seems odd to have packages in our stable tree that don't work with each other? Doesn't that kinda go against the point of our stable tree? I personally don't use genkernel, but I believe those updating their systems via emerge world, and then running genkernel later against the new kernel. Will likely have it fail, and then report bugs against our stable tree. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2.6.22 stable plans
On Thu, 2007-08-02 at 20:35 -0700, Donnie Berkholz wrote: > William L. Thomson Jr. wrote: > > FYI, the patches in bug #183480 [1] allow one to use the most current > > ati-drivers with a 2.6.22 kernel. As I am now while I am composing this > > message. Having applied said patches and bumped ebuild locally. Just > > needs to happen in tree :) > > 01 Aug 2007; Jeff Gardner <[EMAIL PROTECTED]> > +files/8.37.6/fix-ioctl-for-2.6.22.patch, ati-drivers-8.37.6-r1.ebuild: > Add patch to allow compilation with 2.6.22 kernels. See bug #182597. Thanks, hope I didn't come off as bitching about it needing to be committed. Just pointing it out :) But we are all good know, I should have grown a pair and committed it myself :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > There's a couple more that I wouldn't mind seeing as things developers > can do without the maintainer, but I can see how these might be a bit > more controversial, so I'm asking for input. Another good candidate is correcting errors in anything dodoc is tasked to install. When a TODO or other metafile goes missing in the course of development, I often find ebuilds that still mention them. When I haven't done my arch commit yet, I often correct the error after I check whether the file has simply been moved, by either correcting the path or removing the filename from the dodoc call. Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
Steve Long wrote: Alec Warner wrote: Ask for forgiveness, not permission. ++ I think anything that streamlines the process is a good thing. (Obviously I don't know enough about all the changes to comment on specifics.) Not saying it should be done recklessly, eg SRC_URI changes. How about a simple requirement that anyone who changes something test it before committing? (Isn't this already there?) I assume there is already a policy that devs take responsibility for any changes they make.. (That fits with "you broke it, you fix it" [or have it fixed, i guess.;]) In general, while there are a lot of bad things that *can* happen when bumping a package, in most cases they don't. In the cases they do, the dev that bumped should take responsibility. I believe users will be understanding...ricing does have some risks, after all. :) ++ Thanks, Marty -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Le samedi 04 août 2007 à 09:08 +0300, Samuli Suominen a écrit : > On Fri, 03 Aug 2007 14:28:26 -0700 > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > > We disabled it to try to get the size of the x86/amd64 LiveCDs down. > > Thanks. I knew there had to be some reason for it, but couldn't > > remember what it was off the top of my head. Luckily, this won't be > > much of an issue with the next release, since we're switching to Xfce > > rather than GNOME to bring the size down even further and to try to > > produce a more useful (as in more tools) LiveCD. Of course, the > > LiveDVD will have everything on it, as it does now. > > Glad to hear that. Then maybe we could add some stages to livecd? > Replace evolution with something usable like claws-mail to do so. why would you need a mailer at all on a livecd ? Is the livecd intended to provide a full desktop experience whichever desktop is chosen or is it just provided as a way to have something to do while you are installing and/or tools to fix your install ? if it's not intended to be a full desktop experience (garnome does it very well for gnome afaik) then you could install only gnome-light for a start. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Alec Warner wrote: > Ask for forgiveness, not permission. ++ I think anything that streamlines the process is a good thing. (Obviously I don't know enough about all the changes to comment on specifics.) Not saying it should be done recklessly, eg SRC_URI changes. How about a simple requirement that anyone who changes something test it before committing? (Isn't this already there?) I assume there is already a policy that devs take responsibility for any changes they make.. (That fits with "you broke it, you fix it" [or have it fixed, i guess.;]) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Commitlog-mailinglist (was: Re: Some ideas on how to reduce territoriality)
* Robin H. Johnson <[EMAIL PROTECTED]> [07/08/03 16:20 -0700]: > X-VCS-Repository: gentoo-x86 > X-VCS-Directories: profiles/ licenses/ > X-VCS-Files: profiles/foo licenses/bar Everything implemented :-P At least for all commits to gentoo-x86. Well, I reactivated the commitlog-script (quite the same we use for the gentoo-doc-cvs-list) and added some more Headers to it. Currently I'm testing it with messages sent to my own address as it seems that the old commit-list is deactivated. With the new VCS-server it should not cause any overhead and with a real MTA on that machine those messages will be queued even if our mailserver is not running. So, if you want, we can reactivate that list. Regards, Lars -- Lars Weiler <[EMAIL PROTECTED]> +49-171-1963258 Instant Messaging : [EMAIL PROTECTED] Gentoo Linux PowerPC : Developer Gentoo Infrastructure : CVS Administrator pgp3DdEthaSrr.pgp Description: PGP signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Ask for forgiveness, not permission. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:49:58 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Why should someone have to go through all of that just to make these > minor fixes? Is it really necessary for someone to be required to try > to track down and contact the maintainer to tell them that they put > "ebiuld" instead of "ebuild" into an ebuild? This is my entire point. > Why are we forcing a process that only fosters inefficiency? It is > much simpler to say "if you see one of these, fix it" than to force > every single action to go through the maintainer. Well, for simple typos it's ok. But some of the things you listed might have a bigger impact: SRC_URI changes are ok when the actual files are the same, but if they are somehow different one should really check wih the maintainer to make sure it's still the correct file (same for verifying checksums, unless it's obvious). In the end it comes down that you have to know the consequences of a change, and assuming that the maintainer knows more about a package than you do he should be contacted for non-trivial changes (I'm not saying you have to wait for him at all costs). Of course if a package is plain and unconditionally broken it's ok to act first and talk later IMO, but communication is a requirement, not something you should try to avoid. One thing I completely disagree with however are the metadata.xml changes. Basically you're saying there it's ok to change the maintainer of a package without talking to the existing maintainer first (though I'm sure that wasn't your intention). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:47:27 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Well, I meant that this should be doable without the maintainer's > consent. Meaning, I ask you to stabilize 1.0-r1 and a few weeks > later, you can decide to stabilize -r2 without me having to file a > bug. Basically, the maintainer decides the minimal revision he wants > to go stable (so bugs are fixed, etc) but the revisions after that > are up to the arch teams, unless the maintainer sees a need for > everyone to update (major bug, security). My main goal here is to > reduce the "we have to wait on the maintainer to ask" issue within a > given version of a package. Well, that's probably ok when the higher revision is just a "fixed" version, but if for example it includes new (invasive) patches or other major changes to the ebuild it's a different story. But I'd hope we can rely on common sense here. Marius -- [EMAIL PROTECTED] mailing list
