[gentoo-dev] Re: amd64 help
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 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 ebuilds to be stabilised. > | 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 and when there is a keywording bug open, then > said | devs can keyword the ebuild. For a short period of time this > could be | allowed to all devs. > | Any objections? > Why not just extend the amd64 team to include people who will only > work on Java stuff? Other arch teams have no problems with developers > being onboard only for a few particular packages. Because it was meant for every package and I only talk about keywording ~amd64, not stabling. The latter is handled by the team in a timely manner, but keywording is put aside (it leads to even more stabling, once it is keyworded). Java was only mentioned, as they came up with an idea to help amd64 in special and arch teams in general. V-Li signature.asc Description: PGP signature
Re: [gentoo-dev] Topic for Feb council meeting
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 person in a cycle ++ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-01-28 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-01-28 23h59 UTC. Removals: net-misc/bcm44002007-01-23 21:50:22 dsd dev-lang/cm32007-01-24 04:49:16 vapier sys-apps/pcsc-ase-iiie-drv 2007-01-24 19:35:53 alonbl media-libs/libmusepack 2007-01-25 23:15:25 flameeyes x11-themes/bmpx-themes 2007-01-27 03:40:16 chutzpah media-libs/swfdec 2007-01-27 13:02:51 armin76 dev-java/jakarta-tomcat-jasper 2007-01-27 22:49:24 wltjr app-emulation/i8086emu 2007-01-28 19:49:08 calchan dev-ada/asis2007-01-28 20:54:22 george net-im/mercury-bin 2007-01-28 22:46:03 humpback Additions: app-text/gnochm 2007-01-22 03:42:24 dirtyepic app-portage/gatt-svn2007-01-23 07:14:33 opfer dev-perl/Sys-Statistics-Linux 2007-01-23 13:34:20 mcummings xfce-extra/xfce4-timer 2007-01-23 23:01:19 welp dev-java/fontbox2007-01-24 14:47:10 betelgeuse dev-scheme/scm 2007-01-24 18:34:29 hkbst app-admin/pprocm2007-01-25 18:31:56 mcummings dev-perl/GD-Barcode 2007-01-25 19:30:37 ian dev-java/rundoc 2007-01-25 20:04:42 betelgeuse net-p2p/bitstormlite2007-01-26 12:12:51 armin76 dev-java/snip 2007-01-26 16:09:54 betelgeuse app-doc/linux-kernel-in-a-nutshell 2007-01-26 17:08:25 vapier net-p2p/dbhub 2007-01-26 17:17:08 armin76 net-misc/tipcutils 2007-01-26 19:07:09 gustavoz dev-lang/xsb2007-01-28 09:19:36 keri x11-plugins/compiz-extra2007-01-28 12:36:48 hanno media-libs/wxsvg2007-01-28 20:02:38 dirtyepic app-text/searchmonkey 2007-01-28 22:02:02 armin76 sys-fs/davl 2007-01-28 22:22:08 armin76 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-misc/bcm4400,removed,dsd,2007-01-23 21:50:22 dev-lang/cm3,removed,vapier,2007-01-24 04:49:16 sys-apps/pcsc-ase-iiie-drv,removed,alonbl,2007-01-24 19:35:53 media-libs/libmusepack,removed,flameeyes,2007-01-25 23:15:25 x11-themes/bmpx-themes,removed,chutzpah,2007-01-27 03:40:16 media-libs/swfdec,removed,armin76,2007-01-27 13:02:51 dev-java/jakarta-tomcat-jasper,removed,wltjr,2007-01-27 22:49:24 app-emulation/i8086emu,removed,calchan,2007-01-28 19:49:08 dev-ada/asis,removed,george,2007-01-28 20:54:22 net-im/mercury-bin,removed,humpback,2007-01-28 22:46:03 Added Packages: app-text/gnochm,added,dirtyepic,2007-01-22 03:42:24 app-portage/gatt-svn,added,opfer,2007-01-23 07:14:33 dev-perl/Sys-Statistics-Linux,added,mcummings,2007-01-23 13:34:20 xfce-extra/xfce4-timer,added,welp,2007-01-23 23:01:19 dev-java/fontbox,added,betelgeuse,2007-01-24 14:47:10 dev-scheme/scm,added,hkbst,2007-01-24 18:34:29 app-admin/pprocm,added,mcummings,2007-01-25 18:31:56 dev-perl/GD-Barcode,added,ian,2007-01-25 19:30:37 dev-java/rundoc,added,betelgeuse,2007-01-25 20:04:42 net-p2p/bitstormlite,added,armin76,2007-01-26 12:12:51 dev-java/snip,added,betelgeuse,2007-01-26 16:09:54 app-doc/linux-kernel-in-a-nutshell,added,vapier,2007-01-26 17:08:25 net-p2p/dbhub,added,armin76,2007-01-26 17:17:08 net-misc/tipcutils,added,gustavoz,2007-01-26 19:07:09 dev-lang/xsb,added,keri,2007-01-28 09:19:36 x11-plugins/compiz-extra,added,hanno,2007-01-28 12:36:48 media-libs/wxsvg,added,dirtyepic,2007-01-28 20:02:38 app-text/searchmonkey,added,armin76,2007-01-28 22:02:02 sys-fs/davl,added,armin76,2007-01-28 22:22:08 Done.
Re: [gentoo-dev] ecompress heads up
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 signature
Re: [gentoo-dev] amd64 help
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 | generation-2 ebuilds on their own, due to the long time it takes and | to the amount of ebuilds to be stabilised. | 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 and when there is a keywording bug open, then said | devs can keyword the ebuild. For a short period of time this could be | allowed to all devs. | Any objections? Why not just extend the amd64 team to include people who will only work on Java stuff? Other arch teams have no problems with developers being onboard only for a few particular packages. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] amd64 help
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 proven stable already. Regards, Petteri okay, i'll bottom post this time just for variety. From opfers post it sounded like he was proposing to allow this for all packages (not just java). I was enquiring after that. I have a long email to write about this, but it'll have to wait until tonight or tomorrow. -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
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 council, this would apply as well > 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 person in a cycle -mike pgpBvXk2nHo1N.pgp Description: PGP signature
Re: [gentoo-dev] amd64 help
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 proven >> stable already. >> >> Regards, >> Petteri >> > > okay, i'll bottom post this time just for variety. From opfers post > it sounded like he was proposing to allow this for all packages (not > just java). I was enquiring after that. > Yeah, just wanted to give the background that started this discussion. I agree that we should not start loosening the policy ligthly. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] amd64 help
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. Regards, Petteri okay, i'll bottom post this time just for variety. From opfers post it sounded like he was proposing to allow this for all packages (not just java). I was enquiring after that. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
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: OpenPGP digital signature
Re: [gentoo-dev] Topic for Feb council meeting
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 a reduced term to fill the vacancy. > 3. take the 8th spot from the last election. > > The spirit of the GLEP would indicate option 2, but it's never spelled > out. Speak out now if you have a opinion on the subject. It should definitely be one of 2 or 3. Option 1 is ridiculous. I would personally opt for 3, since it allows the council to keep on functioning properly. Or maybe 3 if there is unanimous approuval from the council or 2 otherwise. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Topic for Feb council meeting
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 from the last election. The spirit of the GLEP would indicate option 2, but it's never spelled out. Speak out now if you have a opinion on the subject. -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
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 should do some kind of recruiting drive / call for help. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
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 when Java team marks stable generation-2 ebuilds on their own, due to the long time it takes and to the amount of ebuilds to be stabilised. 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 and when there is a keywording bug open, then said devs can keyword the ebuild. For a short period of time this could be allowed to all devs. Any objections? V-Li -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 help
Sounds practical. That should save us some time. :) Christian Faulhammer 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 when Java team marks stable generation-2 ebuilds on their own, due to the long time it takes and to the amount of ebuilds to be stabilised. 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 and when there is a keywording bug open, then said devs can keyword the ebuild. For a short period of time this could be allowed to all devs. Any objections? V-Li -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] amd64 help
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 ebuilds to be stabilised. 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 and when there is a keywording bug open, then said devs can keyword the ebuild. For a short period of time this could be allowed to all devs. Any objections? V-Li signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
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 breaking the tree? > > !!! All ebuilds that could satisfy "www-client/mozilla" have been masked. > !!! One of the following masked packages is required to complete your > request: > - www-client/mozilla-1.7.13 (masked by: package.mask) What about the rest of the portage error ? At least it could be used, to fix (well sort of) it :) > # Raúl Porcel <[EMAIL PROTECTED]> (27 Jan 2007) > # Masked for removal 26 Feb 2007, bug 135257, security issues > # Replaced by www-client/seamonkey[-bin] > > Regards, > Petteri Sincerely, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: openmosix removal plan
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] matrox.eclass
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 which no driver can be downloaded? Lots of people must have those installed apparently. :) You know, I already mentioned a couple of times that is will work just fine with a dummy eclass (if someone has this crap installed by some miracle) but we are so drowned in policies that this doesn't go anywhere. Maybe someone could at least punt the single unusable ebuild that remains in the tree so that something marginally useful would come out of this. Thanks, bye. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
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 is the correct solution. > Mixing ebuild and eclass here, are you? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
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. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
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. > > Regards, > Bryan Østergaard Yay, rants... - 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... Sigh. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
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 also > > invalid'. > > > > Thats what we are trying to fix. > > There's absolutely no package that could be installed via this crappy > eclass, already tried to explain about 4 times but you don't listen. Oh > well, I give up; go fix the slot, never mind that it's utterly useless. > 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. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
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 absolutely no package that could be installed via this crappy eclass, already tried to explain about 4 times but you don't listen. Oh well, I give up; go fix the slot, never mind that it's utterly useless. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
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 some >>> time). Fixing it doesn't make sense, making it dummy or even removing it >>> (plus the unusable single ebuild which inherits it) does. >>> >>> >>> [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 >>> >> And we already told you, removing it isn't a good solution (even if it >> technically works within the bounds of the current api). The bug is >> that the SLOT invalidates cache entries and it's trivial to fix. > > The eclass is not trivial to fix, to be fixed, this eclass would require > a complete rewrite from scratch. There's no usable ebuild for this > eclass and the eclass is completely moot. Still fail to see what are you > trying to fix as opposed to removing a broken non-functional cruft from > the tree. > > 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. The fact that the eclass sucks balls is irrelevant, I could say the same of a dozen other old as hell eclasses. But they remain in the tree, as will this one. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
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). Fixing it doesn't make sense, making it dummy or even removing it >> (plus the unusable single ebuild which inherits it) does. >> >> >> [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 >> > > And we already told you, removing it isn't a good solution (even if it > technically works within the bounds of the current api). The bug is > that the SLOT invalidates cache entries and it's trivial to fix. The eclass is not trivial to fix, to be fixed, this eclass would require a complete rewrite from scratch. There's no usable ebuild for this eclass and the eclass is completely moot. Still fail to see what are you trying to fix as opposed to removing a broken non-functional cruft from the tree. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
