Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv

2006-06-02 Thread Simon Stelling
You forgot to mention which package uses the variable. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] UTF-8 encoding and file format of manuals

2006-06-02 Thread Tom Martin
On Thu, 1 Jun 2006 21:08:54 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: On Thursday 01 June 2006 20:19, Jan Kundrát wrote: Wiktor Wandachowicz wrote: Summing up: * UTF-8 manuals: good or bad? The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in piece. Would it

Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv

2006-06-02 Thread Jakub Moc
Simon Stelling wrote: You forgot to mention which package uses the variable. Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv ;) -- jakub signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] UTF-8 encoding and file format of manuals

2006-06-02 Thread Jan Kundrát
Paul de Vrieze wrote: Would it be possible to do automatic detection and unicode conversion in the portage install stage? I think that would probably be the best option. At a later stage a simple detection and warning might be sufficient. Tricky. You can parse a file and check if it's valid

Re: [gentoo-dev] Security/QA Spring Cleaning

2006-06-02 Thread Eldad Zack
On Sunday 28 May 2006 21:20, Ned Ludd wrote: The following maintainers and maintaining herds are affected by this in one way or another. This list is still far to large for me want to file a bug for.. So please do what you can to help narrow this list down. Granted not all cases can be

[gentoo-dev] Last rites/mask notification: dev-libs/libvc, app-misc/rolo and mail-client/mutt-vc-query

2006-06-02 Thread Stefan Cornelius
Hi Gentoo, dev-libs/libvc, app-misc/rolo and mail-client/mutt-vc-query were masked because of the open security bug #127757. It also seems like there was no upstream release for like 3 years, so this packages are pretty much dead. If nobody speaks up or volunteers as maintainer for that cruft,

[gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Ferris McCormick
Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement that any alternative package manager support any ebuild which portage supports seems

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Stephen Bennett
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick [EMAIL PROTECTED] wrote: What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Marius Mauch
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick [EMAIL PROTECTED] wrote: Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Paul de Vrieze
On Friday 02 June 2006 18:47, Marius Mauch wrote: Actually this is probably the main problem of all the package manager compability gleps: We don't have a proper specification, all existing docs more or less are based on the existing portage implementation. So right now the implementation is

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Stephen Bennett
On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Alec Warner
Stephen Bennett wrote: On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to

[gentoo-dev] Marking packages ~amd64 (or amd64) and no-multilib

2006-06-02 Thread Chris Gianelloni
First off, I'd like to apologize for cross-posting this, but I've been pestered by this enough recently to want to try to reach as much of the developer pool as possible. If you add any amd64 KEYWORDS to *any* packages in the tree, make sure you've updated your profiles directory before doing

[gentoo-dev] Re: [gentoo-core] Marking packages ~amd64 (or amd64) and no-multilib

2006-06-02 Thread Ned Ludd
On Fri, 2006-06-02 at 15:26 -0400, Chris Gianelloni wrote: First off, I'd like to apologize for cross-posting this, but I've been pestered by this enough recently to want to try to reach as much of the developer pool as possible. If you add any amd64 KEYWORDS to *any* packages in the tree,

[gentoo-dev] User Relations Co-lead

2006-06-02 Thread Christel Dahlskjaer
Hi, It is my pleasure to inform you that after much discussion I can announce that Joshua Jackson (tsunam) has come onboard to act as my co-lead in Userrel[1]. Wish him luck, I suspect he will need it! [1] http://www.gentoo.org/proj/en/devrel/user-relations/index.xml -- $a=gentoo.org;

Re: [gentoo-dev] Glep 49 (g2boojum's version)

2006-06-02 Thread Chris Gianelloni
On Fri, 2006-06-02 at 19:48 +0200, Paul de Vrieze wrote: On Friday 02 June 2006 18:47, Marius Mauch wrote: Actually this is probably the main problem of all the package manager compability gleps: We don't have a proper specification, all existing docs more or less are based on the existing

[gentoo-dev] eselect-compiler updates and unmasking

2006-06-02 Thread Jeremy Huddleston
I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's

Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-02 Thread Donnie Berkholz
Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it

[gentoo-portage-dev] Does 2.1 retain eclass info in binpkgs?

2006-06-02 Thread Duncan
I'm doing some testing of the latest eselect-compiler for eradicator, involving merging and unmerging gcc. He has made some recent changes to toolchain.eclass that are supposed to help it work with eselect-compiler, and that's what I'm trying to test. Obviously, gcc is a rather huge package to