[gentoo-dev] Re: GLEP 27
Doug Goldstein <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 10 Apr 2008 16:35:36 -0400: > How does everyone feel about the proposed layout and syntaxes of GLEP > 27? > > Do we want to revisit this GLEP with an updated GLEP or status quo? > > http://www.gentoo.org/proj/en/glep/glep-0027.html For those who don't know their GLEPs by number, this is Portage management of UIDs/GIDs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 April 2008
On Fri, Apr 11, 2008 at 01:41:09AM +0100, Ciaran McCreesh wrote: > On Thu, 10 Apr 2008 17:37:31 -0700 > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > > That's why I setup them up with the ability to rsync it, and they > > never got back to me on that, nor used it ever. > Hrm, curious. They seem interested and alive currently. Perhaps it's > worth another shot... Get Robin Lackey @ OhLoh to mail me again then. I'm busy the next week as I'm at the MySQL conference in Santa Clara, but it's just a matter of giving him the access details again. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpUrLXyLyaMP.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 April 2008
On Thu, 10 Apr 2008 17:37:31 -0700 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > That's why I setup them up with the ability to rsync it, and they > never got back to me on that, nor used it ever. Hrm, curious. They seem interested and alive currently. Perhaps it's worth another shot... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 April 2008
On Fri, Apr 11, 2008 at 01:28:43AM +0100, Ciaran McCreesh wrote: > On Thu, 10 Apr 2008 17:21:20 -0700 > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > > Having OhLoh would be nice, but over the course of the last year, > > they've found that their system is not really capable of handling the > > scope of the gentoo-x86 CVS tree. > As I understand it, they need a full history to start off. But once > they have that, it's just a case of pulling every commit, which they > should be able to handle. Jason Allen said today that a tarball of the > repo should probably be enough to get it working. That's why I setup them up with the ability to rsync it, and they never got back to me on that, nor used it ever. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpQ8uXZL7tE7.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 April 2008
On Thu, 10 Apr 2008 17:21:20 -0700 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > Having OhLoh would be nice, but over the course of the last year, > they've found that their system is not really capable of handling the > scope of the gentoo-x86 CVS tree. As I understand it, they need a full history to start off. But once they have that, it's just a case of pulling every commit, which they should be able to handle. Jason Allen said today that a tarball of the repo should probably be enough to get it working. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 April 2008
On Thu, Apr 10, 2008 at 04:50:52PM -0700, Donnie Berkholz wrote: > Ways to track commit stats of various sorts came up, such as cia.vc > and ohloh. cia seems to have too much downtime to rely on. ciaranm > talked with ohloh people already. ohloh would require some > modifications to ohcount to recognize ebuilds and eclasses, and a > full copy of the cvs repository to start, but it seems worth > exploring. Betelgeuse said he would tar up a copy of the gentoo-x86 > repo. Having OhLoh would be nice, but over the course of the last year, they've found that their system is not really capable of handling the scope of the gentoo-x86 CVS tree. Their system tries to get the full history every time, which is a design issue. See the constant failures here: http://www.ohloh.net/projects/gentoo/enlistments?query=gentoo-x86&sort=module_name&commit=Update I did get in touch with them a year ago: http://www.ohloh.net/forums/11/topics/183 This moved to private email, and I suggested some changes to how they were doing it, as well as telling them how to fetch the gentoo-x86 tree with rsync - but they (Robin Luckey) never got back to me beyond that. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpB1XI3PDkNy.pgp Description: PGP signature
[gentoo-dev] Council meeting summary for 10 April 2008
Hi all, Here is the summary from today's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. Thanks, Donnie Quick summary = GLEP 46 (Allow upstream tags in metadata.xml): Approved Slacker arches: Vapier's proposal is going out tonight. Minimal activity for ebuild devs: We're trusting the judgment of the undertakers. Also looking into Ohloh for commit stats. Initial comments on PMS: Unapproved EAPIs cannot go into the approved document. Roll call = (here, proxy [by whom] or slacker?) amnehere betelgeuse here dberkholz here flameeyes proxy [tsunam] lu_zero slacker vapier here jokey here Updates to last month's topics == http://www.gentoo.org/proj/en/council/meeting-logs/20080313-summary.txt Document of being an active developer - Last month: No updates Updates: No updates Slacker arches -- 3 months ago: vapier will work on rich0's suggestion and repost it for discussion on -dev ML Last month: vapier said he was going to work on it this weekend. Updates: vapier said he's finishing it up and will have it posted tonight. GLEP 46: Allow upstream tags in metadata.xml http://www.gentoo.org/proj/en/glep/glep-0046.html 2 months ago: Caveat on approval about allowed protocols Updates: Restriction to http/https has been dropped as pointed out by council members (amne and Flameeyes if I'm right). The point for restricting the URLs to the mentioned protocols was that they shouldn't link to automatically updated ressources. This has been replaced by an explicit specification and a recommendation that http/http should be favoured over ftp/svn/gopher/etc to make the implementation for automated update discovery tools easier (they should of course ignore URLs they can't handle). Approved. New topics == Minimal activity for ebuild devs Current is 1 commit every 60 days. Should it be higher? Agreement was hard to find. Some people thought it should be 1 commit / week, others said that people have busy lives and questioned the benefits. A number of people did agree that we should trust the judgment of the undertakers. dberkholz suggested that low commit rates may not maintain the quality of the committer, and we should more carefully review the commits of these people. Ways to track commit stats of various sorts came up, such as cia.vc and ohloh. cia seems to have too much downtime to rely on. ciaranm talked with ohloh people already. ohloh would require some modifications to ohcount to recognize ebuilds and eclasses, and a full copy of the cvs repository to start, but it seems worth exploring. Betelgeuse said he would tar up a copy of the gentoo-x86 repo. Initial comments on PMS --- http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git Are there any major changes needed, or just tuning details? The council voted that kdebuild-1 and other unapproved EAPIs could not be in an approved PMS document. The spec isn't a place for proposals or things that will never be submitted for approval by the council. It's a specification, a reference of what is allowed in the main tree. Open floor -- blackace asked about complaints against philantrop, eroyf, and spb. vapier referred that to devrel. Betelgeuse said that there's been no rejection or action on those complaints yet, and internal discussion is ongoing. Philantrop complained that he hadn't heard anything about complaints, and Betelgeuse said that since some members already left, he didn't want to take matters into his own hands in sharing private information.
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Mike Frysinger wrote: there is no compile time problem. it's all runtime. i still think carrying the patch until gcc-4.3 goes stable is OK. 1400_prevent-gcc43-optimization-udivdi3.patch fixes compilation issue, another patch (already in some 2.6.24.x, I guess) fixes direction flag (that well-known runtime bug). So the point is, our current 2.6.24 kernel is safe. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] GLEP 27
How does everyone feel about the proposed layout and syntaxes of GLEP 27? Do we want to revisit this GLEP with an updated GLEP or status quo? http://www.gentoo.org/proj/en/glep/glep-0027.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] glibc-2.7 stabilization
On Thursday 10 April 2008, José Luis Rivero (yoswink) wrote: > Mike Frysinger escribió: > > glibc-2.7 has sat in ~arch for much longer than i would have liked. the > > only real issue holding it back is nscd. > > In alpha we still have a bastard called 205099[1]. We need to track down > the real problem there and fix it before we can mark 2.7 even ~alpha. > Any help from toolchain ninjas is more than welcome. Thanks. as noted, that needs to be fixed in the kernel. working around it in glibc doesnt make the issue go away. you could even call it a security vuln since any non-root user can take down the machine. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Duncan wrote: > Mike Frysinger <[EMAIL PROTECTED]> posted: > > then move on to the gcc 4.3 tracker bug (#198121). once this gets below > > a certain critical mass (i wont know what the critical mass is until > > it's been de-attained), then we'll be ~arching things. people are > > recommended to do a quick sweep of the lower hangers (many bugs have > > simple patches). > > Does this mean I can file bugs without patches whether they aren't yet > filed already, for still-failing ebuilds? Last I checked, I had a few > (3-4 I think, out of 600+ packages on my system, a dozen or so didn't > compile but most had bugs with patches already, and compiled after > applying them), but there have been enough updates since then I'll need > to re-test before I file in any case. > > I wasn't filing them since I didn't have patches and 4.3 was still hard- > masked, but I have been keeping a list. =8^) as long as you dont assign them to gcc-porting, that's fine -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Jan Kundrát wrote: > Donnie Berkholz wrote: > > Presuming you're adding the direction-flag patch to 4.3.0 so it doesn't > > break people on a kernel earlier than 2.6.25? > > gentoo-sources-2.6.24-r4 has that patch, at least when looking at the > changelog. Or is it just for compile-time borkage and not for the > direction flag cleaning? there is no compile time problem. it's all runtime. i still think carrying the patch until gcc-4.3 goes stable is OK. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Santiago M. Mola wrote: The GLEP should be updated. "Motivation" section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ Sorry, I missed this email, but I'll be at the council meeting to listen in on talk about GLEP 46. Having Freshmeat, SourceForge etc. project id's in metadata.xml sounds great. I would gladly write a tool to go through SourceForge and Freshmeat's metadata and match project names to ebuild package names using HOMEPAGE. I already have code to parse FLOSSMole's[1] metadata, so it'd be simple to whip up quickly. doapspace.org has an API that lets you give a SourceForge, Freshmeat, PyPI and RubyForge project name and get metadata back, so having a link to the DOAP's URL in metadata.xml isn't really needed for those. For self-hosted projects, we could either put a link to the DOAP in metadata.xml, or simply make sure the HOMEPAGE matches the homepage in the DOAP itself. The second is preferable because the URL to the DOAP could change. Meatoo will be much more accurate after I cross-reference metadata from FLOSSMole to map Gentoo package names to other forge/package index names. Once that's done, we'll have very accurate version bump info that can be looked up by herd/maintainer, from SourceForge, RubyForge, Freshmeat etc. Rob [1] http://ossmole.sourceforge.net -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
I win, as always *g* -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: gcc-4.2 / gcc-4.3 plans
Mike Frysinger <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 10 Apr 2008 02:57:11 -0400: > then move on to the gcc 4.3 tracker bug (#198121). once this gets below > a certain critical mass (i wont know what the critical mass is until > it's been de-attained), then we'll be ~arching things. people are > recommended to do a quick sweep of the lower hangers (many bugs have > simple patches). Does this mean I can file bugs without patches whether they aren't yet filed already, for still-failing ebuilds? Last I checked, I had a few (3-4 I think, out of 600+ packages on my system, a dozen or so didn't compile but most had bugs with patches already, and compiled after applying them), but there have been enough updates since then I'll need to re-test before I file in any case. I wasn't filing them since I didn't have patches and 4.3 was still hard- masked, but I have been keeping a list. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] glibc-2.7 stabilization
Hey Mike: Mike Frysinger escribió: some heads up here glibc-2.7 has sat in ~arch for much longer than i would have liked. the only real issue holding it back is nscd. In alpha we still have a bastard called 205099[1]. We need to track down the real problem there and fix it before we can mark 2.7 even ~alpha. Any help from toolchain ninjas is more than welcome. Thanks. [1] http://bugs.gentoo.org/show_bug.cgi?id=205099 -- Jose Luis Rivero <[EMAIL PROTECTED]> Gentoo/Doc Gentoo/Alpha -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: glibc-2.7 stabilization
On Thu, 10 Apr 2008 03:02:17 -0400, Mike Frysinger wrote: > some heads up here > > glibc-2.7 has sat in ~arch for much longer than i would have liked. the > only real issue holding it back is nscd. i never use this thing myself, > but on some arches (like ppc), it's known to eat your cpu like a dirty > C-globbler (where C is short for CPU). on other arches, it's known to > just cream itself for fun and then promptly exit. Interesting - I saw nscd dying every so often with 2.6 (x86) but at least for me that seems to have stopped since 2.7. Not sure what I'm doing wrong :) On slower systems it certainly makes a noticeable difference. -h -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Donnie Berkholz wrote: Presuming you're adding the direction-flag patch to 4.3.0 so it doesn't break people on a kernel earlier than 2.6.25? gentoo-sources-2.6.24-r4 has that patch, at least when looking at the changelog. Or is it just for compile-time borkage and not for the direction flag cleaning? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Mike Frysinger wrote: > Also, you'll have to provide a URL to said change. i havent seen a > patch for it in my random driftings on the interweb. > -mike I was just researching the issue, so had this handy: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00417.html -- /PA -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Donnie Berkholz wrote: > On 02:57 Thu 10 Apr , Mike Frysinger wrote: > > gcc-4.3 seems to be standing up well. since the major > > gcc-ebuild-specific issues seem to be resolved now, i'll probably do a > > sweep of bugs to see if there's any patches i'm missing (if you guys know > > of a bug that should be addressed specifically in the gcc-4.3.0 ebuild, > > speak up now). > > Presuming you're adding the direction-flag patch to 4.3.0 so it doesn't > break people on a kernel earlier than 2.6.25? I didn't see it in a quick > glance at the patch tarball. i had no plans to revert the behavior in question. i could be persuaded to carry such a patch though until 2.6.25 goes stable and gcc-4.3 goes stable. presumably the time frame of both of those should be "long enough". also, you'll have to provide a URL to said change. i havent seen a patch for it in my random driftings on the interweb. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] VDB access
Ciaran McCreesh a écrit : The following things access VDB by hand: * gnome2-utils.eclass. Will be fixed once a portage with proper env saving goes stable, which isn't too far off. Bug 155993. Quick follow-up on that for everyone. The eclass has been modified not to access VDB anymore yet with all the bells and whistles to improve performance, and the concerned ebuilds have been updated. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for April
On 03:03 Wed 09 Apr , Mike Frysinger wrote: > This is your one-day friendly reminder ! The monthly Gentoo Council > meeting is tomorrow in #gentoo-council on irc.freenode.net. See the > channel topic for the exact time (but it's probably 2000 UTC). > > If you're supposed to show up, please show up. If you're not supposed > to show up, then show up anyways and watch your Council monkeys dance > for you. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ Here's the proposed agenda. Added CC for the council list. Thanks, Donnie Requested attendees === GLEP 46: vanquirius, ciaranm, dev-zero PMS: ciaranm, halcy0n Roll call = (here, proxy [by whom] or slacker?) amne betelgeuse dberkholz flameeyes lu_zero vapier jokey Updates to last month's topics == http://www.gentoo.org/proj/en/council/meeting-logs/20080313-summary.txt Document of being an active developer - Last month: No updates Updates: Slacker arches -- 3 months ago: vapier will work on rich0's suggestion and repost it for discussion on -dev ML Last month: vapier said he was going to work on it this weekend. Updates: GLEP 46: Allow upstream tags in metadata.xml http://www.gentoo.org/proj/en/glep/glep-0046.html 2 months ago: Caveat on approval about allowed protocols Updates: Restriction to http/https has been dropped as pointed out by council members (amne and Flameeyes if I'm right). The point for restricting the URLs to the mentioned protocols was that they shouldn't link to automatically updated ressources. This has been replaced by an explicit specification and a recommendation that http/http should be favoured over ftp/svn/gopher/etc to make the implementation for automated update discovery tools easier (they should of course ignore URLs they can't handle). Ready for confirmation, which should be mainly a formality. New topics == Minimal activity for ebuild devs Current is 1 commit every 60 days. Should it be higher? Initial comments on PMS --- http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git Are there any major changes needed, or just tuning details?
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On 02:57 Thu 10 Apr , Mike Frysinger wrote: > gcc-4.3 seems to be standing up well. since the major gcc-ebuild-specific > issues seem to be resolved now, i'll probably do a sweep of bugs to see if > there's any patches i'm missing (if you guys know of a bug that should be > addressed specifically in the gcc-4.3.0 ebuild, speak up now). Presuming you're adding the direction-flag patch to 4.3.0 so it doesn't break people on a kernel earlier than 2.6.25? I didn't see it in a quick glance at the patch tarball. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] glibc-2.7 stabilization
some heads up here glibc-2.7 has sat in ~arch for much longer than i would have liked. the only real issue holding it back is nscd. i never use this thing myself, but on some arches (like ppc), it's known to eat your cpu like a dirty C-globbler (where C is short for CPU). on other arches, it's known to just cream itself for fun and then promptly exit. glibc-2.8 is supposed to be out soonish, and if nscd insists on continuing to be a pile, i'm afraid of having to just dump in a bunch of reverts. nscd in glibc-2.6.1 seems to be generally OK. -mike signature.asc Description: This is a digitally signed message part.
