Re: [gentoo-dev] Some packages up for grabs
Hey again! Some of the packages I offered for grabs have been taken a while ago, thanks everyone. Here are the remaining ones: * Wolfram Schlich [2012-12-01 11:02]: > [...] > Feel free to take care of the following packages that I used to > maintain a while ago but don't anymore due to change of interest: > > - RAID controller utils: > > sys-block/afacli (older Adaptec) > sys-block/dellmgr (older Dell-branded LSI MegaRAID) > [...] > sys-block/lsiutil (LSI MegaRAID) Dropped to maintainer-nee...@gentoo.org > - Other packages: > > app-arch/afio > app-misc/digitemp > [...] > media-gfx/dcraw > net-analyzer/nmbscan > net-analyzer/portbunny > net-dns/fpdns > [...] > sys-block/spindown > sys-fs/inotify-tools > sys-fs/owfs Dropped to maintainer-nee...@gentoo.org Cheers, Wolfram
Re: [gentoo-dev] Some packages up for grabs
* Diego Elio Pettenò [2012-12-01 21:31]: > On 01/12/2012 01:59, Wolfram Schlich wrote: > > - RAID controller utils: > > Maybe we should add sysadmin herd as fallback for these? +1 from me. Anyone from the sysadmin herd speaking up (for or against it)? :) > > sys-block/hpacucli (HP/Compaq Smart Array) > > This one I can help with in the immediate future since I have a couple > of servers needing it at work. > > > sys-process/fcron > > This one I'll take care of (I'm already in metadata). Great! :) Cheers, Wolfram
Re: [gentoo-dev] Some packages up for grabs
Hey Jesus! * Jesus Rivero (Neurogeek) [2012-12-01 15:43]: > On Dec 1, 2012 5:01 AM, "Wolfram Schlich" wrote: > > > > Hi! > > > > Feel free to take care of the following packages that I used to > > maintain a while ago but don't anymore due to change of interest: > > > > sys-block/tw_cli(3ware) > > dev-db/mysql-proxy > > [...] > > I'll take these. Great, thanks :) Cheers, Wolfram
[gentoo-dev] Some packages up for grabs
Hi! Feel free to take care of the following packages that I used to maintain a while ago but don't anymore due to change of interest: - RAID controller utils: sys-block/afacli(older Adaptec) sys-block/dellmgr (older Dell-branded LSI MegaRAID) sys-block/hpacucli (HP/Compaq Smart Array) sys-block/lsiutil (LSI MegaRAID) sys-block/megacli (LSI MegaRAID) sys-block/megactl (LSI MegaRAID) sys-block/megamgr (LSI MegaRAID) sys-block/megarc(LSI MegaRAID) sys-block/tw_cli(3ware) - Other packages: app-arch/afio app-misc/digitemp app-text/utrac dev-db/maatkit dev-db/mysql-proxy dev-libs/cyberjack dev-util/sel media-gfx/dcraw net-analyzer/nmbscan net-analyzer/portbunny net-dns/fpdns net-misc/radvd net-misc/wol sys-block/spindown sys-fs/inotify-tools sys-fs/owfs sys-process/fcron If you're interested in any of these, just contact me directly. Thanks! Cheers, Wolfram
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
* Zac Medico <[EMAIL PROTECTED]> [2008-08-25 20:42]: > Obviously there are an infinite number of possible approaches. The > main reason I brought this up was that a user had expressed a desire > to have package.keywords for use in private profiles (not the > official gentoo ones). The question of whether or not we should > implement package.keywords for the sake of private profiles should > be considered separately from the question of whether or not we > choose a policy to allow the use of package.keywords in one or more > of our official gentoo profiles. I'm currently in need of package.keywords for private profiles as well, so please add me to the list :) Would be great if portage-2.2 final would support that! Thanks, Wolfram
Re: [gentoo-dev] Asterisk 1.4 in Portage
* Doug Klima <[EMAIL PROTECTED]> [2007-12-26 19:19]: > Howdy all, Hey Doug! > As some people might have noticed, I've wanted to bring Asterisk 1.4 to > the tree proper. ++ on that from me :) > The big holdup is the zaptel ebuild, which needs to be > revamped and brought in as well for the 1.4.x series. I've already > rewritten most of it, the only issue is I don't have hardware to test > (nor do I want any). So I'd like if someone out there that used/had > zaptel hardware would pick up the ebuild. I do have an asterisk server with 2 HFC (CologneChip) cards, using 1 of them in NT mode (for connecting an ISDN phone to it) and one of them in TE mode (for connecting it to the ISDN of the telco). I used those with the zaphfc driver from the bristuff package. So, I could test your asterisk+zaptel ebuilds with this setup. > If you're interested, drop me a line. I'll send you over a 1.4.x ebuild. What's the status of http://overlays.gentoo.org/proj/voip/browser/trunk/net-misc/asterisk/\ asterisk-1.4.12.1.ebuild, does it differ much from the latest one you'd like to commit? What versions of zaptel, bristuff and the florz patch are you going to commit anyway? Thanks :) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
* Wolfram Schlich <[EMAIL PROTECTED]> [2007-11-27 02:31]: > * Wolfram Schlich <[EMAIL PROTECTED]> [2007-11-27 02:24]: > > * Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: > > > [...] > > > So I'd like to unmask it soon. Please, if you're using mailman test it, > > > tell > > > me if it suits your needs or just give me feedback like "worksforme", I > > > actually don't have a clue how many people really use this ebuild. > > > > I get this using hardened-sources with activated grsecurity > > trusted path execution feature: > > > > 2007-11-27 02:15:47 +01:00; alpha; kern.alert; kernel: grsec: From > > 127.0.0.6: \ > > denied untrusted exec of /usr/lib/mailman/bin/mmsitepass by \ > > /bin/bash[bash:14178] uid/euid:280/280 gid/egid:280/280, \ > > parent /bin/bash[bash:14173] uid/euid:280/280 gid/egid:280/280 > > > > That's because /usr/lib/mailman/bin/ is group-writable. > > Ok, that's not true :] > > Using this configuration... > --8<-- > CONFIG_GRKERNSEC_TPE=y > # CONFIG_GRKERNSEC_TPE_ALL is not set > CONFIG_GRKERNSEC_TPE_INVERT=y > CONFIG_GRKERNSEC_TPE_GID=1005 > --8<-- > ...I have to add 'mailman' to group 1005. Ok, it get's worse: for the mailman webinterface, I'd have to add 'apache' to group 1005 as well, opening up even bigger holes. No way! So, emerge -C mailman, that is :( Too bad. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
* Wolfram Schlich <[EMAIL PROTECTED]> [2007-11-27 02:24]: > * Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: > > [...] > > So I'd like to unmask it soon. Please, if you're using mailman test it, > > tell > > me if it suits your needs or just give me feedback like "worksforme", I > > actually don't have a clue how many people really use this ebuild. > > I get this using hardened-sources with activated grsecurity > trusted path execution feature: > > 2007-11-27 02:15:47 +01:00; alpha; kern.alert; kernel: grsec: From 127.0.0.6: > \ > denied untrusted exec of /usr/lib/mailman/bin/mmsitepass by \ > /bin/bash[bash:14178] uid/euid:280/280 gid/egid:280/280, \ > parent /bin/bash[bash:14173] uid/euid:280/280 gid/egid:280/280 > > That's because /usr/lib/mailman/bin/ is group-writable. Ok, that's not true :] Using this configuration... --8<-- CONFIG_GRKERNSEC_TPE=y # CONFIG_GRKERNSEC_TPE_ALL is not set CONFIG_GRKERNSEC_TPE_INVERT=y CONFIG_GRKERNSEC_TPE_GID=1005 --8<-- ...I have to add 'mailman' to group 1005. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
* Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: > [...] > So I'd like to unmask it soon. Please, if you're using mailman test it, tell > me if it suits your needs or just give me feedback like "worksforme", I > actually don't have a clue how many people really use this ebuild. I get this using hardened-sources with activated grsecurity trusted path execution feature: 2007-11-27 02:15:47 +01:00; alpha; kern.alert; kernel: grsec: From 127.0.0.6: \ denied untrusted exec of /usr/lib/mailman/bin/mmsitepass by \ /bin/bash[bash:14178] uid/euid:280/280 gid/egid:280/280, \ parent /bin/bash[bash:14173] uid/euid:280/280 gid/egid:280/280 That's because /usr/lib/mailman/bin/ is group-writable. Is that necessary at all?! -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
* Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: > [...] > So I'd like to unmask it soon. Please, if you're using mailman test it, tell > me if it suits your needs or just give me feedback like "worksforme", I > actually don't have a clue how many people really use this ebuild. pkg_postinst() says... --8<-- * Please read /usr/share/doc/mailman-2.1.9-r2/README.gentoo.gz for additional * Setup information, mailman will NOT run unless you follow * those instructions! --8<-- ...but that README actually has .bz2 instead of .gz on my system :) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
* Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: > Hi, > > The mailman ebuild was a pain in the past, installing to non-fhs-locations > (/usr/local), doing lot's of strange stuff, not able to use etc-update... > > mailman-2.1.9-r2 tries to fix lot's of those issues, it's much more > configurable through some variables. It's currently masked, but yesterday I > committed a bunch of changes and now I'm pretty satisfied with it. Nice! > So I'd like to unmask it soon. Please, if you're using mailman test it, tell > me if it suits your needs or just give me feedback like "worksforme", I > actually don't have a clue how many people really use this ebuild. Any special hints/advice? -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-process/fcron: ChangeLog fcron-3.0.4.ebuild
* Petteri Räty <[EMAIL PROTECTED]> [2007-11-20 02:26]: > Wolfram Schlich kirjoitti: > > * Donnie Berkholz <[EMAIL PROTECTED]> [2007-11-09 10:13]: > >> On 08:54 Fri 09 Nov , Wolfram Schlich (wschlich) wrote: > >>> 1.1 sys-process/fcron/fcron-3.0.4.ebuild > >>> > >>> file : > >>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&view=markup > >>> plain: > >>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&content-type=text/plain > >>> if useq debug; then > >> use() is useq() now. Dunno whether this is common enough to deserve a > >> repoman check. > > > > I won't change that until useq() is going to be finally removed and > > that action is *required* then (all of my ebuilds have useq() for > > control structures, and I'm not going to change *all at once now* > > just because someone has decided to equal use() and useq()... if > > someone feels like spending time on that, feel free to care about > > it ;)). > > > > I added http://bugs.gentoo.org/show_bug.cgi?id=199722 for nuking useq in > EAPI 2. Thanks, I'm Cc:'ed now :) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-process/fcron: ChangeLog fcron-3.0.4.ebuild
* Donnie Berkholz <[EMAIL PROTECTED]> [2007-11-09 10:13]: > On 08:54 Fri 09 Nov , Wolfram Schlich (wschlich) wrote: > > 1.1 sys-process/fcron/fcron-3.0.4.ebuild > > > > file : > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&view=markup > > plain: > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&content-type=text/plain > > > if useq debug; then > > use() is useq() now. Dunno whether this is common enough to deserve a > repoman check. I won't change that until useq() is going to be finally removed and that action is *required* then (all of my ebuilds have useq() for control structures, and I'm not going to change *all at once now* just because someone has decided to equal use() and useq()... if someone feels like spending time on that, feel free to care about it ;)). > > if ls -1 /var/spool/cron/fcrontabs/* >&/dev/null; then > > This particular check ignores ROOT, and so does the rest of > pkg_postinst(). Seems to me that a cron daemon is a package relatively > likely to be installed using ROOT, so it's worth fixing. Thanks, fixed :) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
* Robert Buchholz <[EMAIL PROTECTED]> [2007-10-08 05:53]: > On Thursday, 4. October 2007, Josh Sled wrote: > > Wolfram Schlich <[EMAIL PROTECTED]> writes: > > > * Donnie Berkholz <[EMAIL PROTECTED]> [2007-10-03 19:12]: > > >> On 12:43 Wed 03 Oct , Wolfram Schlich wrote: > > >> > And *please*, don't send such mails to this > > >> > list *and* to my address in addition. > > >> > > >> You can add a procmail rule to detect duplicates using a cache and > > >> checking Message-Id, with formail. Examples of this are all over > > >> the place. It's a useful rule to have for many reasons besides > > >> this. > > > > > > Yeah, but it's unpredictable *which* one of the two mails makes > > > it first onto my system, thus the one *not* sent to the list might > > > > Sigh. > > > > It is the same message, addressed To/Cc: you and/or the list, no > > matter which one is delivered first. So just put all list(+private) > > filtering before personal filtering. > > That doesn't work when filtering for List-Id headers which can be nicely > used with regex matching like so: > [...] Yup, I *only* filter mailing lists by list related headers like List-Id: and others -- filtering list mails by To:/Cc:/Subject: headers is broken by design. My current gentoo-commits reply spamfilter looks like this: --8<-- ## Gentoo spam :0 * ^From:[EMAIL PROTECTED] * ^Subject.*\[gentoo-commits\] * ! ^List-Id: /dev/null --8<-- -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
* Donnie Berkholz <[EMAIL PROTECTED]> [2007-10-03 19:12]: > On 12:43 Wed 03 Oct , Wolfram Schlich wrote: > > And *please*, don't send such mails to this > > list *and* to my address in addition. > > You can add a procmail rule to detect duplicates using a cache and > checking Message-Id, with formail. Examples of this are all over the > place. It's a useful rule to have for many reasons besides this. Yeah, but it's unpredictable *which* one of the two mails makes it first onto my system, thus the one *not* sent to the list might end up in my INBOX and the one sent to the list, that would have been correctly delivered to the mailbox for this list, would be deleted by procmail because it would be recognized as the duplicate. So that is just not a solution. I will instead filter mails sent by @gentoo.org addresses that have '\[gentoo-commits\]' in their subjects but no List-Id: header. Bad luck for everyone who sends such mails *only* to me. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
* Donnie Berkholz <[EMAIL PROTECTED]> [2007-10-03 10:55]:
> On 08:51 Wed 03 Oct , Wolfram Schlich (wschlich) wrote:
> > 1.1 sys-fs/ncdu/ncdu-1.3.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/ncdu/ncdu-1.3.ebuild?rev=1.1&view=markup
> > plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/ncdu/ncdu-1.3.ebuild?rev=1.1&content-type=text/plain
>
> > src_compile() {
> > econf || die "configure failed"
> > emake || die "make failed"
> > }
>
> This is the default, delete it.
Thanks, fixed :)
And *please*, don't send such mails to this
list *and* to my address in addition.
Thanks,
Wolfram
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] It is Bugday time!
* Dimitry Bradt <[EMAIL PROTECTED]> [2007-02-27 21:20]: > let's see if the bugday publicity at fosdem helps this project (at least > i hope so!) ...since FOSDEM my telephone is configured to remind me on the first saturday every month -- let's see if it actually works ;) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] punt raidtools and move people to mdadm
* Mike Frysinger <[EMAIL PROTECTED]> [2007-02-10 03:15]: > anyone have a compelling reason for keeping raidtools anymore ? the mdadm > package replaces all the functionality of raidtools and is actively > maintained upstream > > ive kept it around mostly so people can transition to mdadm nicely but i > think > it's about time we let it go /vote yes -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] udev coldplugging and /etc/init.d/modules
* Greg KH <[EMAIL PROTECTED]> [2006-12-01 18:08]: > [...] > If you rely on the specific loading order of modules, you were the crazy > one in the first place :) > > As others have said, look at using udev to name your network devices in > a persistant manner, it's the best solution. > > Or you can just blacklist the modules, and then load them yourself in > your modules startup location. > > The problem with doing this is the modules.d stuff is still broken for > blacklisting, it will only work on the first reboot of the system, > there's an open bug for this issue :( Greg, what's the best way to just completely disable udev coldplug-like module loading? TIA. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] openssh sftplogging patch
* Rumi Szabolcs <[EMAIL PROTECTED]> [2006-11-14 07:42]: > On Mon, 13 Nov 2006 13:15:46 +0100 > Wolfram Schlich <[EMAIL PROTECTED]> wrote: > > > In what ChangeLog, the portage package ChangeLog? > > Yeah, I also had to look at the OpenSSH ChangeLog to find out that > > SFTP logging has been added as a new feature. > > Yep, of course I meant the openssh package ChangeLog in portage > which IMHO should contain a word about why a USE flag has been > removed. Ok. Well, I don't know of any "standard procedure" to notify the user of a reason for a USE flag removal... :( > > > To me this doesn't look like as if it would have been integrated... > > > > The sftp-server(8) binary has new command line options that influence > > SFTP logging: > > > > -f log_facility > > -l log_level > > > > The sftplogging also contains functionality to control umask and permit > > chmod and chgrp, which the upstream sftp-server does not provide. > > Hmm... do I understand correctly that the sftplogging patch has not > been integrated but only a part of it's functions has been implemented > in a different way than it is in the patch? Yes. > Well, the syslog logging is useful but those settings about umask and > chmod/chgrp are essential in managing an sftp-based file repository with > multiuser access which is a great alternative to cleartext FTP access. > Using the settings the sftplogging patch provides I can set up an sftp > server in a usable and secure way which would otherwise be impossible. > > So here is a big PLEASE to keep/put back the sftplogging patch and > the use flag in the openssh ebuild! Well, the patch was called "sftplogging". umask+chmod/chgrp has absolutely *nothing* to do with "SFTP logging". I believe this code was misplaced in a patch called "sftplogging". So, I see it in a similar way as vapier does: Get the OpenSSH developers to include such functionality -OR- produce a patch that doesn't touch upstream SFTP logging but just adds umask+chmod/chgrp control features, maybe we can think about adding such a small patch as long as upstream does not provide such features. Just an idea. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] openssh sftplogging patch
* Rumi Szabolcs <[EMAIL PROTECTED]> [2006-11-13 09:15]: > On Sun, 12 Nov 2006 23:11:09 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > On Sunday 12 November 2006 11:38, Rumi Szabolcs wrote: > > > Could anybody please tell what happened? > > > > it's been integrated upstream so there's no point in having a patch anymore > > -mike > > Shouldn't this be mentioned in the ChangeLog somewhere? In what ChangeLog, the portage package ChangeLog? Yeah, I also had to look at the OpenSSH ChangeLog to find out that SFTP logging has been added as a new feature. > This is the 4.4p1 ebuild we are talking about and I could not find > too much of a difference between the patches against 4.3 and 4.4: > > http://sftplogging.sourceforge.net/download/v1.5/openssh-4.4p1.sftplogging-v1.5.patch > > To me this doesn't look like as if it would have been integrated... The sftp-server(8) binary has new command line options that influence SFTP logging: -f log_facility -l log_level The sftplogging also contains functionality to control umask and permit chmod and chgrp, which the upstream sftp-server does not provide. -- Wolfram Schlich -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] SearchSecurity.com: "Linux patch problems: Your distro may vary"
Hi, I just stumbled over an article from SearchSecurity.com which was linked to in a heise newsticker posting that tries to analyze how fast distributions react to security vulnerabilities: http://tinyurl.com/lplfb Quick chart: Rank DistroPoints/100 - -- 1. Ubuntu76 2. Fedora Core 70 3. Red Hat Enterprise Linux 63 4. Debian GNU/Linux 61 5. Mandriva Linux54 6. Gentoo Linux 39 7. Trustix Secure Linux 32 8. SUSE Linux Enterprise 32 9. Slackware Linux 30 Rank 6 out of 10 is not a great result -- at least we beat SUSE ;) Any comments or thoughts about this? Can we become better? Are we maybe better than the author pretends? Does the security team currently face serious problems that need to be solved, be it inside or outside the security team? I am just curious and would be glad to get some feedback :) -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] http://people.gentoo.org/
* Henrik Brix Andersen <[EMAIL PROTECTED]> [2005-12-05 18:40]: > [...] > How do people feel about adding this to the configuration of toucan? > Allowing toucan:~brix/public_html/ to be accessed under either of the > http://dev.gentoo.org/~brix/ and http://people.gentoo.org/brix/ URLs? I like it. -- Wolfram Schlich pgphYpykv9sBG.pgp Description: PGP signature
