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
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
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] 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
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] 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
[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
[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
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] 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] 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
[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
[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
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
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, 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
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: 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
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: 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: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
