Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Jakub Moc
Alec Warner napsal(a): Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time).

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Alec Warner
Jakub Moc wrote: Alec Warner napsal(a): Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Jakub Moc
Alec Warner napsal(a): See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is also invalid'. Thats what we are trying to fix. There's

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Bryan Østergaard
On Sun, Jan 28, 2007 at 12:02:39PM +0100, Jakub Moc wrote: Alec Warner napsal(a): See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Jakub Moc
Bryan Østergaard napsal(a): On Sun, Jan 28, 2007 at 12:02:39PM +0100, Jakub Moc wrote: Jakub, please stop making a fool of yourself with your endless rants. Quite a few experienced ebuild developers have already told you why it's not being removed. As such your rants are only wasting time.

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Luca Barbato
Jakub Moc wrote: - Folks, this car won't go any more, the engine has blown. Help. -- No worries, we'll fix the scratched paint on your left door and everything will be cool... the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT is the correct solution.

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Petteri Räty
Luca Barbato wrote: Jakub Moc wrote: - Folks, this car won't go any more, the engine has blown. Help. -- No worries, we'll fix the scratched paint on your left door and everything will be cool... the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT

Re: [gentoo-dev] matrox.eclass

2007-01-28 Thread Jakub Moc
Petteri Räty napsal(a): Luca Barbato wrote: the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT is the correct solution. Those packages that couldn't be installed since X.org (as opposed to XFree) did hit the tree because the eclass just dies and for

[gentoo-dev] Re: openmosix removal plan

2007-01-28 Thread Konstantin V. Arkhipov
On Sunday 28 January 2007 06:00:07 Daniel Drake wrote: I'm happy to take care of this +1. -- voxus :wq pgpNt6eonq05e.pgp Description: PGP signature

Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]

2007-01-28 Thread Christian Heim
On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote: Raúl Porcel wrote: # Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007) # Masked for removal 26 Feb 2007, bug 135257, security issues # Replaced by www-client/seamonkey[-bin] www-client/mozilla www-client/mozilla-bin How about not

[gentoo-dev] amd64 help

2007-01-28 Thread Christian Faulhammer
Hi, As we all notice from time to time, amd64 team is lacking behind a bit, due to various reasons. a) manpower, b) a lot of keywording. Java team asked arch teams if they object when Java team marks stable generation-2 ebuilds on their own, due to the long time it takes and to the amount of

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Dan Meltzer
Isn't this kind of against what glep40 set out to do? On 1/28/07, Christian Faulhammer [EMAIL PROTECTED] wrote: Hi, As we all notice from time to time, amd64 team is lacking behind a bit, due to various reasons. a) manpower, b) a lot of keywording. Java team asked arch teams if they object

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Daniel Drake
Christian Faulhammer wrote: So, maybe we can discuss here another helping hand for amd64. Devs that work with a given software (not necessarily the maintainer) on amd64 architecture It seems like this should be discussed amongst the active amd64 developers internally first, and perhaps

[gentoo-dev] Topic for Feb council meeting

2007-01-28 Thread Mike Doty
The subject of what to do if a council member voluntarily leaves the council came up at the last meeting. The glep doesn't cover what to do in this case. Here are the options: 1. re-elect a whole new council. 2. elect a new member at a reduced term to fill the vacancy. 3. take the 8th spot

Re: [gentoo-dev] Topic for Feb council meeting

2007-01-28 Thread Olivier Crête
On Sun, 2007-28-01 at 14:24 -0800, Mike Doty wrote: The subject of what to do if a council member voluntarily leaves the council came up at the last meeting. The glep doesn't cover what to do in this case. Here are the options: 1. re-elect a whole new council. 2. elect a new member at

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Petteri Räty
Dan Meltzer wrote: Isn't this kind of against what glep40 set out to do? Top posting... Any way the thing was that the only change in these ebuilds are the eclasses/eclass functions used and the new eclasses have been proven stable already. Regards, Petteri signature.asc Description:

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Dan Meltzer
On 1/28/07, Petteri Räty [EMAIL PROTECTED] wrote: Dan Meltzer wrote: Isn't this kind of against what glep40 set out to do? Top posting... Any way the thing was that the only change in these ebuilds are the eclasses/eclass functions used and the new eclasses have been proven stable already.

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Petteri Räty
Dan Meltzer wrote: On 1/28/07, Petteri Räty [EMAIL PROTECTED] wrote: Dan Meltzer wrote: Isn't this kind of against what glep40 set out to do? Top posting... Any way the thing was that the only change in these ebuilds are the eclasses/eclass functions used and the new eclasses have been

Re: [gentoo-dev] Topic for Feb council meeting

2007-01-28 Thread Mike Frysinger
On Sunday 28 January 2007 17:24, Mike Doty wrote: The subject of what to do if a council member voluntarily leaves the council came up at the last meeting. i dont think the voluntarily qualification should be there ... if a dev turns jackass and they get punted and they happen to be on the

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Mike Doty
Dan Meltzer wrote: On 1/28/07, Petteri Räty [EMAIL PROTECTED] wrote: Dan Meltzer wrote: Isn't this kind of against what glep40 set out to do? Top posting... Any way the thing was that the only change in these ebuilds are the eclasses/eclass functions used and the new eclasses have been

Re: [gentoo-dev] amd64 help

2007-01-28 Thread Ciaran McCreesh
On Sun, 28 Jan 2007 19:17:35 +0100 (MET) Christian Faulhammer [EMAIL PROTECTED] wrote: | As we all notice from time to time, amd64 team is lacking behind a | bit, due to various reasons. a) manpower, b) a lot of keywording. | Java team asked arch teams if they object when Java team marks stable |

Re: [gentoo-dev] ecompress heads up

2007-01-28 Thread Mike Frysinger
On Friday 26 January 2007 17:41, Mike Frysinger wrote: that said, i would entertain the notion of auto uncompressing just .bz2, .gz, .Z and telling everyone else to toss off ... talking with zmedico; this is what he wants so ive implemented this -mike pgplsTrnzmpNo.pgp Description: PGP

Re: [gentoo-dev] Topic for Feb council meeting

2007-01-28 Thread Ioannis Aslanidis
Mike Frysinger wrote: On Sunday 28 January 2007 17:24, Mike Doty wrote: 1. re-elect a whole new council. 2. elect a new member at a reduced term to fill the vacancy. 3. take the 8th spot from the last election. i'd lean towards three here ... also, s/8th/next/ in case we shed more than 1

[gentoo-dev] Re: amd64 help

2007-01-28 Thread Christian Faulhammer
Ciaran McCreesh [EMAIL PROTECTED]: On Sun, 28 Jan 2007 19:17:35 +0100 (MET) Christian Faulhammer [EMAIL PROTECTED] wrote: | As we all notice from time to time, amd64 team is lacking behind a | bit, due to various reasons. a) manpower, b) a lot of keywording. | Java team asked arch teams if