[gentoo-dev] integrating solaris overlay into main portage
Hi all, i always feared in asking this because of some typical flamewars, however. I am now in a company which is actively using Solaris 10 and Gentoo. We're deploying some house-written software onto both using the portage system (!). However, knowing that portage for Solaris (10) is only available via a prefix is not the problem, but knowing that for solaris you have to use a completely different portage tree which is just lagging behind is a real pain. i'm not that familiar with this prefixed development as the maintainers itself, but i don't think it's a big deal to tag those ebuilds with solaris-x86 (for example) that are $EPREFIX aware, isn't it? The benifit: we have so many ebuilds in the tree that just need keywording and/or a simple $EPREFIX addition. This shouldn't hurt any primary package maintainer in finding any of these in their ebuilds, in fact, i'd be happy to know there's yet another package that can be installed using gentoo's portage on yet another architecture. How do you feel with that idea? Regards, Christian Parpart. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are you guys for real?
On Wednesday 13 June 2007 23:46:01 Hélder Máximo Botter Ribas wrote: > Nowadays, this list looks more like a fight ring than a dev list. > > I'm using gentoo for 4 years, I love emerge, I enjoy to be part of > gentoobr( Gentoo Brazilian community ), I'm always helping at gentoobr > and gentoo-chat. I really enjoy gentoo. it feels really good to read ppl still enjoy things we all love in the end anyway - although, a public list is what the public community contributing to it is submitting. and if only the biatches between us have something to say this way, then it still doesn't mean that *all* of us act like that. regards, Christian Parpart. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Are you guys for real?
On Wednesday 13 June 2007 23:53:51 Markus Ullmann wrote: > Some numbers to back Vlastimil up > > > Yep there's still development going on, devs commit ebuilds and stuff. > > http://cia.vc/stats/project/gentoo > > > Also, as said many times, number of devs participating in flamewars here > > is pretty low compared to number of all devs... > > considering > http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml > and > http://archives.gentoo.org/stats/gentoo-dev-per-month.xml > I really agree that most people are quiet ;) > > Greetz > -jokey nice stats - but how about commits per month to the big pool of gentoo repositories? (mostly important the portage tree, of course ^^) Christian. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC]: gentoo-politics ML
On Thursday 07 June 2007 09:10:41 Kent Fredric wrote: > On 6/7/07, Kumba <[EMAIL PROTECTED]> wrote: > > Anyways, thoughts? > > > > --Kumba > > +1 +1 here too > possible alternative names: gentoo-soap, gentoo-gossip ( not to be > confused with net-im/gossip ) gentoo-soap, lol! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] g++ problem
On Monday 28 May 2007 18:16:11 Robert Clark wrote: > > works fine as soon as I add the -static flag for g++ > > > > g++ -g -Wall -static `curl-config --cflags` `curl-config --libs` -l > > xerces-c Ui.cpp GetDataCurl.cpp GetDataAmazon.cpp XmlParser.cpp > > Options.cpp > > > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bi > >n/ld: cannot find -lgssapi_krb5 > > collect2: ld returned 1 exit status obviousely you've got a dynamic version libgssapi_krb5.so but no static version libgssapi_krb5.a (please note the file extension). please checkout the package that installed this particular library (sorry, don't know which, as I don't play w/ gssapi nor krb) and probably fix the ebuild, in case it is just missing installing the dynamic version. But maybe upstream just did not create a static lib version, so you've to patch their Makefile and in the end, patch the ebuild anyways. Hope these thoughts help, Christian Parpart. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] C++ herd proposal
On Monday 19 September 2005 15:22, warnera6 wrote: > Mark Loeser wrote: > > Paul de Vrieze wrote: > >> I think that dev-util is a very specific category containing > >> development utilities of some sort. There might be some > >> misclassifications in them, but from a user perspective I don't really > >> care about the language anything is written in. As C++ is so > >> widespread I don't think that anything but app-misc or the like should > >> be moved into a dev-cpp category. > > > > This isn't for what the package is written in, but more for what the > > package is for. If the package is a utility for use when doing coding > > with C++, like the ones I listed, then I think it should be in dev-cpp. > > That's what the metadata for the category describes it to be. > > > > Mark > > Once again I'd like to point out that organizing packages in the tree by > category is a stupid idea for this very reason. and what's *your* certain proposal then? pgpYUgBMZbynY.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 22:14, Mike Frysinger wrote: > On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: > > Kevin F. Quinn wrote: > > >> I would also like to see many of them, if not all, moved to the > > >> dev-cpp category: > > > > > > Is this bit really necessary? > > > > The reason for me adding that bit is the metadata from dev-cpp: > > > > The dev-cpp category contains libraries and utilities relevant to the > > c++ programming language. > > > > Now to me, that means I can find *all* relevant C++ stuff here. If we > > don't want that to be the case, maybe we should say "miscellaneous", but > > why should something be in dev-libs, as compared with dev-cpp? > > net-libs, I could understand, and dev-games, as those could be argued to > > have a direct relation. > > for generic C++ packages (STLport/boost for example), i can see them being > in the dev-cpp category ... but for packages which have specific uses > already and arent in 'generic' categories, i dont think they should be > moved -mike if I do understand you correctly, I'd even not use dev-cpp as category, instead something that contains the word `platform` or `framework` in it, as STLport/boost/STL(libstdc++-v3,...) and others are exactly of that kind. However, we've some more no-herd'ed packages to put into this new potential c++ herd - but these are two different discussions/threads IMHO. Regards, Christian Parpart. pgpmomqy0QfGN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 14:01, Kevin F. Quinn wrote: > On 17/9/2005 13:33:30, Christian Parpart ([EMAIL PROTECTED]) wrote: > > On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote: > > > On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: > > > > > > C++ herd is a good idea, especially with that number of packages. > > > > > > > I would also like to see many of them, if not all, moved to the > > > > dev-cpp category: > > > > > > Is this bit really necessary? > > > > indeed, it at least helps curious c++ devs to browse through some yet > > unknown c++ libs and he maybe finds something useful. > > If the only gain is that one group finds one search criteria a little > easier, then I think that is far from sufficient reason to re-categorise. errr... I didn't meant "of course" == "indeed", I meant it a way of "that might make sense". sorry for the misunderstandings ;) Regards, Christian. pgpofgnAw5U4n.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote: > On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: > > C++ herd is a good idea, especially with that number of packages. > > > I would also like to see many of them, if not all, moved to the dev-cpp > > category: > > Is this bit really necessary? indeed, it at least helps curious c++ devs to browse through some yet unknown c++ libs and he maybe finds something useful. Regards, Christian Parpart. pgpzHaXkO28CW.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 01:20, Mike Frysinger wrote: > On Friday 16 September 2005 06:20 pm, Mark Loeser wrote: > > Since we currently have language herds for other languages such as Ada, > > Perl, and Java, I don't think C++ should be any different. > > it is different, but i dont mind the idea of having a bunch of C++ experts > looking over a bunch of packages which otherwise may be neglected And that's the point I see in as well - having some central point for our C++ experts/freaks. Of course, a c++ herd would not just be like ADA/Java IMO. Though, I vote FOR such a herd (and would like to join anyway) > > dev-libs/STLport(no-herd, vapier?) > > vapier/toolchain > > > dev-libs/fampp2 (no-herd, vapier) > > dev-libs/ferrisloki (no-herd, vapier) > > dev-libs/libferrisstreams (no-herd, vapier) > > dev-db/stldb4 > > generally i dont need help with these as the upstream author is a pretty > cool guy and gets back to me :) > -mike but having some backup is always the safer way, in case some of us is AFK for some unobvious reasons and a security patch is to be injected. Regards, Christian Parpart pgpUVooVe8STE.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Friday 02 September 2005 06:28, Lance Albertson wrote: > Grant Goodyear wrote: > > Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT] > > > >>This just leads me to assume you're not really a coder (wrt native > >>programming languages like C/C++), are you? > > > > *Grin* This sort of condescending attitude is rarely wise when it comes > > to dealing with Gentoo devs. Not only does it tend to annoy people > > (yes, I'm a tad annoyed by the presumption), but since you're still > > relatively new here the odds are that people know the person you're > > being condescending to better than they know you, and thus it just makes > > you look bad if you're wrong. Feel free to ask people what I do for a > > living, and whether they suspect that I know the difference between a > > 64-bit pointer and a 32-bit int. > > Ha! Yeah ... kids these days... just don't respect their elders like > they should ;-). I have seen more and more 'newish' devs speaking their > minds like this without even knowing/asking the person. I guess respect > and tactfulness isn't being taught anymore... > > And yes, Grant definitely knows the difference :-) Maybe I do not understand the diffference between "I assume" and "I know", and "I know" I meant the first, however, in that case, Grant, I do not know why you're requesting this combine when you know about these "issues" already. Don't get me wrong, I am (though, I was) just curious, and really surprised how the hell ppl (telling to be coders) can even think about such merges. It might - of course - *somehow* still be possible, but I just do not believe in, as I posted earlier (by example). And just like kintaco said, there're not only ppl outside that do know why those archs are different, there're also ppl outside that even make use of such things on *their* main arch (x86) and do not care (or did) about 64bit compats, in fact, most do not know that this piece of could would lead into semantic errors on such archs anyway. As said, don't get me wrong, I'm neither new (depends on definition!) nor am I "missing respect". I was just sharing some by-example snippets why this is a bad idea, and I was just "assuming" (not "know") why I said what I said. Regards, Christian Parpart. pgp0pZlV2YJFY.pgp Description: PGP signature
Re: [gentoo-dev] combining x86 and amd64
On Thursday 01 September 2005 19:10, Grant Goodyear wrote:
> The recent discussion about having a "real" x86 arch team and combining
> the x86 and amd64 keywords was both interesting and provocative.
aha? Not in the list, is it?
> Of course, this is the sort of thing that the GLEP system was meant for.
> Now that we have a new council that (I hope) will be active in approving
> or rejecting GLEPs, perhaps someone should be writing a GLEP about
> combining x86 and amd64?
This just leads me to assume you're not really a coder (wrt native programming
languages like C/C++), are you?
I mean, x86 (32bit) and amd64 (64bit) ARE NOT THE SAME ARCH.
This is simply demonstrated by all those ugly pointer-to-integer conversions
that often happen when you write on your legacy x86 architecture.
However, when you try to compile it on an amd64 e.g., you just can't as gcc
WILL bail out.
Having now a x86amd64-alike keyword instead of x86 and amd64 will just make
lots of user's emerge experiences pain ass.
Of course, OTOH, while our bugs db gets flooded with reports, this *could* be
a startup for us to know *what* packages needs fixing. But that way, we would
be jast far off enterprise.
Here's an example that works on x86 but *not* an amd64:
// g++ -o test32vs64bit test32vs64bit.cpp
#include
int main() {
void *p = NULL;
unsigned u = (unsigned)p; // ok on x86; error on amd64
p = (void *)u; // ok on x86; error on amd64
return 0;
}
Of course, you might think WTF do some guy need this, but hey, programmers are
really creative, and use what the compiler accepts - I myself ran into this
while porting my apps/libs to amd64. And think of it, not everybody has the
money to grab one.
Congrats,
Christian Parpart.
pgpKwfrGKm0Ue.pgp
Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: > On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: > > 2) ebuild maintenance will be a nightmare- every new version will > >require again walking the source to see if the lines you've drawn for > >dividing the source are still proper. minimize the duplication by a mysql eclass, just like we do for apache e.g. (and lots of others) that prevent us from code duplication. > I'd see no problem with this in mysql, if, for example, mysql's Makefile > had a "make libmysqlclient" target. In that case, I would make it a > separate package. Having a look at the already provided libmysqlclient ebuild [1] it obviousely (and for our luck) looks like upstream supports this installation types. > This would also mean a lot of work on your part, as > every single package that had a dependency on mysql would now need some > way of specifying whether the server was going to be local or remote, to > properly *DEPEND on the correct package. We've plenty of tools that help us in searching for all ebuilds *directly* depending on "dev-db/mysql"; than you just need to decide, wether this needs the server or not. And (w/o looking at them) I do predict, that 100% of them will only need libmysqlclient. Why? What package would depend on the server in particular? If the user wants the server to be run on localhost, than he would just have to add it to his emerge args as well. I see no problems there - instead: it would be a great enheancement. (IMO) > All in all, I think it isn't worth even attempting at this time. read above. do you still think so? If so, why? Regards, Christian Parpart. [1] http://bugs.gentoo.org/attachment.cgi?id=55816 -- 04:43:52 up 148 days, 17:51, 1 user, load average: 0.66, 0.76, 1.15 pgpojzr28kw9N.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thursday 18 August 2005 19:01, Georgi Georgiev wrote: > maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types > > > Using the "minimal" useflag for this - IMHO - is a misuse of the idea of > > "minimal" semantically - as I do understand minimal in a way like "don't > > overbloat me with patches and other feature additions"-alike. > > minimal - Install a very minimal build (disables, for example, plugins, > fonts, most drivers, non-critical features) > vanilla - Do not add extra patches which change default behaviour I agree with these definitions. however, why I was refering to the "minimal" use-flag anyway, was, because comment 1 in the bug-report statet, that we *do* have the "minimal" use-flag to achieve, what the bug-reporter was intending to get (a splitout of client-only libs/headers); Extract of comment 1 in the bug: | New ebuilds have the "minimal" use flag. This flag build the server with | "configure --without-server" . | explaining better this last point. You still need to download ALL the | package from MySQL site *BUT* only the libraries will be installed. They reason for why I was ever intending to ask here on -dev and why I'm CCed in the bug still is: * it looks a little overbloated, when you wanna install cat/foo ebuild that supports to back its data to mySQL instead of sqlite, and you *have* to install a server for that (not always); this might be irrelevant for desktop machines, but the hell not for servers; you can't predict, that you maintain INSTALL_MASK-alike var to prevent such things being installed. you (in first place) do not know what you all need to mask anyway * a useflag (so I use and understand them) are for enabling features or other *extra* advantages (like kdeenablefinal or debug); * while having not taken a look at the mysql build side, I don't believe, that it would be an overhead in splitting out libmysqlclient (and that's what we're finally talking about) and making (for backwards compatibility and use) it a depend to the already existing dev-db/mysql package; Regards, Christian Parpart. -- 04:26:38 up 148 days, 17:34, 1 user, load average: 0.86, 1.39, 1.97 pgpmHlNUu3Czy.pgp Description: PGP signature
[gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Hi all, well, regarding the request on bug 88490 [1] (and my own needs) I'm in a deep problem ;) There *are* packages out there, that depend on (networking) client libraries (and their headers of course); for the general mysql ebuild, I'd propose the following splitup: * dev-db/mysql-server (or myssqld) * net-libs/libmysqlclient * dev-db/mysql (a meta package that simply depends on both, for backward compat) The reason is, that some packages need to talk to (SQL )servers, but some host installation do not need - or even want to (think about security policies) - a local (SQL) server; Using the "minimal" useflag for this - IMHO - is a misuse of the idea of "minimal" semantically - as I do understand minimal in a way like "don't overbloat me with patches and other feature additions"-alike. This idea of course is applicable for lots of more packages, but mysql is one use case where I myself ran into; Do we have a general accepted gentoo policy for this? And... any thoughts on this subject? Regards, Christian Parpart. [1] http://bugs.gentoo.org/show_bug.cgi?id=88490 -- 15:56:43 up 148 days, 5:04, 2 users, load average: 1.32, 1.21, 1.21 pgpimFIPl7JZ1.pgp Description: PGP signature
Re: [gentoo-dev] Put DESCRIPTION HOMEPAGE and LICENSE in another place
On Thursday 11 August 2005 02:04, Carlos Silva wrote: [...] > What do you think of this? I once asked for a better place (namely metadata.xml), but got corrected with the following reason: HOMEPAGE/LICENSE/DESCRIPTION might change over version bumps; not just the revision/version number, also the description reflecting major behavior changes from version 0.1 to 1.0 for example; The license may change for numerous reasons; The homepage may change as version 1.2.4.x might be available on $URL/a and 1.4.8.y might be available on $URL/b (and though maybe even slotted); both can still be the same package; though slotted, and with differend homepage URL. But anyway, I feel that these cases in realworld are really very rare (except the the license-change thingy) just my thoughts, Christian Parpart. -- 05:28:28 up 140 days, 18:36, 0 users, load average: 0.14, 0.18, 0.23 pgpmNu2lr778s.pgp Description: PGP signature
Re: [gentoo-dev] app-portage/genlop: 9 open bugs, dead upstream
On Sunday 24 July 2005 20:29, Ivan Yosifov wrote: > Hello Everyone, > > What's up with genlop ? > There are 9 open bugs, some including trivial fixes ( like #97049 ), > the homepage http://pollycoke.org/genlop.html ( as listed in the > ebuild ) is dead. If my understanding is correct, unmaintained packages > are removed from the tree. well, we once (within the apache herd) had a module that's not really maintained by anyone special, but debian (to mention one I *do* remember) is maintaining this package, too, and though we decided to leave it in, especially where we recognized, that debian even did some more effords on this partiular package. don't flame me now, but I forgot what package exactly it has been, however, the wact still remains. finally, genlop still has a user base (including me). So I wouldn't dare in dropping it. Regards, Christian Parpart. -- 04:32:01 up 123 days, 17:39, 1 user, load average: 2.89, 5.20, 5.16 pgpOkvty5Oim6.pgp Description: PGP signature
Re: [gentoo-dev] net community servers, in what category?
On Thursday 21 July 2005 00:09, Chris Gianelloni wrote: > So you're splitting this into separate ebuilds, or it comes that way > from upstream? Well, upstream is me, however, the package gets released in a big tarball containing a global level configure script that can handle a all-at-once installation. Each module within (those I mentioned as ebuild) contain itself a ./configure as they can be installed seperately. This - I decided - not just for killing my time, but for providing splitted server installations, like multiple www nodes (installing www-apache/mod_yacs and its DEPENDs) and the real server node installing yacsd (possibly others, like yb, if needed) That's why I split them up. > > dev-libs/libyacsutil > > - the support library (client/server) > > community-libs/libyacs > > - the YaCS core framework library (server) > > dev-libs well, seems to be the best place then. > > community-server/yacsd > > - the UNIX daemon process finally serving the community > > net-misc, net-www [...] > > community-server/yacs-meta > > - the meta package for YaCS, in case everything has to be > > run on a single server > > net-misc or net-www for sure not net-www as it has nothing to do with www et al. so, net-misc seems best then. [...] > You shouldn't create categories for anything less than about 10 to 20 > ebuilds. The more the better, really. I understand. So, as Oliview proposed the same like you, I gonna stick with this then. Thanks all, Christian Parpart. -- 00:23:29 up 119 days, 13:31, 0 users, load average: 1.47, 1.90, 2.09 pgpKmYGgJBy43.pgp Description: PGP signature
Re: [gentoo-dev] net community servers, in what category?
On Wednesday 20 July 2005 23:58, Christian Parpart wrote: > dev-libs/libyacsutil > - the support library (client/server) > community-libs/libyacs > - the YaCS core framework library (server) > community-server/yacsd > - the UNIX daemon process finally serving the community > app-admin/yacsadmin > - the server console administration tool > app-benchmarks/yb > - a server benchmarking tool (think of / like: ab, the apache > benchmark) www-apache/mod_yacs > - the apache module that serves as the front-end for the end-users > community-server/yacs-meta > - the meta package for YaCS, in case everything has to be > run on a single server The server (like apache) can be extended by modules /mod_chat - a chat system /mod_character - a character (RPG, guestbook, ...) system /mod_cms - a CMS (content management system) The chat module itself supports plugins, meaning, that 3rd-party plugins (in seperate ebuilds) shall be placed somewhere as well. For those I also do not have a proper category I could place them in. Thanks, Christian Parpart. -- 23:55:50 up 119 days, 13:03, 0 users, load average: 3.28, 2.26, 2.55 pgpm8NDgkyV9D.pgp Description: PGP signature
[gentoo-dev] net community servers, in what category?
Hi all, I wanted to create some ebuilds for at least one community server (represented by a bunch of ebuilds); So, I was looking for the right category for all of those ebuilds that belong to this software, however, I didn't find a proper category for each of them at all :( The software I am talking about is called YaCS (yet another community system) and consists of the following parts (that are being split up into seperate ebuilds): dev-libs/libyacsutil - the support library (client/server) community-libs/libyacs - the YaCS core framework library (server) community-server/yacsd - the UNIX daemon process finally serving the community app-admin/yacsadmin - the server console administration tool app-benchmarks/yb - a server benchmarking tool (think of / like: ab, the apache benchmark) www-apache/mod_yacs - the apache module that serves as the front-end for the end-users community-server/yacs-meta - the meta package for YaCS, in case everything has to be run on a single server Now, you see, I already proposed my (in my mind) ideal categories. The problem are two packages I couldnn't fit into currently existing categories. In fact, we even haven't any community server in portage yet (and there do exist quite a few). So, I might have a little (continuous) brain-dead and though, would like to be pointed to the right category for those two packages; otherwise, I'd like to propose those two new categories - in that case: who's the karma to initiate them? Other community software I found (*and* are free): * boo - http://yallara.cs.rmit.edu.au/~malsmith/products/boo/ * yChat - http://www.ychat.org/ * SPiN Chat System - http://chat.spin.de/en/ (dunno what kinda license it is) note: while browsing google, I found lots of commercial software of this subject and just a few few (serious) open sourced ones. So, finally, in what category could those packages be placed in? Thanks in advance, Christian Parpart. -- 23:17:49 up 119 days, 12:25, 0 users, load average: 4.17, 2.57, 3.12 pgpY2xXfkksE9.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
On Wednesday 20 April 2005 10:59 am, Paul de Vrieze wrote: > On Wednesday 20 April 2005 09:36, Christian Parpart wrote: > > And yeah, I disagree to a move-back, too!! I'm most likely not to > > support this in any kind, instead, I'd be willing in pushing p.mask'ed > > apache httpd 2.1 into the tree, so, that I don't have to live with the > > old shitty behavior again. > > > > Seriousely, why did we put all our power into those improvements when > > we're now about to revert mostly everything? > > I believe that most issues are with the new configuration setup. What > about checking for the old configuration format and in that case > providing the old configuration setup. If there is no old format (or > allready a working new format config file) use the new config system. I might be wrong, but... I do not think that this will be easily possible, because all modules would have to deel with this, too. Besides all this, suppose the case that we've an apache httpd 2.1-line would in the trees, someone emerged it (though, don't have 2.0.x installed), is there be a way to get subversion with +apache2 useflag installed? apache-2.1 needs latest apr/apr-util's, I just hope that this wouldn't crash in any way. Cya, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 17:23:03 up 28 days, 6:29, 0 users, load average: 0.26, 0.31, 0.34 pgpakx01jaFGI.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote:
> Christian Parpart wrote:
> > And yeah, I disagree to a move-back, too!! I'm most likely not to support
> > this in any kind, instead, I'd be willing in pushing p.mask'ed apache
> > httpd 2.1 into the tree, so, that I don't have to live with the old
> > shitty behavior again.
> >
> > Seriousely, why did we put all our power into those improvements when
> > we're now about to revert mostly everything?
>
> Because they seriously hork people's installations in some cases and cause
> lots of frustration. The improvements seem great, but they need to *work*
> out of the box for most situations which this doesn't appear to be doing.
> Testing is supposed to be for things that work and just need tweaking, not
> something that works for most cases and breaks other people's systems. For
> one, make your eclass backwards compatible so that mod plugins are easier
> to maintain. You're not reverting if you're saving a lot of people some
> pain.
> Why do you have to push all these improvements on the current stable
> line of apache (2.0.x) ?
I once read stuart's posting far along ago about needing help in apache herd.
So I came in (and others). So we planned what needs to be solved as reported
(tons of items were in bugzilla before), and what needs to be done to improve
maintainship as well as client/hostadmin side configuration and workflow.
So we came up to the current feature set we currently have. And I'm really
happy w/ our fixes and (far more) about the improvements we made.
Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all
(just once AFAIK and not related to the actual problem). *that's* why we've
solved everything possible in 2.0-line.
> Why can't these changes just be used in the
> upcoming alpha/beta releases and totally be implemented by the time they
> move to the next stable release.
Wasn't thought about earlier, just as said, however, I feel really sad when we
*move*back* that far, since I feel not happy in upgrading to the next apache
ebuilds on the servers I do administrate, and, in fact, do a downgrade,
because we at least move back with the configuration *and* (most probably)
drop LFS-support as well. That'd be hell for me.
And that's why I proposed to maintain the 2.1-line of apache httpd including
all current features by now - just(!) in case, everyone really *wants* that
we shall revert those improvements.
> Asking people to suddenly change midway
> through is a major pain. If they knew that these kinds of changes were
> going to happen in >2.0.x, then it would be easier for them to manage.
we put a blocker into the depends, so, that users have to unmerge there
already installed apache before doing an upgrade. My proposal *now* would
even be, to block actual apache{1,2} installations in pkg_config() that still
have old configuration files in /etc/apache{,2} around.
So, the user is enforced to have a look at it when having done the upgrade.
src_config() {
if test -e ${APACHE_CONFDIR}; then
einfo "${Place_here_the_info_text_and_URL}"
die "Old configuratioin files detected. Please remove them \
before upgrading to new apache."
fi
}
However, I know, that not all ppl would like such a behavior anyway. But doing
everything automatically isn't just the best option. For this, the old
configuration has been just *too* crappy to realize auto adaption of of the
old configuration data into the new layout.
Best regards,
Christian Parpart.
--
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
17:09:51 up 28 days, 6:16, 0 users, load average: 0.27, 0.42, 0.42
pgpmQFpwIcRsk.pgp
Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
On Tuesday 19 April 2005 10:51 pm, Paul de Vrieze wrote: > On Tuesday 19 April 2005 21:45, Elfyn McBratney wrote: > > APR and APU are stand-alone and independent of apache, so there is no > > need to p.mask those libs. > > They do not coexist with the old apache2 properly as apache2 includes it's > own version. As did subversion. AFAIK we can't have apr/apr-utils as standalone pkgs as long as we've subversion or apache2 still embedding it, that's been the reason for providing the ebuild patch for subversion (from the apache herd), too - I remember. Just embedding them again is really a great lost of at least maintainability, so at least do I feel. And yeah, I disagree to a move-back, too!! I'm most likely not to support this in any kind, instead, I'd be willing in pushing p.mask'ed apache httpd 2.1 into the tree, so, that I don't have to live with the old shitty behavior again. Seriousely, why did we put all our power into those improvements when we're now about to revert mostly everything? Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 09:29:00 up 27 days, 22:35, 0 users, load average: 0.01, 0.05, 0.00 pgpFGxPPtrag7.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Wednesday 13 April 2005 3:03 pm, Aaron Walker wrote: > Ciaran McCreesh wrote: > > On Wed, 13 Apr 2005 03:33:46 +0200 Christian Parpart <[EMAIL PROTECTED]> > > > > wrote: > > | Finally, just don't use svn if you feel that uncomfortable with it. No > > | one said that cvs will go away. I'm tired of reading your 'svn is > > | hard to merge because it *is* hard to merge' posts :( > > > > Eh? Dude, I'm one of the people that's been asking for SVN from the > > beginning. SVN is considerably easier to merge than CVS -- however, it's > > a pain in the ass if you're using multiple projects per repo because > > then you *have* to give it full paths. > > > > Really, I think you should reread the entire thread if you think I'm > > against SVN. > > Yeah actually the glep wouldnt exist at all w/o Ciaran pawning it off on me > :) I take it back. Really I just wanted to stop that 'I like it better that way' discussion. But yet, I'm responding again. However, I take it back, sorry though. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 16:45:13 up 21 days, 5:51, 0 users, load average: 0.42, 0.31, 0.26 pgpLX7Cwojlcw.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Tuesday 12 April 2005 8:57 pm, Ciaran McCreesh wrote: > On Tue, 12 Apr 2005 20:50:36 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > > wrote: > | On Monday 11 April 2005 22:42, Ciaran McCreesh wrote: > | > Well, surprisingly enough, one of the main reasons we use these > | > version control things is so that we can see *what changed*. It's a > | > hell of a lot easier to do this when you can just say "show me > | > everything that changed in the foo project between three days ago > | > and today" rather than having to worry about adding in extra > | > selections to pick a project path. > | > | You need to do this anyway. Whether it's a path inside the repository > | or on the webserver doesn't matter. It's like > | https://svn.gentoo.org/gentoo/projA where /gentoo is the name of the > | repos or https://svn.gentoo.org/gentoo/projA where /gentoo is a > | superdirectory of all project repositories that are now housed in the > | gentoo cvs repository. In either case /gentoo could be removed. > > No, with certain operations you need to start giving entire paths if and > only if you're not operating on the repo as a whole. If you loose when using svn as client, then you might wanna have a look at svk which already has star-merge capabilities. Or just don't merg until svn 1.3 is out (which will have it) > | > One big repository is harder to work with. It's that simple. > | > | With one exception, that is, sharing and merging within a repository > | is a lot easier than between two separate repositories. > > Which is an extremely rare task compared to doing things like diffs and > branch merges... http://rt.openfoundry.org/Foundry/Project/Download/Attachment/28786/20705/SVK-0.991.tar.gz (or wait for the ebuild) play a bit around, feel it, and report your experiences. when having problems (like you seem to *always* complain) report in *detail*. Finally, just don't use svn if you feel that uncomfortable with it. No one said that cvs will go away. I'm tired of reading your 'svn is hard to merge because it *is* hard to merge' posts :( Sorry, but this is how it comes over. Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 03:28:51 up 20 days, 16:35, 0 users, load average: 0.40, 0.27, 0.21 pgpaR4ulngk6Y.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Monday 11 April 2005 10:42 pm, Ciaran McCreesh wrote: > On Mon, 11 Apr 2005 22:23:29 +0200 Christian Parpart <[EMAIL PROTECTED]> > > wrote: > | On Monday 11 April 2005 8:26 am, Ciaran McCreesh wrote: > | > On Sun, 10 Apr 2005 23:57:12 +0200 Christian Parpart > | > <[EMAIL PROTECTED]> > | > > | > wrote: > | > | > SVN uses transactions and > | > | > changesets. These make a heck of a lot more sense if they're > | > | > done on a per project basis. > | > | > | > | reason? > | > > | > Because you can pull out a meaningful and relevant changeset without > | > having to arse around with path prefixes. > | > | Do you have to? If so, why? > > Well, surprisingly enough, one of the main reasons we use these version > control things is so that we can see *what changed*. It's a hell of a > lot easier to do this when you can just say "show me everything that > changed in the foo project between three days ago and today" rather than > having to worry about adding in extra selections to pick a project path. yeah ;) > | > | > Unlike with CVS, this makes a big difference -- SVN > | > | > revision IDs are actually meaningful, > | > | > | > | SVN repository IDs represent the state of the whole repository at > | > | a given time, nothing more or less. > | > > | > Not repo IDs. Revision IDs. > | > | That's the one I meant. yeah. > > And, said revision IDs are useful for keeping track of what's changed. > Or, at least, they are if you know that an update of 3 in the revision > number is equivalent to three changesets, which you don't if you use > multiple projects per repo. This eases the understanding of course. However, sometimes moving file X from project foo to bar makes sense. I do not say that *you* will be in such situation, but I know I already went in. And besides, I'm (not related to gentoo) keeping multiple repositories for different projects and (where it makes sense) project categories. > | > | Hmm... besides, the ASF is just having a single repository for all > | > | their public projects (with about 1000+ contributors) w/o any > | > | problems. > | > > | > So we should make the same mistakes as them? Sure, a single repo > | > would be usable, but multiple repos would be a heck of a lot better. > | > | Seriousely, this is plain low FUD unless you can give me a decent > | argument on why the ASF made a mistake here. > > One big repository is harder to work with. It's that simple. Might be personal taste, I can't feel here with you, but this is *all* not part of GLEP36. So, let's break here the loop ;) Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 23:25:53 up 19 days, 12:32, 4 users, load average: 0.94, 0.71, 0.65 pgpPWy2WtLrli.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Monday 11 April 2005 8:26 am, Ciaran McCreesh wrote: > On Sun, 10 Apr 2005 23:57:12 +0200 Christian Parpart <[EMAIL PROTECTED]> > > wrote: > | > SVN uses transactions and > | > changesets. These make a heck of a lot more sense if they're done on > | > a per project basis. > | > | reason? > > Because you can pull out a meaningful and relevant changeset without > having to arse around with path prefixes. Do you have to? If so, why? > | > Unlike with CVS, this makes a big difference -- SVN > | > revision IDs are actually meaningful, > | > | SVN repository IDs represent the state of the whole repository at a > | given time, nothing more or less. > > Not repo IDs. Revision IDs. That's the one I meant. yeah. > | Hmm... besides, the ASF is just having a single repository for all > | their public projects (with about 1000+ contributors) w/o any > | problems. > > So we should make the same mistakes as them? Sure, a single repo would > be usable, but multiple repos would be a heck of a lot better. Seriousely, this is plain low FUD unless you can give me a decent argument on why the ASF made a mistake here. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 22:20:40 up 19 days, 11:27, 4 users, load average: 1.33, 1.03, 0.88 pgpVTtyatMt1P.pgp Description: PGP signature
Re: [gentoo-dev] net-www/apache testing request (marking stable anytime soon)
On Monday 11 April 2005 7:55 pm, Stuart Herbert wrote: > Hi Jason, > > Jason Wever wrote: > | And why would we not want to present the default Apache index.html to our > | users? > > Installing anything as a default page into /var/www/localhost/htdocs/ is > dangerous. If the Apache install is an upgrade, the default page could > quite easily break someone's working website. > > I haven't looked at the new page myself (yet), but I hope that > > a) it's only installed if a local USE flag is enabled, and yes. definitely. > b) that it's tasteful and contains useful "Getting Started" material tasteful. yeah. useful getting started? yeah, one href to gentoo org. No, seriousely, you wanna more "getting started"? Than hire the documentation team, because upstream apache won't maintain "getting started" docs anylonger as a default webpage and we did not agree to their current plain'n'ugly "It works!" page. Once we've set up the server documentation e.g. (that one on apache-svn repos that still exists) than yeah, lets put it up. But for so long? no way. (except for the conditions mentioned above). Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 22:15:47 up 19 days, 11:22, 4 users, load average: 0.85, 0.77, 0.80 pgpF2xMRlHUxB.pgp Description: PGP signature
Re: [gentoo-dev] net-www/apache testing request (marking stable anytime soon)
On Sunday 10 April 2005 7:18 pm, Jason Wever wrote: > On Sun, 10 Apr 2005 18:43:13 +0200 > > Christian Parpart <[EMAIL PROTECTED]> wrote: > > Of course, we did not wanna push nearly-everyones little blindly > > executed `emerge -uvD world` into hell. But everyone makes mistakes, so > > including me. sorry for that, though, we got almost every complain > > fixed already. That's why we're requesting for testing, for being sure, > > going stable won't shoot anyone into his foot again. > > Are there any plans for a non-branded version of this new Apache > configuration? It seems a bit opposite of the goal to try to make Apache > more compliant with how it is provided upsteam to be putting in a branded > default front page. current upstream page just sais "It works!". That's indeed not what we want to present the Gentoo Apache Users. > Also if we're stuck with the branding, can we come up with a page that is > at least a little more professional looking or a little less like someone > trying to be witty? If you've a better page. email me. [I'm open to better proposals] Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 03:30:23 up 18 days, 16:36, 2 users, load average: 0.08, 0.15, 0.16 pgpVS36nLQbhQ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Sunday 10 April 2005 8:34 pm, Ciaran McCreesh wrote: > On Sun, 10 Apr 2005 20:27:03 +0200 Christian Parpart <[EMAIL PROTECTED]> > > wrote: > | Both have pros and cons. Well, the ASF has everyting converted into a > | single repository and they seem to be just lucky with it. KDE is > | about to convert everything into a single svn repos as well (for > | other reasons). For the Gentoo projects, it might make sense > | (administrative) to keep everything into a single repository as well. > | However, providing each sub project with its own repository will work > | around the single-point-of-failure effect (in worst case) so it's > | likely to happen this way. > > Nothing to do with single points of failure. maybe wrong said. I mean, when you break the repos, you break everything and the whole development process halts. when you break a little repos if a single dev group, you break just this one (to be fixed though) and the others will continue w/o any problems. > SVN uses transactions and > changesets. These make a heck of a lot more sense if they're done on a > per project basis. reason? > Unlike with CVS, this makes a big difference -- SVN > revision IDs are actually meaningful, SVN repository IDs represent the state of the whole repository at a given time, nothing more or less. > and you don't want to lock every > single Gentoo project whilst one person on a slow dialup connection does > a single transaction to a single project. as confirmed by svn devs and others, the transaction data is first uploaded to the server (with whatever speed the client has) and then performed server-side. Though, the time of locking the database depends on the CPU load, and not the client's [dialup] speed. Hmm... besides, the ASF is just having a single repository for all their public projects (with about 1000+ contributors) w/o any problems. Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 23:44:22 up 18 days, 12:50, 2 users, load average: 0.51, 0.64, 0.72 pgpkvaHCyl0SG.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Sunday 10 April 2005 11:35 pm, Greg KH wrote: > On Sun, Apr 10, 2005 at 10:30:29PM +0100, Daniel Drake wrote: > > A while back, we had to move the gentoo kernel patches out of the Gentoo > > CVS because we realised it conflicted with the old copyright assignment > > form: I have signed an agreement saying that everything I put in gentoo > > cvs will be copyrighted to Gentoo. That obviously isn't the case for > > kernel patches that I didn't write. > > > > We moved the kernel patches into a bitkeeper repo, and they've been there > > for a while. However, this might be clashing with the social contract, > > and costless BK is going away, so its time to move again. I'd love to > > host these in a Gentoo repo, preferably SVN, but would need to get that > > agreement revoked for me and the other kernel developers. Who do I need > > to speak to? > > Thanks for bringing this up, I was going to do so this week. I can get > the cvs data out of the bk tree, if we want to move it anywhere else, so > we will not loose the history (if that's an issue.) But we need to get > moved off of bkbits.net as soon as possible, > and the gentoo server is > not a current solution :( could you be please more specific? I mean. why isn't it a current solution? because SVN isn't right in place or because of the copyright problems still around or ...? thanks, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 23:42:51 up 18 days, 12:49, 2 users, load average: 0.44, 0.69, 0.75 pgpftbMY1O8Aq.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Sunday 10 April 2005 7:53 pm, Ciaran McCreesh wrote: > On Sun, 10 Apr 2005 19:44:19 +0200 Christian Parpart <[EMAIL PROTECTED]> > > wrote: > | So, sooner or shorter, we're announcing here some news on > | this subject (oops, did I already by this?, so, I can say, > | we're offering already existing svn repositories to be > | merged into the gentoo svn repository > > Hrm, please tell me you're planning one svn repo per 'project', not one > huge big Gentoo svn repo. Both have pros and cons. Well, the ASF has everyting converted into a single repository and they seem to be just lucky with it. KDE is about to convert everything into a single svn repos as well (for other reasons). For the Gentoo projects, it might make sense (administrative) to keep everything into a single repository as well. However, providing each sub project with its own repository will work around the single-point-of-failure effect (in worst case) so it's likely to happen this way. However, it's not likely to happen today or tomorrow, like ramereth said. be patient ;) Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 20:17:34 up 18 days, 9:23, 0 users, load average: 0.76, 0.80, 0.72 pgp0pqONmkLdZ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Sunday 10 April 2005 7:32 pm, Ciaran McCreesh wrote: > On Sun, 10 Apr 2005 19:27:51 +0200 Patrick Lauer <[EMAIL PROTECTED]> > > wrote: > | On Sun, 2005-04-10 at 18:12 +0100, Ciaran McCreesh wrote: > | > On Sun, 10 Apr 2005 12:39:45 -0400 Aaron Walker <[EMAIL PROTECTED]> > | > > | > wrote: > | > | Regarding GLEP 36[1], solar has asked me to try and figure out a > | > | way to provide both CVS and Subversion for one repository and keep > | > | them sync'd somehow. > | > > | > Please don't. This would mean we'd have to stick with all of the > | > restrictions of CVS. > | > | We have to do that anyway until cvs is phased out. > > Eh? Er, no. We're already using SVN for a whole load of Gentoo projects, > but we're currently hosting them off berlios rather than official Gentoo > infrastructure. That's the purpose of this GLEP. I see, there's a greater demand on this subject than I even thought about. I even expected that you'll all kill me for the whols SVN alternative thoughts I'm raising. Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 19:45:33 up 18 days, 8:51, 0 users, load average: 0.92, 0.73, 0.60 pgpbblmElribB.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
On Sunday 10 April 2005 7:27 pm, Patrick Lauer wrote: > On Sun, 2005-04-10 at 18:12 +0100, Ciaran McCreesh wrote: > > On Sun, 10 Apr 2005 12:39:45 -0400 Aaron Walker <[EMAIL PROTECTED]> > > > > wrote: > > | Regarding GLEP 36[1], solar has asked me to try and figure out a way > > | to provide both CVS and Subversion for one repository and keep them > > | sync'd somehow. > > > > Please don't. This would mean we'd have to stick with all of the > > restrictions of CVS. This is a technical no-go (at least a hell) to realize. So, forget about a (realtime) synchronized cvs<->svn portage tree and alike. > We have to do that anyway until cvs is phased out. the sooner the better ^o^ > If you can think of a full battle plan for migrating everything at once > that even includes tools etc, I'll be among the first to help getting it > implemented. Well, a full battle won't go that easy, however: We're already working on a subversion migration into official gentoo. So, please be patient. We've been talking about this off-list for a long time now - not just talking but also doing test conversions, script fixing and alike. We also had a little meeting right yesterday about an open issues list I figured out. So, sooner or shorter, we're announcing here some news on this subject (oops, did I already by this?, so, I can say, we're offering already existing svn repositories to be merged into the gentoo svn repository, and we're offering already existing sub-projects' CVS directories to be converted on-demand. so, as soon as we're about to announce this service, just drop us a note. ka0ttic, you maybe overran me with your mail :-) So far, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 19:33:55 up 18 days, 8:40, 0 users, load average: 0.63, 0.55, 0.54 pgpSDDhS46gfV.pgp Description: PGP signature
Re: [gentoo-dev] net-www/apache testing request (marking stable anytime soon)
On Sunday 10 April 2005 4:55 pm, Brian Jackson wrote: > How about not breaking apache? We did not break apache, we broke *binary compatibility* within apache. Are you aware of *why* we decided to break binary compatibility? Well, if not, I can say we did so to provide LFS to the end-users. You might not need it, but for sure, others will be very happy about. So, please before just asking this, also consider the benifits from it. Of course, we did not wanna push nearly-everyones little blindly executed `emerge -uvD world` into hell. But everyone makes mistakes, so including me. sorry for that, though, we got almost every complain fixed already. That's why we're requesting for testing, for being sure, going stable won't shoot anyone into his foot again. Finally, the eclass updates have been a BIG must to simplify maintaince in a long term. So, we could of course have introduced just yet another eclass resisting parallel to the old one - just to have worked around this breakage as well. Yeah, we learn all the time :) > I was a little beyond pissed when I had > to sit there for 2 hours trying to figure out why my apache was broken, > and who was going to get put on my list of being kicked in the junk. > Just for some stupid config file changes. does it work now? when did you upgrade? what problems did you run in? please feedback us. That's what we was calling for ;-) > I find it very hard to believe > you guys couldn't come up with a better way to do it. Even if that means > doing evil stuff in one of the stages that isn't sandboxed. We thought about doing so but decided against. At least my reason was, because this would be a bloody hell and a no-go in a garrantied clean config merge. I advice everyone to configure their new apache files (httpd.conf for commonapache/apache.conf) from scratch. Regards, Christian Parpart. -- the following rfc contains how to quote on lists like this: Netiquette: http://www.ietf.org/rfc/rfc1855.txt 17:57:59 up 18 days, 7:04, 0 users, load average: 0.28, 0.31, 0.35 pgprALEbGGY3f.pgp Description: PGP signature
[gentoo-dev] net-www/apache testing request (marking stable anytime soon)
Hi guys, refering to [1] and [2] I must see, that we've been in testing phase for quite a long time now. Our eclass' changes reflect only to masked and/or testing ebuilds, though, marking stable ebuilds somewhat obsolete. Although, apache httpd is bumping 2.0.54 very soon and our latest *stable* is just 2.0.52-r1 (and yet obsolete in all aspects). Before bumping a new 2.0.54 release of apache2, I would like to catch all problems we maybe have to fix right before going stable. Though, ... please test apache-2.0.53 and/or apache-1.3.33-r2 (including your favorite apache modules) on your system(s) and please report any oddies you experience. Thanks in advance, Christian Parpart. [1] http://packages.gentoo.org/ebuilds/?apache-2.0.53 [2] http://packages.gentoo.org/ebuilds/?apache-1.3.33-r2 -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 15:57:13 up 50 days, 12:22, 1 user, load average: 0.00, 0.00, 0.00 pgpcdTJq3hQTy.pgp Description: PGP signature
