Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 21:35:52 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: > The original topic of this conversation was about what to do about an > arch that is obviously not as responsive as other arches. This is a > concrete example of that fact, which you requested. This seems to be > a topic frequently discussed here. Really, I wanted concrete examples of where there was an actual problem. Preferably lots of concrete examples, to demonstrate that this is a systemic thing rather an odd one off issue. > Who knows how long that request would have languished if not for the > security bug? Who knows indeed... Wouldn't the Council be better served with examples where we do know? If there's a real problem here, surely it wouldn't be that hard to produce an extensive list of examples? Ideally each example would state how often the arch team has been asked, how long they've had to respond, how clear it has been made to the arch team that the issue is considered a priority and what the impact of the arch team not taking action is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 02:06 +0300, Peter Volkov wrote: > В Сбт, 05/01/2008 в 18:19 +0100, Luca Barbato пишет: > > Anything other suggestions? > > I think, arch which does not manage to cope with stabilize bugs force > users to use unstable branch so it's good both for developers and users > to force such arch to concentrate on fixing real bugs and maintain only > unstable branch. Decision to drop stable branch for certain arch should > be done by council after request and discussion on -dev having > [EMAIL PROTECTED] in CC. > Well, if running mips actually causes more breakage than running ~mips and if it is unlikely that this will change soon, then the stable keyword is not just useless, but misleading. In this case, just dropping it seems the most sensible solution. Thus it all comes down to a question for mips users/developers: Is mips any longer more stable than ~mips? Any opinions? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: On Sat, 05 Jan 2008 20:52:49 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: That's making the assumption that anyone looked at it, of course. Please note comment #9 on http://bugs.gentoo.org/show_bug.cgi?id=198346. It was still ~8 days from then that the setuptools keyword was added. So, we have examples of impact due to delay in keywords/etc. Shall we proceed with the discussion of what to do about it? http://www.gentoo.org/security/en/vulnerability-policy.xml The target for that GLSA was 20 days. 8 days is well within target. What are you moaning about? The original topic of this conversation was about what to do about an arch that is obviously not as responsive as other arches. This is a concrete example of that fact, which you requested. This seems to be a topic frequently discussed here. Who knows how long that request would have languished if not for the security bug? As you said, when there are so many requests and so few people to service them, they all have the same priority, unless there's something to elevate their priority. Ciaran, I think you've made my point far more eloquently than I could have myself. Thanks for your time and attention to this matter. Marty -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last Rites: net-misc/howl
# Saleem Abdulrasool <[EMAIL PROTECTED]> (05 Jan 2008) # Mask for removal in 30 days. This has been superceeded by Avahi. Upstream # considers it a dead project and actively refuses to work on it or accept # patches. net-misc/howl -- Saleem Abdulrasool compnerd (at) gentoo (dot) org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 20:52:49 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: > That's making the assumption that anyone looked at it, of course. > Please note comment #9 on > http://bugs.gentoo.org/show_bug.cgi?id=198346. It was still ~8 days > from then that the setuptools keyword was added. > > So, we have examples of impact due to delay in keywords/etc. Shall > we proceed with the discussion of what to do about it? http://www.gentoo.org/security/en/vulnerability-policy.xml The target for that GLSA was 20 days. 8 days is well within target. What are you moaning about? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: On Sat, 05 Jan 2008 20:32:09 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: Perhaps you should have explicitly stated in the bug that it was for security reasons and thus a priority. Make things easy for the arch teams -- if you have useful information like that, provide it in an easy to see place. Looking at that bug, I don't see anything indicating that there's any reason it should have been considered over more widely used packages. Because setuptools is not widely used? The sec bug was (and remains) linked as a blocker. Is that not explicit or easy enough? When arch people get dozens to hundreds of bug emails per day, no, it's not. A simple "this is now a security issue, see bug blah" makes it an awful lot easier for arch people to prioritise -- emails that merely show blockers added or removed tend to get ignored because a) they're almost always meaningless changes from the arch team's perspective, and b) the bug email doesn't convey any useful information on its own anyway. To be clear, the security issue didn't arise until November 7, 2007. The request to keyword setuptools was *not* a security issue until then. Thanks, Marty -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
When arch people get dozens to hundreds of bug emails per day, no, it's not. A simple "this is now a security issue, see bug blah" makes it an awful lot easier for arch people to prioritise -- emails that merely show blockers added or removed tend to get ignored because a) they're almost always meaningless changes from the arch team's perspective, and b) the bug email doesn't convey any useful information on its own anyway. That's making the assumption that anyone looked at it, of course. Please note comment #9 on http://bugs.gentoo.org/show_bug.cgi?id=198346. It was still ~8 days from then that the setuptools keyword was added. So, we have examples of impact due to delay in keywords/etc. Shall we proceed with the discussion of what to do about it? Thanks, Marty -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 18:19:10 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > PS: has anybody checked how viable is now qemu-system ? Testing on qemu isn't anything like testing on real hardware. It's not a reliable or useful way of doing arch work. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 20:32:09 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: > > Perhaps you should have explicitly stated in the bug that it was for > > security reasons and thus a priority. Make things easy for the arch > > teams -- if you have useful information like that, provide it in an > > easy to see place. Looking at that bug, I don't see anything > > indicating that there's any reason it should have been considered > > over more widely used packages. > > Because setuptools is not widely used? > > The sec bug was (and remains) linked as a blocker. Is that not > explicit or easy enough? When arch people get dozens to hundreds of bug emails per day, no, it's not. A simple "this is now a security issue, see bug blah" makes it an awful lot easier for arch people to prioritise -- emails that merely show blockers added or removed tend to get ignored because a) they're almost always meaningless changes from the arch team's perspective, and b) the bug email doesn't convey any useful information on its own anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ryan Hill wrote: >> PS: has anybody checked how viable is now qemu-system ? > > Does it build with GCC 4 yet? not yet... -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: On Sat, 05 Jan 2008 20:18:09 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2 months for mips to keyword it. Security bugs are normally supposed to have enhanced priority for keywording, etc. Perhaps you should have explicitly stated in the bug that it was for security reasons and thus a priority. Make things easy for the arch teams -- if you have useful information like that, provide it in an easy to see place. Looking at that bug, I don't see anything indicating that there's any reason it should have been considered over more widely used packages. Because setuptools is not widely used? The sec bug was (and remains) linked as a blocker. Is that not explicit or easy enough? Thanks, Marty -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sat, 05 Jan 2008 20:18:09 -0600 Martin Jackson <[EMAIL PROTECTED]> wrote: > See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2 > months for mips to keyword it. > > Security bugs are normally supposed to have enhanced priority for > keywording, etc. Perhaps you should have explicitly stated in the bug that it was for security reasons and thus a priority. Make things easy for the arch teams -- if you have useful information like that, provide it in an easy to see place. Looking at that bug, I don't see anything indicating that there's any reason it should have been considered over more widely used packages. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
And what is the impact of that holdup? Have you explained why you consider that to be a priority to the arch teams in question? We had a sec bug on net-snmp that was held up due to dev-python/setuptools not being ~mips. The net-snmp folks added a python module to their distribution, and I added support to the ebuild for it, so now the latest stable net-snmp for mips has a DoS against it. See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2 months for mips to keyword it. Security bugs are normally supposed to have enhanced priority for keywording, etc. Thanks, Marty -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 20:33:15 -0500 (EST) "Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> wrote: > On Sun, 6 Jan 2008, Ciaran McCreesh wrote: > > So nothing that's a priority for the users of those archs then. Now > > please provide specific examples of how anyone is being held up. > > http://bugs.gentoo.org/show_bug.cgi?id=202726 And what is the impact of that holdup? Have you explained why you consider that to be a priority to the arch teams in question? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Sun, 6 Jan 2008, Ciaran McCreesh wrote: So nothing that's a priority for the users of those archs then. Now please provide specific examples of how anyone is being held up. http://bugs.gentoo.org/show_bug.cgi?id=202726 Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ryan Hill wrote: I don't think any of the current suggestions are very good, but I don't have anything better, other than we get more mips/alt-arch ppl or access to hardware. Like I said, I'm willing to buy hardware if I can find any (must ship to Nowhere, Canada). Alright, I put my money where my mouth is and found an R5K O2 for sale in Texas. Hopefully shipping won't be too much. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 09:03:43 -0500 (EST) "Caleb Tennis" <[EMAIL PROTECTED]> wrote: > > If anyone has any examples of where they really are being held back > > and where they really have given the arch teams plenty of time to do > > something, I'd like to see them... Somehow I doubt it happens very > > often, if at all. > > Why? You aren't the person I or anyone else has to make a case to. > In fact, I never would have mailed the list about this to prevent > this very type of potentially-out-of-control discussion from > occurring, except that the e-mail from Mike said that discussion > topics needed to be sent to the list. Ah, so you'd like the Council to jump to some arbitrary decision, rather than hearing specific examples and evidence from all involved? How will providing specific examples of how people are being held up not be beneficial to the decision-making process? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 12:47:51 +0200 Samuli Suominen <[EMAIL PROTECTED]> wrote: > Mainly, talking about categories (yes, categories, no need to mention > single ebuilds at this point) xfce-* and media-* here. So nothing that's a priority for the users of those archs then. Now please provide specific examples of how anyone is being held up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] has_version etc parallelisability
On Sat, 05 Jan 2008 18:29:51 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > src_compile() { > > { sleep 10 ; has_version '>=app-misc/foo-1.23' ; } & > > } > > is & allowed in ebuilds? should? Banning it entirely is excessive. Banning leaving any attached processes between phases is hopefully not going to upset anyone... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: length of the DESCRIPTION variable
Petteri Räty kirjoitti: Current devmanual suggest to not use line lengths over 80 characters. http://devmanual.gentoo.org/ebuild-writing/file-format/index.html I wrote a repoman check that checks that the value doesn't go over 80. This is useful for tools like eix that show the DESCRIPTION. The thing is that lots of ebuilds will fail this currently. Do you think we should use a higher limit like 100? qualudis seems to use 120 currently. Regards, Petteri Seems devmanual is currently putting the limit to 80 too. http://devmanual.gentoo.org/ebuild-writing/variables/index.html DESCRIPTION A short (less than 80 characters) description of the package's purpose. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: length of the DESCRIPTION variable
Current devmanual suggest to not use line lengths over 80 characters. http://devmanual.gentoo.org/ebuild-writing/file-format/index.html I wrote a repoman check that checks that the value doesn't go over 80. This is useful for tools like eix that show the DESCRIPTION. The thing is that lots of ebuilds will fail this currently. Do you think we should use a higher limit like 100? qualudis seems to use 120 currently. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Luca Barbato wrote: Chris Gianelloni wrote: This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved "once and for all" and things can resume normal operation. This thread so far spawned lots of reply from an external contributor making the point of keeping stale ebuilds around and 4 developers against the idea proposing different solutions ranging from force update pending some remote testing to remove the stable keyword for such arches. Anything other suggestions? I don't know, I can kinda see both sides. Alt arches tend to be finicky so it's important that updates are well tested on them. Also they're more prone to break during upgrades, not only because they're more fragile but because upstream is far less likely to have tested on them, so I can see why having a stable tree is important. On the other hand, that stable tree is crufting up badly and also prone to breakage just due to being unmaintained. mips have 225 open bugs, 87 of which they are the assignee. i don't really care about open bugs, but some do, and it's making them crabby. I don't think any of the current suggestions are very good, but I don't have anything better, other than we get more mips/alt-arch ppl or access to hardware. Like I said, I'm willing to buy hardware if I can find any (must ship to Nowhere, Canada). Does anyone from the (current) mips team have anything to suggest? PS: has anybody checked how viable is now qemu-system ? Does it build with GCC 4 yet? -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
В Сбт, 05/01/2008 в 18:19 +0100, Luca Barbato пишет: > Anything other suggestions? I think, arch which does not manage to cope with stabilize bugs force users to use unstable branch so it's good both for developers and users to force such arch to concentrate on fixing real bugs and maintain only unstable branch. Decision to drop stable branch for certain arch should be done by council after request and discussion on -dev having [EMAIL PROTECTED] in CC. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh kirjoitti: If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. Maintainers want that the versions they provide to users work. I don't want to make that guarantee for old versions because I don't have the time to test wrt updates to the dependency tree etc. Maintainers could keep the old versions for some time but in my experience the mips team is completely unresponsive (http://bugs.gentoo.org/show_bug.cgi?id=160056). Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Samstag, 5. Januar 2008, Wulf C. Krueger wrote: > > Anything other suggestions? > > Let the maintainer of said package decide on the keywording (and therefore > how to handle slacker arches). That's not a good idea. What Gentoo needs is users (and this includes co-develoepers) having a reliable maintenance experience across the repository and developers not following our maintenance policies to be booted. In fact the MIPS team should have been given a last chance to reduce the number of keyworded packages to a number the team can handle and otherwise we should have said "Sorry, but goodbye MIPS." long long ago. That said, the only reason the old KDE ebuilds are still in the tree is that I didn't kick my ass to do it, yet. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] has_version etc parallelisability
Luca Barbato kirjoitti: Ciaran McCreesh wrote: On Fri, 4 Jan 2008 18:50:56 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: Depends on the implementation; for pkgcore, if that comm pipe is dead, the ebuild env *should* be dead, or dieing. Background'ing processes from that env isn't valid imo, either. Right. Paludis will give a weird die message but not actually fail if you do: src_compile() { { sleep 10 ; has_version '>=app-misc/foo-1.23' ; } & } is & allowed in ebuilds? should? lu I would say that nothing started in src_* functions should be running when the function exits. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Saturday, 05. January 2008 18:19:10 Luca Barbato wrote: > This thread so far spawned lots of reply from an external contributor > making the point of keeping stale ebuilds around and 4 developers > against the idea Make that 5. > Anything other suggestions? Let the maintainer of said package decide on the keywording (and therefore how to handle slacker arches). An example: An arch cares more about e. g. games (and proudly blogs about it) than KDE. In such a case in the future I'm going to try to work it out with the respective arch and if they don't react in a timely manner, I'll simply remove the stale ebuilds (or whatever action is appropriate). And, if that has happened often enough, I will take appropriate steps to make sure such stuff doesn't happen again, e. g. by making sure the ebuilds I maintain are not keyworded by the respective arch again until their problems have been resolved. As will be the case for KDE4. It won't get any mips keyword. As for Ciaran's remarks - yes, theoretically, he is right but I don't see him arch testing for mips so his remarks are pretty meaningless to me. -- Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] has_version etc parallelisability
Ciaran McCreesh wrote: > On Fri, 4 Jan 2008 18:50:56 -0800 > Brian Harring <[EMAIL PROTECTED]> wrote: >> Depends on the implementation; for pkgcore, if that comm pipe is >> dead, the ebuild env *should* be dead, or dieing. Background'ing >> processes from that env isn't valid imo, either. > > Right. Paludis will give a weird die message but not actually fail if > you do: > > src_compile() { > { sleep 10 ; has_version '>=app-misc/foo-1.23' ; } & > } is & allowed in ebuilds? should? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Chris Gianelloni wrote: > This has been an issue for quite some time. Of course, the impact is > debatable, but it seems that we cannot agree ourselves on what is > agreeable, so I see this as a point to bring to the Council simply so it > can be resolved "once and for all" and things can resume normal > operation. This thread so far spawned lots of reply from an external contributor making the point of keeping stale ebuilds around and 4 developers against the idea proposing different solutions ranging from force update pending some remote testing to remove the stable keyword for such arches. Anything other suggestions? lu PS: has anybody checked how viable is now qemu-system ? -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: some sci-mathematics packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Cloos wrote: > Sébastien> sci-mathematics/pariguide: unmaintained since 2002 > > Is there anything actually wrong with this one? > > I don't see any bugs open on it, and it works fine here. > > Dropping packages just because they are stable is rather questionable. Not stable on all arches, and ebuild would need some work. Sorry, not enough time/manpower to take care of packages unmaintained upstream. The pari resources page mentions mathguide as a pariguide successor from the same author. Haven't looked at it yet (and all the doc is in German). - -- Sébastien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHf6jd1ycZbhPLE2ARAsqmAJ4gud6c/cZrzLFAn5SBxp1P4wkSYQCglVS6 wXyu0f1Z3qb8jvy++avwLKo= =vmKh -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
> If anyone has any examples of where they really are being held back and > where they really have given the arch teams plenty of time to do > something, I'd like to see them... Somehow I doubt it happens very > often, if at all. Why? You aren't the person I or anyone else has to make a case to. In fact, I never would have mailed the list about this to prevent this very type of potentially-out-of-control discussion from occurring, except that the e-mail from Mike said that discussion topics needed to be sent to the list. We currently get rid of packages that are unmaintained or are old enough that they pose technical problems for developers with today's tools. I see no difference in establishing some similar kinds criteria for arch team keywords (which I'm not even asking for. I'm simply asking for dialogue to determine what kinds of criteria would be appropriate, if any). Similarly, what would the Gentoo policy be if at some time in the future an arch team had no members? What if it had two members, but they were unable to keep up with stabilization requests and were running 6-12 months behind? "Sorry, there isn't anybody who can mark that stable, but we're hoping to get someone on the team this year" isn't a valid answer in my book. I have no idea what the process is to add an "officially" support arch to the tree, but certainly it's more than just one guy making a few commits. There's some process that has to be gone through, right? Well, there also needs to be an exit strategy for when lack of interest in maintenance no longer means that arch should be supported. But right now, all I'm asking for it when it's appropriate for an ebuild maintainer to not have to spend any more time waiting for the arch team to respond to requests. If you believe that number is 1 billion days, fine. Those of us who have faced the issue and disagree can also make our opinions heard to the council, and let them decide what should be done, again, if anything. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving use.desc
On Friday, 4. January 2008, Donnie Berkholz wrote: > On 14:59 Wed 02 Jan , Mike Kelly wrote: > > While you're at it, I think almost everything in > > desc/video_cards.desc, desc/input_devices.desc, and a few more, could > > use some attention. > > > > In particular, things like nv vs. nvidia are quite confusing. I > > usually end up reading the xorg-server ebuild when I want to makes > > sense of it, which defeats the point of video_cards.desc altogether. > > Are there any programs (make.conf / USE editors) that manage to read and > set that stuff? By read, do you mean read the setting from make.conf or read the description? If the latter, quse reads it. $ quse -D nvidia local:nvidia:gnome-extra/sensors-applet: Enable support for nvidia sensors local:nvidia:sys-power/cpufreqd: Enable nvidia overclocking (nvclock) plug-in video_cards.desc:nvidia: VIDEO_CARDS setting to build driver for nvidia video cards Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 5 Jan 2008 04:32:33 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Fri, 04 Jan 2008 20:20:18 -0800 > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > No offense to anyone, but holding back hundreds of developers and > > thousands of users for a handful of developers > > ...and how exactly are hundreds of developers and thousands of users > being held back? So far as I can see, in cases where anyone really is > being held back, the arch teams are quite happy to prioritise -- the > people who go around moaning about 'slacker archs' rarely if ever > actually have anything holding them back. > > If anyone has any examples of where they really are being held back > and where they really have given the arch teams plenty of time to do > something, I'd like to see them... Somehow I doubt it happens very > often, if at all. > No need to talk about 'slacker archs' since we are REALLY talking about a 'slacker arch' called mips. I've given up hope long time ago, leaving ebuilds behind with KEYWORDS="mips" since opening bugs seems useless and maintaining them is too much work (the target of stabilization or keywording changes many times before the bug is finally touched) Mainly, talking about categories (yes, categories, no need to mention single ebuilds at this point) xfce-* and media-* here. IIRC, paludis has the "imlate" script you can use. - drac -- [EMAIL PROTECTED] mailing list