Re: [gentoo-dev] GLEP ??: Critical News Reporting
Nathan L. Adams wrote: [Thu Nov 03 2005, 07:02:58PM CST] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ciaran McCreesh wrote: > > Read the list of requirements in the GLEP. The plain text solution > > meets all of them. XML fails on several. > > If readability isn't a requirement, your list is wrong. I would argue that reading raw xml is a lot less fun than reading minimally marked-up plain text (such as an e-mail). > > | So what are the trade-offs of the 'flat file'? If you store a > > | migration guide as a 'flat file', its not going to be very readable. > > > > Who said anything about storing a migration guide as a flat file? Read > > the GLEP. > > No, *you* need to read my previous response. I was using 'flat file' to > mean whatever it is you're calling your less-than-GuideXML scheme. *Sigh* I think you might be misinterpreting the GLEP. The news items are likely to be fairly short, such as the "YourSQL" example that's in the GLEP. The news item would then point to a migration guide that resides elsewhere, if needed. The point behind having the news pulled by portage is that the headless server, for example, would only report news items that are relevant to that machine. The server's admin could then fire up a web browser on a desktop machine to read any necessary additional info. > > | GuideXML is the standard for Gentoo docs for some damn good reasons! True, but at the same time there's a reason that GLEPs can be written in restructured text as well as guidexml. I doubt that it's accidental that almost all GLEPs have been submitted in restructured text rather than guidexml. (Incidentally, I like our guidexml. I think that it renders quite well for what we want. I'm not so fond of writing it, however.) That's really beside the point, though. The real point is that plain text news items are going to be the easiest to create and the easiest to read on a console screen. As for having an errata page, it wouldn't be difficult to write a program to automatically convert news items to guidexml. I suspect that ciaranm could even be talked into writing it, if such a page were to become reality. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgppllN4FWKVp.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: [Mon Nov 07 2005, 06:37:10AM CST] > So what's the point of the ChangeLog again? Move load from the CVS > server and onto the rsync servers? (Don't answer that - just beating a > dead horse ;) *Grin* I'm going to answer anyway, since the answer isn't necessarily obvious to everybody. Once upon a time, the expectation was that the ChangeLog contained information about package modifications that would be of interest to users, while the CVS log would contain info mainly of interest to devs. Of course, that was when viewcvs accessed the live tree, too. Since then, there seems to have been a consensus that the CVS log should really be autogenerated from the ChangeLog, which itself is created using ``echangelog``. My view is that the ChangeLog should contain user-readable descriptions (although we also encourage some useful jargon such as "version bump") of every change a package has undergone, providing a fairly complete history for that package that is much more readable than iterating through CVS diffs. Consequently, the ChangeLog has far too much information to realistically serve as a low-noise news source. (One could imagine tagging certain ChangeLog entries as being particularly important, but that forces news to be package based, and seems overly complicated, so please forget that I ever brought it up.) > I'm really just against having it in emerge, especially with the current > suggestion of portage just doing a little bit of maintenance work for > external tools and nothing else. I'm not sure exactly what you're arguing here. Is it just that you think that the news stuff should be a post-sync hook instead of being triggered explicitly by "emerge"? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpsn76RkqrpW.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Marius Mauch wrote: [Fri Nov 11 2005, 11:40:53AM CST] > Things that I'd like to be changed/I'm not completely sure about: > - filtering of news items: > I've already asked a similar question in another mail (in other > context) without an answer, but how many news items do people believe > will exist at any given time? Depending on the actual implementation it > might be required to scan all existing news items which could take some > time if there is a large number of them (say, more than a few hundred) > It's clear that noone can present accurate numbers, just after some > rough estimates here. The GLEP sets the bar pretty high for what should be a significant news item, so my extremely rough guess is that 30/year would be on the quite high side. Ideally this system should extend, not supplant, the normal einfo/ewarn notices. (Um, what is the status of the einfo/ewarn message system that went into CVS. Any ETA on when it's going to be back-ported to current portage? I could see where there might be a tendency to abuse the news system if the messaging stuff is still unavailable.) > Also it might be useful for this filtering to be an external tool using > portage functions and called by portage (see also below). Although this > could be considered an implementation detail as it's mostly transparent > for ebuild devs/users. I'm not quite sure what you're saying here. > - local storage of news items / "read" attribute: > I don't really the like the copy-if-new feature and handling at the fs > level, I'd use a file that lists the ids of news items (potentially > with a timestamp and/or status field). I don't see any benefits of > having redundancy here, and accessing the news in $PORTDIR is simple > enough. Granted race conditions might be an issue (where the solution > complicates tools), but that's so minor I wouldn't really care about > it. My impression was that ciaranm was thinking of using something akin to a Maildir mailbox to hold and handle news items, because then one can leverage an insane amount of existing stuff. *Shrug* I also wouldn't object to a flat list of pointers to relevant files. > Another thing that's unclear: "Whenever relevant unread news items are > found, emerge will copy or symlink the news file into > /var/lib/gentoo/news/." > This "Whenever ... are found" is too vague, should this apply to emerge > --sync, any emerge operation, any "import portage" call or what? This > isn't just an implementation detail. I was going to say that the only way new news items could appear is during an emerge --sync, but of course that's not true for people who either add an overlay or use CVS. I'd be comfortable with making it run only at --sync time, or if it were triggered explicitly (--check-news, or some such). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpO9PSqeL1kS.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
Ciaran McCreesh wrote: [Tue Nov 08 2005, 12:04:51PM CST] > On Tue, 8 Nov 2005 17:57:54 + Ciaran McCreesh <[EMAIL PROTECTED]> > wrote: > | Assuming there aren't any further comments between now and then, I'd > | like GLEP 34 (GLEP File Hosting) to be approved please. > > No, 43. Not 34. Bleh. Whoops, 43 just requires local approval, since it isn't really cross-project, so I've approved it (as the lead GLEP editor). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpEWTzwudrE7.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
Homer Parker wrote: [Fri Nov 11 2005, 08:09:11PM CST] > Just want to be sure that GLEP41 is on the list. GLEP 41 was rejected by the council at the last meeting, pending a rewrite that addressed the issues brought up at that meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt According to CVS, the GLEP hasn't been updated since the last meeting, so I'm assuming that the GLEP's authors aren't ready yet. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpTUuIwoYYgd.pgp Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Thierry Carrez wrote: [Mon Nov 14 2005, 03:09:24AM CST] > Voting > - GLEP 41 (requested by Homer Parker) My recollection was that GLEP 41 was rejected at the last meeting, although a revised GLEP could be resubmitted for approval. As far as I know, however, the GLEP has not yet been revised. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpoataSnjjIE.pgp Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Marius Mauch wrote: [Mon Nov 14 2005, 08:05:44AM CST] > > Discussion > > - Portage Tree signing status (requested by Marius Mauch) > > Ehm, I didn't request anything. Grant did ;) Yep, I did make the request, but it is genone who did all of the hard work. I'm just pushy. *Grin* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgprkGPbJisnj.pgp Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Thierry Carrez wrote: [Mon Nov 14 2005, 10:28:23AM CST] > v 1.3 looks like a revised version to me (on Nov 11) : > http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0041.txt?r2=1.3&root=gentoo&r1=1.2&diff_format=u Hmmm, I'm not sure how I missed that one, but clearly I did. Did it get sent out to -dev for comments? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp0Yd5GWcsZg.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Curtis Napier wrote: [Fri Nov 18 2005, 04:44:53PM CST] > >The problem with staff is that staff who aren't ATs/HTs won't be using > >it... > > > > I agree with this. Those of us who don't have commit rights to the tree > should have an @staff.g.o, people like me for instance. I happen to be > part of two projects but neither gives me access to the tree so I would > get an @staff.g.o and am fine with that. It lets people I email outside > of the project know that I am staff and not a developer. I rather strongly disagree. It is true that in the past we have used the word "staff" to denote devs who do not have gentoo-x86 commit access. I've never been in favor of that terminology, however. Devs are devs, whether they have gentoo-x86 commit access or not. Our doc devs or infra devs can break Gentoo in ways just as horrific as our devs w/ tree access can. Infra, doc, or tree access just determines which part of Gentoo you're allowed to break (in a rather twisted way of looking at things). It's terribly important to me that we not somehow end up with first-class devs and second-class devs. My preference is that the subdomain chosen should succinctly reflect the role that arch testers serve. My personal preference would be to choose something like "aide", "helper", "assistant", or something similar. (Indeed, I'd have preferred "volunteer" if it weren't for the niggling fact that we're all volunteers.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp2nRREEEbCZ.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Jakub Moc wrote: [Fri Nov 18 2005, 06:07:48PM CST] > > 19.11.2005, 0:58:29, Grant Goodyear wrote: > > > My preference is that the subdomain chosen should succinctly reflect > > the role that arch testers serve. My personal preference would be > > to choose something like "aide", "helper", "assistant", or something > > similar. (Indeed, I'd have preferred "volunteer" if it weren't for > > the niggling fact that we're all volunteers.) > Once again - I don't know if it's not been clear enough so far, from > the replies on this topic: I don't have time nor desire to dig out > somewhere on the web what's the correct email I should use to contact > someone... there are about 200 more or less active Gentoo devs around > and the last thing I need is to ponder upon what project/role that > particular person is on. What's the benefit? Perhaps you should re-read the GLEP? Or the log from the last two Council meetings? Nobody is suggesting that devs should have their e-mail addresses changed to [EMAIL PROTECTED] The issue is what e-mail address to give people who are helping out Gentoo but not actually devs. Since these people are not going to be maintaining packages, it seems unlikely that you're going to have to spend all that much time trying to figure out how to contact them; just hit "r" like you would with any other user. Incidentally, the benefit is to make users who are actively helping Gentoo feel like they're part of the family. It was decided that a straight @gentoo.org address would be confusing, though, since most people associate those addresses with developers. I'm fairly agnostic on the whole thing, myself, but since the Council voted to approve the GLEP, I was simply trying to do my best to put forth a proposal that fit within that framework. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpQ1PsROd24D.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Kurt Lieber wrote: [Fri Nov 18 2005, 06:22:28PM CST] > @yellowstar.gentoo.org > > You can now declare godwin's law. tyvm & hand Huh? > --kurt (who finds the very idea of "second-class devs" revolting and > embarassing) I happen to agree with that sentiment. It's just not clear to me that it applies here. *Shrug* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpadGGTi2D8u.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Lance Albertson wrote: [Fri Nov 18 2005, 05:46:47PM CST] > Anyways, I don't see any problem with us giving them straight up > [EMAIL PROTECTED] aliases. They won't have shell access, nor cvs so we > don't have to worry about that. This makes it very simple for us infra > folks to manage. I can only imagine the hell we'll create when someone > moves from staff.g.o to tester.g.o to g.o. I will not support any GLEP > that proposes any nonsense like that since its totally not needed. Yes, > I could have spoken up about this sooner, but I can't keep track of > every thread on -dev. I believe that the issue was that @g.o addresses generally denote a dev, and that giving such addresses to people who are not devs could cause confusion. For example, suppose we have a user who specializes in a particular imap server. If there were an urgent security issue, such a user might get a request to stable the package despite the fact that the person isn't a dev, which wouldn't serve anybody. A simpler method would be to ditch the idea of handing out e-mail addresses to users, no matter how much work they do for us, but that idea wasn't much more popular than any of the others. *Shrug* > I'm very disappointed that the council did not wait on the vote for this > considering the sudden submission of the revision of the GLEP. I'm > curious the reasoning for going ahead with this? Have you read the log? It's fairly clear why they did it; they were being nice, because although I always intended the GLEP process to be iterative, with plenty of time for comments, I never put it in writing.. I personally think that it would have been better to hold off until next month, but it was a judgement call, and I don't think it was wholly unreasonable. The Council did go out of their way to emphasize that there should not be a repeat of this event. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpJlpqHg65zD.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Jakub Moc wrote: [Sat Nov 19 2005, 02:11:19AM CST] > Grrrmhhh, was it so much unclear? I mean: "stable on x86" definitely > belongs to changelogs, while "stable on x86, thanks Jim for opening a > keywording bug, Jack and Jim for testing and Joe for reminding me five > times to mark it finally stable when I forgot about it" does NOT. I personally think: "stable on $arch, thanks to Jim and Jack (Bug #$bug)" satisfies the desired property of terseness while still suitably acknowledging those who have done the work. Moreover, there's been an informal policy of acknowledging helpful users in ChangeLogs for years now. > It's the responsibility of the developer who keyworded the thing anyway, ATs > are not allowed to keyword stuff and don't have RW CVS access, so what is the > purpose of tracking such stuff in changelogs and cluttering them? Use CVS > commit messages to track such things if you think you need it. I generally suggest that devs follow agriffis' lead and use a tool that generates the CVS commit message from the ChangeLog message. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpezey9m0Gwt.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
Corey Shields wrote: [Fri Nov 18 2005, 10:42:30PM CST] > Still screwed up. Lesson learned, make friends with a majority of the > council, write and propose a glep the day before a meeting and then push it > through. wow. sounds a lot like American politics. That's quite an indictment. You've skipped right past the notion that perhaps a mistake was made to accuse the Council of cronyism. As somebody who's been part of devrel, and thus the recipient of exactly that type of response more than once, I would think that you would have known (and done) better. Incidentally, the GLEP was originally revised and posted on glep.g.o on 11 November before the 2000 UTC deadline to request being added to the agenda for the 15 Nov. meeting. When hparker updated the GLEP he made a rookie mistake, and forgot to update the Post-History field, so when I looked at the GLEP I assumed that it hadn't been updated. It's clear that the GLEP authors assumed that they just needed to incorporate the changes that the Council suggested, and that approval would be pro forma. In fact, they should have submitted the GLEP to -dev for another round of comments. Indeed, this GLEP reveals that there are a number of misconceptions in how the GLEP process is supposed to work. Here's what was supposed to happen. (Yes, it's my fault for not ensuring that it did, and I very much apologize.) After a GLEP is approved by the GLEP editor for posting to glep.g.o, the GLEP is sent to -dev for comments. Sane disputes should then be incorporated into a revision of the GLEP, where such disputes should be addressed and either incorporated or rejected with an explanation of why. There were, indeed, a number of disagreements with this GLEP when it was first released, and they are not at all documented in the GLEP. This process is iterated until some sort of steady state is reached, at which point the GLEP authors are supposed to tell the GLEP editor that they are ready for it to go up for approval. This step is actually fairly important, since the GLEP editor is responsible for determining who the "controlling authority" is for the GLEP. A full Council vote is only needed on GLEPs that are cross-project (or that lack a project). Both times that this GLEP went up for approval I should have been much more assertive in stating that this GLEP was not yet ready. (It's not the GLEP editor's place to prevent a GLEP from going up for approval, however. The assumption is that a not-yet-ready GLEP will simply be voted down.) In any event, mistakes happen. The real question is what to do next. This GLEP has been approved, for good or ill. Either the GLEP authors can offer a revision that incorporates the disputes that are coming up now (and that came up before but were never addressed), or somebody can write a new GLEP that would supersede this one, or people can just live with the current version. In any case, you have my apology for not doing a very good job with this one. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcXgkhwTCvY.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
Kurt Lieber wrote: [Sat Nov 19 2005, 04:42:41PM CST] > On Sat, Nov 19, 2005 at 05:06:15PM + or thereabouts, Kurt Lieber wrote: > If the requirement is for r/o CVS access to the same CVS server that the > pure-blooded developers use (sorry, couldn't resist) then it may require > upgrades to our existing server and/or purchasing a new server. What about authenticated viewcvs on the live CVS server instead? Back when we had a live viewcvs I used to use it all the time for doing exactly what the ATs want to do now, and I assume that viewcvs puts much less load on the server than a CVS pull does. In any event, do we need a new server anyway? We actually do have some money that could be spent on such things, and the CVS server is really high on the list of for which I, personally, would be more than willing to spend it. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpz3yxh2JmYl.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
Kurt Lieber wrote: [Sat Nov 19 2005, 04:47:37PM CST] > OK, fine. Devrel does not have an established track record of retiring > devs who are otherwise inactive. Just as an aside, I've seen scores (if not more) of devs retired within the last couple of months, so I think that problem is currently being fixed. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgprUeUgZpxhD.pgp Description: PGP signature
Re: [gentoo-dev] opinion on how to improve the website redesign
Vapier wrote: [Mon Nov 21 2005, 08:09:55AM CST] > - wheres the ufo guy [2] ? at least hide him in the bottom left > corner of the page ... it'd keep with the mysterious nature of the > fellow > [2] http://www.gentoo.org/images/gridtest.gif Drobbins wanted to hang on to Znurt when he left. You're welcome to ask his permission to use it on the new site, as he might have changed his mind since then. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpWEm5641oRJ.pgp Description: PGP signature
Re: [gentoo-dev] opinion on how to improve the website redesign
It's interesting to compare http://wwwredesign.gentoo.org/ with http://www.aaronshi.com/gentoo/mainindex.html. One of the things that I always liked about the original design was the fact that the front page held a considerable amount of information without needing much vertical scrolling. On the other hand, I like the fact that the current iteration says something about what Gentoo actually is, which just seems like a good idea on the front page. (Although I'd prefer to modify the text a bit so that it starts with "Gentoo is" and is limited to just one or two sentences.) In fact, I've been thinking that it might be nice to remove the news from the front page altogether (we could always have a news.gentoo.org for people who mainly use the site for news), which would leave plenty of space for the "Documentation", "Resources", and "Community" panels with limited scrolling. As an aside, I would prefer to see something fairly soon, even if it's more a face lift than a redesign, than wait another year before we update the site. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp7dudyG23en.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Chris Gianelloni wrote: [Tue Nov 22 2005, 09:15:27AM CST] > > Well, if we could educate the users that stage2 tarballs are totally > > pointless, and that running bootstrap.sh followed by emerge -e system > > from a stage3 is pretty much *exactly* the same as starting a stage1 > > from scratch... > > It isn't pretty much anymore. It *is* exactly the same. I keep hearing this, isn't there a real difference between a stage 1 and a stage 3 install inasmuch as somebody who needs (or wants) to dramatically tailor what's in the system profile can choose to do so from a stage 1 or 2, but would have to remove packages after the fact if starting from a stage 3? I wouldn't have a problem with that, as long as we document it, but it just seems that the claim that the old and new methods produce _exactly_ the same results seems to be stretching things a bit. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp6Gs5lhB168.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Ciaran McCreesh wrote: [Tue Nov 22 2005, 12:17:47PM CST] > On Tue, 22 Nov 2005 12:03:49 -0600 Grant Goodyear <[EMAIL PROTECTED]> > wrote: > | I keep hearing this, isn't there a real difference between a stage 1 > | and a stage 3 install inasmuch as somebody who needs (or wants) to > | dramatically tailor what's in the system profile can choose to do so > | from a stage 1 or 2, but would have to remove packages after the fact > | if starting from a stage 3? I wouldn't have a problem with that, as > | long as we document it > > emerge -e world && emerge -e world && emerge depclean Cool. Why rebuild twice? Any chance we could add this to the FAQ? > | but it just seems that the claim that the old and new methods produce > | _exactly_ the same results seems to be stretching things a bit. > > How do you think stage3s are built in the first place? Sorry, poor phrasing on my part. Of course it's true that if one follows the handbook (either the current or the previous version), then one ends up with the same system regardless of whether or not a stage1, stage2, or stage3 is used. What I intended to suggest was that tinkering at the system level is less obviously accomplished when starting from a stage3, so the occasional assertion I've read that starting from a stage 1 or stage 2 provides no benefits over starting from a stage 1 or 2 didn't seem right to me. In any event, I don't mind the handbook changes, although I'd perhaps like to see the FAQ for starting from a stage 1 fleshed out a tad, such as including a paragraph of why one might not want to do that. Perhaps steal from whomever posted a treatise on the issue some time ago (either rac or avenj, I don't remember which)? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpuMGNgCEAnY.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Chris Gianelloni wrote: [Tue Nov 22 2005, 01:06:03PM CST] > Who said that removing something isn't a part of the procedure to get an > identical build? Yeah, my phrasing was lousy (which I noted in another e-mail, but I doubt you had time to see it before replying to this one). > > The point is that following the proper steps, one *can* get the exact > same output. This would include using --newuse and cleaning out unused > packages, along with any other maintenance items that would be required. That's fine with me. All I really want to do is ensure that we preserve our users' ability to tinker with system without making life too painful for them. Starting from a stage 1 it was obvious how to do such tinkering. I would argue that it's not quite as obvious how to do that when starting from a stage 3, so a bit of additional documentation on how to do that would be nice. If that were done, then I would have no complaints about the stage 1 and stage 2 tarballs going away altogether. *Shrug* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpAjhyhwiUPp.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
Diego 'Flameeyes' Pettenò wrote: [Thu Nov 24 2005, 05:31:32AM CST] > What I'm waiting for now are comments if someone has ideas where to > put guides that does not belong directly to an existant project. And > if someone wants to join the effort of documenting maintenance process > for his packages, it would be helpful, too. Assuming that they're reasonably well written, why not add them to The Doc? Alternatively (and perhaps more usefully), what about permitting a MaintainerNotes file in any cat/pkg directory where it would be useful? A plain text file would be easier for people to create and maintain, and its presence would quickly alert devs to potential quirks with a possibly unfamiliar package. Of course, the drawback would be the additional tree bloat. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpdPwMPOn195.pgp Description: PGP signature
Re: [gentoo-dev] Multi hash support in portage - status
Marius Mauch wrote: [Thu Nov 24 2005, 04:38:44AM CST] > GLEP I still have to start writing (mostly a reformatting of a mail I > sent a long time ago), there is already a prototype implementation > (doesn't cover everything yet but works generally), target is > for when current trunk will be released (still have to settle on a > version for it), which should hopefully be after 2.0.54 gets out > (which should be in the next few weeks). At a guess I'd say 4 months > till stable (but really, that's just a guess, see the 2.1 fiasko). Personally, I'd much rather see the nascent support go in, even at the cost of expanding the tree a tad, rather than push it off into the fairly distant future. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpveWlvEIX9O.pgp Description: PGP signature
Re: [gentoo-dev] Misquoted in the GWN
Patrick Lauer wrote: [Mon Nov 28 2005, 12:46:57PM CST] > > Also, why not bring back the "post to -core" requirement? Make it a > > rule that it can't be labelled as an official Gentoo publication unless > > it gets some review... Heh. Personally, I've never really been all that fond of the GWN being "an official Gentoo publication"; I'd much rather see it as a true community news source. I've always thought that by making it an official publication it _appears_ to be more propaganda than news. > That Ulrich and I have made some suboptimal decisions in the past is a > fact, but why aren't there more contributors to the GWN so that we two > aren't single points of failure? I suspect that the devs most likely to write an article for the GWN are also those most likely to have a blog on planet.g.o. Given the latter, there's not much incentive for the former. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpd2fFt1C4Jf.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Philip Webb wrote: [Wed Nov 30 2005, 04:34:56PM CST] > As one of the "masses", I am certainly disturbed at that implication. > I don't remember any such need when I upgraded 2.9.5 -> 3.x (now 3.3.6). http://www.gentoo.org/doc/en/new-upgrade-to-gentoo-1.4.xml -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgptsXmrzu1x2.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Manifest2 format
Marius Mauch wrote: [Tue Dec 06 2005, 10:04:53AM CST] > As promised here the GLEP for Manifest2 support: > http://www.gentoo.org/proj/en/glep/glep-0044.html You know, I'd actually support a rather more abrupt transition, where we announce that on a particular date all digest files are going to be removed, thereby breaking any version of portage older than portage-x.y.z. Many people would probably miss such a deadline, but assuming that we also publicize how to download and unpack a portage rescue tarball then I would think that the actual pain would be minimal. (Indeed, we could even have a fix-portage.sh script in /usr/portage/scripts that would do the downloading and unpacking, if we wanted to be particularly nice.) Backwards compatibility is nice, but I'd really rather not see good ideas take a year to fully be implemented unless absolutely required. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpat2Fyk7A3w.pgp Description: PGP signature
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Danny van Dyk wrote: [Tue Dec 13 2005, 02:35:44PM CST] > | I'll accept that change if you get Grant to accept a mini-GLEP > | switching the GLEPs over to use that format too. > > I don't think that we need a GLEP for it, no matter how 'mini' it > would be.. Just asked Grant if I can convert dates in current GLEPs, > and he's ok with, though he wanted to have input from -dev first, so: > > Anyone objecting to change those dates from "dd-mon-" format to > "-mm-dd"? Note that GLEP 1 would need to be amended, too, to reflect the new format. > If not, i'll commit my diff in 24h... I actually had in mind a couple of days, just to make sure that people had a reasonable chance to respond -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpxLb4157UcG.pgp Description: PGP signature
Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
Ciaran McCreesh wrote: [Tue Dec 13 2005, 02:43:42PM CST] > I object. You're changing the GLEP process, and the way that that's > done is through another GLEP. Otherwise we'll end up with people > writing GLEPs following GLEP 1, and not realising that GLEP 1 is no > longer how things work. > > Doing things properly wouldn't be difficult here. GLEP 43 took less > than half an hour. It's worth doing it for the sake of not confusing > future GLEP authors. Okay, I'll acquiesce to the call for a GLEP. It seems a tad extravagant, since I'll be the one approving it, but I can agree that having the change documented would be useful. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpwHiBPFT5Es.pgp Description: PGP signature
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] > The purpose of GLEPs is to coordinate several teams into providing an > overall enhancement to Gentoo. However, the GLEP itself is written by > a single person rather than a cooperative effort between the teams. You know, there's no reason that GLEPs need to be written by a single person. It's often true, though, that it is a single person's idea, initially at least. > Specification > > Rather than coming to the ML with a completed GLEP and then asking for > feedback, a GLEP author should look at the teams involved and then > select a solicit a member from each team to be responsible for that > area of the GLEP. The GLEP author may represent any teams they belong > to. Throwing out the initial GLEP amounts to the same thing, in my opinion, since any interested parties are urged to provide feedback, and ideally the next revision will include that feedback, either to accept it or reject it. > Rationale > > Rather than doing lots of hard work and having it thrown away once it > is found to be unacceptable by the teams involved, the teams involved > share the hard work and come up with something acceptable to everybody > right from the outset. Yes, of course, GLEP authors should talk to the folks who are likely to be affected beforehand, but if they fail to do so then the GLEP process is likely to be rather protracted for that GLEP. I have to admit that I have no problem with people doing hard work for little gain, if that's what people want to do. *Shrug* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp0pldxoayh2.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] > > | There doesn't need to be a debate. This whole proposal doesn't care > > | about portage compatibility whatsoever and it's exactly this style of > > | thinking that slows down portage development (which everybody loves > > | to complain about so much). > > > > Sure it does. It cares about the way Portage is currently, and it cares > > about any reasonable future Portage changes. > > Bullshit. I'm not quite sure I understand the strong response. The GLEP was clearly designed to have a minimal impact on portage. Now I'm willing to listen to arguments that it does not, in fact, do that, but certainly the well-defined, minimal coupling between the news and emerge was not accidental. (Incidentally, I've never complained about the pace of portage development. I'm not developing it, so I don't complain about those who are.) Just as an aside, it would be nice if we could keep [EMAIL PROTECTED] vulgarity-free, since it's a list that's often read at work by a good number of people. > > > | As I said already, there will immediately be a bug asking for overlay > > | support. Portage already supports multiple in a form whether anybody > > | likes it or not. How they are supported and how they will change > > | should be of no concern to the glep. What should be of concern is > > | establishing a robust API between the readers and portage such that > > | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp9qHX6VO2Cp.pgp Description: PGP signature
Re: [gentoo-dev] GLEP XX - GLEP date and time format
Henrik Brix Andersen wrote: [Tue Dec 13 2005, 03:41:55PM CST] > Since I have no idea on how to use docutils, I'd be grateful if > someone familiar with the process (Grant?) could commit this to CVS. Committed to CVS. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpLxpJ2UeD24.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Tue Dec 13 2005, 05:44:39PM CST] > > Wouldn't it suffice for the GLEP to simply have a statement that it will > > query portage for a list of repositories, once there's a way to do that, > > but until then the default repo will be assumed? > > Modifications are required to portage anyway. Why postpone it until after > several readers are written and force all of them become broken? Okay, so what is the portage team proposing to use for a repo query API? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpKJpt3hG1A8.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Henrik Brix Andersen wrote: [Sun Jan 01 2006, 05:35:26PM CST] > On Sun, Jan 01, 2006 at 05:30:01AM +, Mike Frysinger wrote: > > If you have something you'd wish for us to chat about, maybe even > > vote on, let us know ! Simply reply to this e-mail for the whole > > Gentoo dev list to see. > > I would like GLEP 45 [1] - GLEP date format - to be discussed and > voted on. I doubt that GLEP 45 really needs a vote by the full council. The lead GLEP editor's decision should probably suffice for something this trivial. (Recall that the GLEP process is that the GLEP author let's the GLEP editors know when a GLEP is ready to go up for approval, and that it is generally the editors who work out precisely who needs to approve the thing.) I'll happily approve GLEP 45, with the exception that I don't know how to implement part of it. The GLEP Last-Modified string is autogenerated from CVS, so it's not in the -mm-dd format that the GLEP requires. Help? Thanks, g2boojum -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpZWN8eS1mJq.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Lance Albertson wrote: [Mon Jan 02 2006, 12:14:05PM CST] > Gentoo has been missing some kind of direction/goal for some time now. > Looking back at the last two years, what are the major > changes/accomplishments that we have done? Granted, I know there has > been great strides in improvement in some things, but I really wonder > about any ground breaking enhancements. Assuming that we can ever get GLEP 42 out the door, I think that will constitute ground-breaking. There has actually been a considerable amount of progress on the Portage front, as well, although not all of the new stuff is out yet. Similarly, the slowly-rolling website redesign is truly on the verge of being released. We also have had excellent modular X11 support for some time now, and it appears that gcc-4.x support is doing quite well, too. Oh, and we've also retired an amazing number of no-longer-active devs, so I don't know if it's actually true that we've added numbers. > I'm not sure of the exact solution. Its just been pretty frustrating > lately hearing folks complain about this and that when I know that we > could do so much better. Maybe we're just happy with being where we're > at. I know I'm not. There's a niche that Gentoo fits really well and I > think we should focus on perfecting that niche instead of trying to be > better than distroA or distroB. Okay, so you're not happy with Gentoo's direction, but what are you actively doing to change it? (Other than starting this discussion, that is?) I don't mean that question as an attack, although it may well appear that way. It's also not directed at you, since others have made similar comments. Instead, I'm suggesting that the reason that Gentoo lacks a leadership position right now is that, at least where Gentoo is concerned, effective leadership generally means an individual who is putting in a _lot_ of hard work writing code and implementing changes. That's one of the reasons that drobbins could be effective--he had the time to extend portage, work on the website to fit his vision, and make sweeping changes to the tree. In that respect, I would argue that Gentoo's most leader-like person right now is vapier, because he's a dev who actively enacts wide-ranging changes. Similarly, flameeyes, ciaranm, and the portage team all deserve credit for having a significant impact on where Gentoo has been going recently. (Yes, I also realize that people may not agree with some of what those devs have been doing, but they have been out there getting their hands dirty, and it makes a huge difference.) *Shrug* My feeling is that Gentoo is not advancing all that quickly right now, but that it's being maintained fairly well. More importantly, we still ensure that people _can_ make sweeping changes, if they want to put in the work to do so. I'm actually fairly confident about Gentoo having a decent future. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpWkukfBJf42.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Lance Albertson wrote: [Tue Jan 03 2006, 02:09:43PM CST] > Sure, we've made lots of great improvements, but I'm concerned that we > have too many subprojects all working in their little world and no one > really looking over the whole project making sure things flow together > well. There's no one out there who's responsibility is to track all > these subprojects and make sure things are flowing right. That's quite true. Of course, I would argue that it's true because nobody has volunteered to do that job. Of course, there'd be no real authority with that sort of position, since if devs don't want to work on a project they probably will not do so, so all that could really be done would be to have a group of people tracking the various projects and encouraging or cajoling progress. That said, having either an informal or formal group in that role could still be quite useful. > Sigh, I get the impression that you think I wrote this email just to > start another long drawn out debate. No, I actually think you wrote this e-mail to voice your concerns, and that your motives are pure. *Shrug* > I have no worries about people actually getting things done. What I'm > concerned about is that there's no true direction of where things will > go. Everyone has their own way of doing something, without any kind of > proper overall plan. I know the GLEP system is designed to help with > that (which is it). I'm looking at more of overall direction in Gentoo, > not specific things. We all have different opinions on how things should > be done and nothing ever seems to be totally decided on. Sure we have > the council, but I really haven't seen any direction from them on where > Gentoo should go. We have debates on the mailing lists that seem to > never go anywhere. Is everything that's debated on there needing to go > through a GLEP, or how do such things get decided with a final say? I agree with many of these statements, but I disagree to what extent there's an actual problem here. Yes, there is little real "direction" to Gentoo. I think that's a reality of having a mid-life volunteer distribution. Our devs choose the parts of the distro that are fun for them to work on, and consequently it is difficult to motivate people to work towards any particular plan if that plan involves "not-fun" things. As such, the best way to get something decided with a final say is to provide not just an idea, but a working implementation. Then it's easy, since either the implementation is good enough, or it is not. That sets the bar rather high, though, so the second best method is to have a strong advocate who's willing to keep slogging away at an idea. > I dunno, I just get the impression that people fear having a goal to > work on and would rather just let things work out in a random way (like > they have been for a while now). I'm not wanting to take the fun out of > this, but I feel more structure and less redtape would help make us move > forward faster and better. I really don't believe that fear of goals is much of a problem. I think the problem, instead, is a lack of sufficiently exciting goals, and a concomitant lack of people sufficiently motivated to shepherd those goals to a successful conclusion. I think I'll stop here, since I'm not expressing my thoughts all that well. *Sigh* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpSSwFcVV2nQ.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Chris Gianelloni wrote: [Tue Jan 03 2006, 12:17:06PM CST] > I think part of the problem is that many people are forgetting exactly > what Gentoo really is. Gentoo is not a distribution of Linux. Gentoo > is not anything more than a loosely bound group of developers all doing > their own thing in a collaborative and collective manner. You cannot > use corporate thinking to manage such a beast. We don't have mission > statements. We don't have road maps. We don't have quarterly earnings > and market projections. We simply exist. The only way we can give > Gentoo a direction is by restricting what we, as developers, are allowed > to do. The only real restrictions we have right now are "be civil" and > "don't break stuff". Anything beyond that is inhibiting one of our > greatest strengths, our individuality and individual ideas. [remainder snipped] Well, that was said much better than I managed. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpmJcDuGxEXn.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
Lance Albertson wrote: [Fri Jan 06 2006, 09:27:23AM CST] > As seen from the discussion earlier this week, I don't think Gentoo has > the proper open-mindness to create a proper enterprise distro. There are > too many things that would get in the way of Gentoo proper to make it > work right. I agree with Duncan that the best route is an outside > project so that they don't have the constraints of Gentoo proper. Trying > to inflict the ideals of an enterprise distro into Gentoo right now will > be an uphill battle the whole way. Just look at all the comments made > from my thread earlier. You cannot make an enterprise distro without > focus or direction and a leader. You'll be stuck in committee decisions > all the time. I understand that you are naturally disheartened that the discussion you started did not end as you would have liked. Fair enough, but I think you should also take another look at that body of responses. Many were, indeed, sulky "I don't wanna leader" comments, but there were also a number of well-written, cogently-argued replies both in favor of and opposed to what you wrote. All in all, I would say that the discussion you started was a net "win" for Gentoo. (Of course, I also happen to disagree with your premise, so I'm biased, but I hope that I'm open-minded enough that I would feel the same if the results had gone the other way.) Indeed, I suggest that this reasonably well-behaved discussion indicates that the Gentoo community is rather open-minded itself. Addressing your point about Enterprise Gentoo, I think you're probably right about it needing focus, direction, and a leader, but that's quite different from needing Gentoo as a whole to have any of those. The Gentoo *BSD work is a good example of how much can be done by a team > Not saying its impossible, but it won't be easy. Absolutely true. That said, there's relatively little resistance to the concept of Enterprise Gentoo, as far as I know. There is substantial resistance to anything that might add additional work to already-overwhelmed package maintainers, however, and I believe that the lack of an acceptable solution there is what stalled things the last time around. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpvosMa1rv23.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
Duncan wrote: [Fri Jan 06 2006, 09:15:42AM CST] > Tell me, from someone who obviously has some FBSD experience, what > advantages does Gentoo/FreeBSD have over the normal FreeBSD? Why would > someone use it who is currently using regular FreeBSD, and why are you > spending the time? There are obviously reasons, as you're a very > talented person spending quite a bit of time on the project, but equally > obviously, I'm not familiar enough with them to make a good G/FBSD > representative, at this point. Most of the things that people like about Gentoo have little to do with the underlying C library, kernel, and userland. Instead, it's portage, sane configuration files, and dependency-based start-up scripts that tend to attract people, and as such it's not surprising that people would like to have all of that on a nominally *BSD-based system (for those people who actually do care about the underlying C library, kernel, and userland). That's the practical reason. A slightly more idealistic reason is that part of the Gentoo philosophy is that packages should work as portably as possible, and we should be a member-in-good-standing of the community. The native *BSD teams have been known to patch their ports to work on their systems without sending their patches upstream. We have a single portage tree that handles packages for all archs (and OSs), and our Alt teams work hard to generate patches that are (a) applied independent of arch/os/whatever and (b) sent upstream. Consequently, work on non-Linux actually does a fair bit to improve the entire community. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpVWVEQ7uLkQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
Grant Goodyear wrote: [Fri Jan 06 2006, 10:46:55AM CST] > Addressing your point about Enterprise Gentoo, I think you're probably > right about it needing focus, direction, and a leader, but that's quite > different from needing Gentoo as a whole to have any of those. The > Gentoo *BSD work is a good example of how much can be done by a team working on stuff that the vast majority of our devs do not care about at all. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpn1Y1RdFn2P.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Diego 'Flameeyes' Pettenò wrote: [Sun Jan 08 2006, 11:59:40AM CST] > I originally thought of putting it on my devspace, but using GuideXML > there is a bit tricky, at least for me (as xsltproc seems to refuse > working on the pure xml directly). I actually prefer devspace for these sorts of docs. Every dev has their own space for that sort of thing, and they can use whatever easy-to-manage doc producing system that they want (within reason). Instead of "fixing" that problem, I think it would be better to fix the xsltproc issues you're having instead. If you'll post what's happening to your doc, perhaps one of our trusty doc folks can help you out. > So I was thinking if we had a way to put some "how to fix" guides > somewhere, on the lines of the ones written by soalr and vapier for > hardened. A part the --as-needed thing, it might also be useful to put > something about "how to solve parallel make issues" and similar things > that are tricky but usually just requires little knowledge of tricks. Again, I like devspace for these things. Of course, particularly useful docs would likely be adopted by the GDP (with the permission of the author, of course). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgppVuia9qUyz.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Lance Albertson wrote: [Tue Jan 10 2006, 12:00:03AM CST] > What if instead of having proj/en we did herd/en on www? Of course, that > doesn't help the whole "GuideXML is hard" bit. I like the idea of using > RST, but it doesn't seem very scalable at this time. Maybe, instead of > that, we created some kind of development site for herds (maybe > herds.g.o). Could be a place where herds put up status updates, specific > docs, draft docs, etc. Once things get established on that site, docs > could get moved to GDP if it were logical to do. As an aside, it's ciarnanm has already put work in on developing an RST to guidexml converter, so I wouldn't worry too much about RST not scaling. -g2boojum-. -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcrgbIuUOBZ.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Ciaran McCreesh wrote: [Fri Jan 13 2006, 08:48:21AM CST] > Very easy to screw up, especially since docutils goes to great lengths > to create output even if the input is highly weird. My own parser moans > on anything like that -- it disallows most nested structure markup -- > which means it's useless on most GLEPs unless someone goes through and > does some serious whitespace cleanups... I'm actually willing to do that, albeit not until after my brief vacation. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp7JnWOHDreI.pgp Description: PGP signature
Re: [gentoo-dev] NFP lack of progress
Brian Harring wrote: [Fri Jan 20 2006, 10:42:39AM CST] > Email's pretty simple- from where I'm sitting, there doesn't seem to > be any actual progress on trustees issues. That's a pretty good synopsis. > 1) Copyright assignment. Check the nfp archives, last comment is sep > 26th, seems to be totally dead. > http://news.gmane.org/gmane.linux.gentoo.nfp/ My understanding is that we do have a draft copyright assignment form prepared, but because any sane discussion about it involves allowing the legal types to interact with foundation members, the thought was that we needed a separate, private, opt-in list for discussion, and that was never set up, so nothing has moved on this issue. (Also, I believe that we are still waiting on hearing back from the legal folks as to what needs to be discussed on the private list, and what can be in public. After all, the document itself will need to be public eventually!) > 2) bylaws. They're proposed. About it. Last update to the bylaws > doc was 10/24/05, http://www.gentoo.org/foundation/en/bylaws.xml In principle, they need to be voted on. In reality, I'm in no hurry since we haven't been around very long to see if the proposed bylaws are really what we need. > 3) quarterly filings. We've got 2nd quarter '05 up > (04/01/05-07/30/05). Where's 3rd? 4th actually being worked upon? > I'm assuming the pages haven't been posted but the paperwork (whatever > there may be) has been handled. There actually is no paperwork (legally, that is), because our income is such that no paperwork is required. From an ethical standard, however, we of course should be posting that info. Cshields? 4) Relocating the NFP to Delaware. Dostrow is working on it, but there has been no progress to date. 5) Wildcard SSL certificate for infra (bug #117837). Kurt is pushing that through, and I assume it will pass. It's darn pricy, but it' not clear that there is really a good alternative. > Additionally, bank transfer is underway, but donnie is responsive on > it so not raising it as an issue. > 1) where we're _actually_ at on these issues. See above. > 2) who is working on what I'm supposed to be pushing people to get things done. It's been rather like pushing a rope (people are busy, real life interferes, and this stuff is amazingly boring), and all-in-all I've done a lousy job of it. During the last multiple months I've been spending most of my time trying to switch careers (which I've now done, starting tomorrow), so I also have not contributed much recently. I won't run again for the foundation, since it's now clear that IP and budget discussions bore me to tears, and I'm not doing a great job motivating people. > 3) what _exact_ issues are holding folks up. I would say that it's more an issue of nothing being sufficiently urgent to spur people to actually finish anything right now. > 4) what is being done to resolve the hold ups. Various people keep prodding the Trustees asking if anything is actually going to be done. I'm not sure that it's helping, but it certainly isn't hurting anything. > 5) What actual progress/work has been done thus far (no, don't need to > document something publically viewable like "wrote bylaws") > 6) A rough schedule of when things are going to be accomplished. Not > asking for hard figures, but if you're held up by X, I'd like to know > when you expect X to be done so we can gauge how things are going. I don't have a good answer here, since I believe that the hangups are all personal, not technical. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpfwDj4OoGQX.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
Jakub Moc wrote: [Thu Feb 16 2006, 03:32:13PM CST] > > 16.2.2006, 22:05:54, Ciaran McCreesh wrote: > > > On Thu, 16 Feb 2006 21:51:40 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > > | Unless someone picks this up, it should be package.masked and > > | removed from portage. There are tons of better and working > > | alternatives. > > > Uh, it's not a last rites unless someone actually does the masking > > pending removal. > > Uh, was this reply really needed? If my understanding is correct, then yes. A "last rites" e-mail means that somebody is taking responsibility for removing a package unless there are notable (and credible) objections. Your e-mail was different, as it merely suggested that "someone" should remove the package, but offered no assurance that somebody actually would do so. Unless you were suggesting that you were going to remove the package yourself? Does that make sense? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgptZM3WL4wlQ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Mark Loeser wrote: > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. My suspicion is that the more common problem is going to be inaccessible developers, rather than uncooperative ones. Certainly, if a maintainer cannot be contacted, then I would prefer that QA fix the problem rather than let it languish. So, yes, I do believe that QA needs the ability to go in and change any package that is broken. (It's worth noting, though, that every dev w/ tree access already has that ability, and the only real issue is the amount of pain that will be inflicted on a dev who changes packages both without permission and without skill. Very few devs will complain about somebody improving packages even without permission as long as the improvement is done well.) > * In the event that a developer still insists that a package does not > break QA standards, an appeal can be made at the next council meeting. The > package should be dealt with per QA's request until such a time that a > decision is made by the council. I'm somewhat ambivalent on this one on a couple of points, and the nxserver case (bug #123926) hits both of them. The first is that it seems to me that in a case like this one, where the package involved is a minor one that (I think) is not a dependency of any other packages, the most that QA should do is hard mask the package w/ a clear note pointing to the bug report, until some sort of resolution is achieved. Removing the package would seem to be a bit much. The second is the fact that I don't really like seeing policy bounced to the council unless absolutely necessary. Just as was seen here, a discussion on -dev might well lead to a reasonable compromise. If it doesn't, then the council can get involved. Of course, that leaves the question of who decides on the severity of a QA violation? Well, I would suggest that the QA team does, at the risk of getting publicly smacked down if they choose poorly. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
Ciaran McCreesh wrote: > My point is that that's a nasty QA bug that's relying upon input from > Stuart to be fixed. Whilst that one's still alive, I'm not going to go > around filing more similar "breaks non-interactively" bugs because the > discussion will just get repeated over and over. Huh? I just read through the bug, and it actually appears to be resolved pending Chris' testing w/ the needed USE flags added to the various profiles. I'll admit that the fix is inelegant, but I'm missing where it's waiting upon Stuart for additional info. Am I missing something? -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
Stephen P. Becker wrote: > Grant Goodyear wrote: >> Ciaran McCreesh wrote: >>> My point is that that's a nasty QA bug that's relying upon input from >>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go >>> around filing more similar "breaks non-interactively" bugs because the >>> discussion will just get repeated over and over. >> Huh? I just read through the bug, and it actually appears to be >> resolved pending Chris' testing w/ the needed USE flags added to the >> various profiles. I'll admit that the fix is inelegant, but I'm missing >> where it's waiting upon Stuart for additional info. Am I missing something? > > Yes, you are missing that the bug really isn't fixed. There are still > USE combinations which would be otherwise perfectly valid, but which > cause php to fail to emerge, thus reaking non-interactivity and forcing > people to (ab)use /etc/portage/package.use to get things working properly. Well, I did say that it was an inelegant fix In any event, I appreciate your response about php brokenness (I'll come back to this below), but does this php brokenness require additional info from Stuart to fix? Let me try breaking things down a bit to see if I can understand the various specific problems: 0. Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other very much. *Shrug* That's not really a problem, it just means that one needs hip-waders to get through all of the muck. No big deal; that's part of being a dev with a really large project. 1. A fresh Gentoo install w/ default USE flags will fail to compile dev-lang/php. That one is being "solved" by adding some additional USE flags to the default profile. The claim from the php team is that the correct fix is a version of portage with USE-based dependencies. The QA folks would prefer to see the php ebuild implement a set of sane defaults to prevent breakages, instead, if I understand correctly, which in practice would mean that the ebuild would detect whether or not deps were built with the correct USE flags, and work around any "broken" deps in the ebuild. (I must be missing something, since the latter strikes me as notably _bad_, since it would mean that two people with identical USE flags would get different outcomes depending on how their dependencies are built.) 2. There are a variety of otherwise-valid USE-flag combinations that will cause php to fail to build (or be otherwise unusable). That's hardly surprising, since dev-lang/php has ~100 USE flags, which means ~2**100 (~10**30) possible USE-flag combinations. Let's see, there are roughly pi*10**7 seconds per year, so if we could test one build of php per second it would only take considerably longer than the lifetime of the universe to test all of the possible combinations. Clearly QA of the current ebuild has to be rather illusory. Do we have a bug open about this? Are there any reasonable suggestions on how to fix it? I do realize that the problem is complicated by the fact that people really do use fairly esoteric php builds on production machines. That said, the current situation really is a nightmare! 3. There are a number of people (not just ciaranm) who consider the webapp idea to be brilliant in concept, but horribly flawed in its execution. (I'm personally fairly agnostic, although the one time that I had to create a webapp-enabled ebuild I found the process to be incredibly confusing. I just assumed that with great flexibility comes great pain.) However, I've never known precisely why people feel that way, and I can't find any bugs about it, so perhaps we could have a real debate about this issue? I don't think that bug #120088 is it. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
Renat Lumpau wrote: > On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: >> today's lesson: proactive QA is frowned upon, it's only a bug when a user >> files a report at bugs.gentoo.org > > I don't think that's the lesson. It oughtta be: we need a way to figure out > which QA issues are important and which are less so. A QA team member's > opinion > (personal attacks, whatever) should be an important input but not the final > say. At the risk of trying to get this conversation back on track, here's what has been happening: Some members of the QA team are working on a new QA tool to identify QA problems in the portage tree. As they add new tests, they run their tool on the tree, and file bugs on any packages that are found to violate that particular QA test. I think it's fair to say that these QA checks will find problems ranging from not-awful-but-annoying to could-break-your-system, but they are all bugs that ought to be fixed eventually. Now, if you're currently working on fixing a big problem and thus too busy to fix the little one, that's perfectly reasonable, but to not fix a small bug because you know there are larger bugs that aren't fixed just seems lazy. So, back to the big issue, are there any real complaints about the QA team essentially formulating QA policy? Should new QA policies instead follow the same rules as new global USE flags or eclasses--an e-mail to -dev asking for comments first? Does QA trump, or does the maintainer trump when it comes to disputes? -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glep 0042 (news) final draft
Mike Frysinger wrote: > On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: >> Unless there are any huge flaws found, I'd like this to be voted on by >> the council -- looks like it'll have to wait until April's meeting to >> fit in with the two weeks rule. > > may push council meeting back to 3rd tuesday if people wish I'd certainly like to see GLEP 42 addressed this month, if at all possible. That said, the two-weeks rule is to avoid inconveniencing the Council and unfairly springing something upon the devs without a chance to look at the details. It's certainly a good rule, but I don't think it should be considered inviolable. If there is an emergency, or the issue is sufficiently well known that the entire two weeks notice seems unnecessary, then I would think the Council could decide to make an exception. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Sending this from the right address this time -g2boojum- Grant Goodyear wrote: > Jakub Moc wrote: >> Please, until something is clarified/some consent reached, avoid changing >> the docs w/ funny stuff like "just flip a coin"... > > I don't believe the text is meant to be funny. It's meant (I think) to > suggest that if all else is equal, meaning that there is no obvious > "best choice", then just choose a flag, by whatever means, to support as > the default. Even if it is not what the user might have chosen, at > least the build will complete. Moreover, the results will then be > deterministic. > >> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32 >> >> What's the above again? QA policy? How does user benefit from flipping a >> coin wrt choosing a functionality? Sigh... :/ > > It prevents emerge from crashing out in the middle of what could be a > quite extensive build. Personally, I would rather rebuild one package > to get desired functionality _after_ the emerge completes than have to > fix the flags for that one package to be able to build everything else. > > -g2boojum- > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Jakub Moc wrote: > Erm, how exactly will you find out that you need to recompile that package > after such extensive build? You'll spend a couple of hours debugging when > your server app stops working? Yay! :P I had assumed that in such a case the ebuild would output a scary-looking ewarn that notified the user of such a problem. > Oh please, stop making up artificial policies doing no good to users just to > hack around lacking features in portage. Was I so impolite that you felt the need to be rude in turn? If so, I certainly apologize, as it was not my intention. I don't believe that I made up this policy, although it's been around as an unofficial policy for so long that I couldn't really say one way or the other. In any event, I certainly agree that fixing portage would be preferable to policies that work around portage's warts. On the other hand, until those warts get fixed it seems useful to have a set of "best practices" in the meantime. I'm arguing that sudden, difficult to predict package build breakages are a bigger sin than having a package build deterministic functionality that may be unexpected by the user. You (I think) believe the opposite. Fair enough. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: > I agree. Adopting a policy like this is a low quality solution for > servers. I've no opinion on how this affects desktops, but packages > for servers need to be precise.A policy that says "if two USE > flags deliver the same benefits, but conflict, pick one" is fine. But > saying "flip a coin" ... how on earth is that "quality"? See my previous post. > And how the heck is it going to work w/ USE-based defaults? This > creates a situation where package (b) cannot trust that a feature is > enabled in package (a), even if package (a) was built with the > required USE flags. Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* > I'll go as far as saying that right now I'm embarrased that it looks > like this is going to become a Gentoo policy in its current form. With an apology for singling you out (when yours is certainly not the only, or even the most appropriate, example), that sort of emotional response is how these threads begin to degenerate. There appears to be an implicit assumption there that your view is clearly correct, and any other is embarrassingly silly. Instead, I suggest that perhaps people on both (all?) sides of the issue are rational, intelligent people who simply differ on what happens to be the greatest evil. > You're absolutely *not* creating a better user experience. You're > brushing a problem under the carpet ... and making it the users' > problem when they wonder why the built a package with a USE flag and > the package still doesn't work as they expect. I would argue that the user tends to get unexpected results in either case, it's just a matter of whether the build crashes, or the resulting package is somewhat unexpected. Given that fact, I'm arguing that having a potentially-lengthy emerge crash out is the bigger evil. > Until Portage supports resolving conflicting USE flags when the > deptree is built, the practical thing to do is for ebuilds w/ > conflicting USE flags to bail. I, quite respectfully, disagree. -g2boojum- signature.asc Description: OpenPGP digital signature
[gentoo-dev] overlay support current proposal?
After reading through that fairly lengthy thread, I'm afraid that I can no longer tell exactly what is being proposed. Who has read access? Who has write access? Bugs are handled where, and by whom? Are we considering a fairly tightly controlled system, or a wild free-for-all? Exactly which problem are we proposing to solve here? If someone could succinctly summarize the current schools of thought, I'd be quite indebted. Thanks, g2boojum pgp7AyKI0mdf3.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Mon Apr 03 2006, 04:38:48PM CDT] > dont get me wrong, i hate documenting common sense as much as the next sane > guy, but it seems Gentoo has come to the point where this needs to be done Actually, I disagree that it "needs to be done". Once upon a time I helped plasmaroo craft parts of our etiquette guide, but at the time I assumed that it was a guide to help the clueless, not a rigid code that we would be putting in place (and under which one could be prosecuted). I think parts of the Ubuntu code are quite nice, but I still disagree that we _need_ it. > many thanks to the Ubuntu guys and to solar for doing the real work here: > http://dev.gentoo.org/~solar/xml/conduct.html Um, do we have permission from the authors? Some of the sentences seem to be word-for-word identical to the source. Incidentally, why drop the part about leaving the project in a considerate manner? > i dont see how anyone can be against this (unless you're a terrorist!), so > this is on track to be integrated as-is into the dev handbook Etiquette > section A few points: The "be collaborative" stanza echoes our social policy, so it's not clear that it's needed here. In any event, if we plan to use this document to extend or otherwise clarify our social policy, then I tend to think that does deserve some discussion. As for the bit about "disruptive behaviors" being "a security and stability threat to Gentoo", I assume that's Solar's contribution? It very much sounds like his mindset that security should be pre-eminent. It's certainly a valid point of view, but I don't happen to agree with it. I don't think that security should trump all else. (Incidentally, I still fail to see exactly how a tree dev whose tree access has been revoked differs from a non-developer Gentoo user. Anybody, dev or not, can submit bugs and ask devs to commit on his or her behalf.) In any event, I thought we had devrel to handle suspending devs, unless there was some sort of clear urgency that required infra to do so? Wasn't that the outcome of the recent discussions? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpAe8DaHp2iP.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Aron Griffis wrote: [Mon Apr 03 2006, 06:35:52PM CDT] > This should be shortened to say just what it means: Developers will > have more fun, be more productive, and create a better distribution if > we concentrate on the issues instead of resorting to personal attacks. Although I tend to agree with your comments about the quality of the writing, it's worth noting that much of this document was swiped from Ubuntu's code of conduct. > This part makes sense, I think... though I don't see the point of > codifying it except to "throw the book" at the next Paludis. Frankly > I think Ciaran did nothing wrong to restrict distribution on a project > he didn't feel was ready for public consumption. It has always seemed > to me like the overreactions were the problem. I think you're reading too much into that passage. It's from Ubuntu's code of conduct, and it is essentially stating (part of?) their social policy. > > Repeated disruptive behaviors will be viewed as a security and > > stability threat to Gentoo. > > Classic switching to the passive voice when the actor wishes to be > distanced from the action. WHO will view these behaviors as > a security and stability threat to Gentoo? Is this a statement the > existing developers are making? The foundation? Infra? Here I'll certainly agree. In fact, I agree with the rest of your statements, so I can stop here. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpbfN8lXEfcg.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Jon Portnoy wrote: [Mon Apr 03 2006, 06:52:33PM CDT] > On Mon, Apr 03, 2006 at 07:35:52PM -0400, Aron Griffis wrote: > > Clearly this sentence states that Infra has usurped the suspension > > process. It's very disappointing since Devrel has put so much work > > into a process that has been demoted to "recommendation" status. > > > > You mean the broken policy.xml everyone wants to replace? That's rather unfair. Yes, you and many others want to replace it. I think it is fair to say that many other people think it was a good, if imperfect, start. > I agree some of the wording should be altered, but I do think it's > sensible for infra to cover when devrel falls on its rear. Of course, it is possible that rational people might disagree that such an event has happened here. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpgejUmVK4dL.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Danny van Dyk wrote: [Mon Apr 03 2006, 06:40:59PM CDT] > Well, you're wrong. I'm against this conduct in its current form and I > am no terrorist. Further, i really dislike how you tried to avoid > public discussion by deeming everyone who disagrees as a terrorist. You know, to the best of my knowledge vapier is not a person who engages in underhanded tricks. My suspicion is that he was not trying to avoid discussion, but that he truly thought the proposed code of conduct would be uncontroversial. (Perhaps one should add to such a code: "Give devs the benefit of the doubt; ask what is meant instead of merely assuming that your interpretation is correct If nothing else, it helps limit escalation.") -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpU4VcV2CE77.pgp Description: PGP signature
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
Kari Hazzard wrote: [Mon Apr 03 2006, 09:16:08PM CDT] > This is Gentoo. We have a reputation of good community support to maintain > here. You're not helping that reputation by being mean to people who ask > legitimate questions. The issue that the question may have been sent to the > wrong list is irrelevant. RTFM is never the right answer to a question. Although I agree with the overall spirit of the comment, I disagree that RTFM is never the right answer. It helps if somebody points out _which_ fine manual to read, but ":help hardcopy" is a much better answer to "How do I print from within vim?" than actual detailed instructions would be. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgphq4eQMaXfj.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Mon Apr 03 2006, 04:38:48PM CDT] > i dont see how anyone can be against this (unless you're a terrorist!), so > this is on track to be integrated as-is into the dev handbook Etiquette > section Oh, one more probably useless comment: I would argue that the decision to enforce an etiquette guide that devs never really got to vote on has lead to a lot of grief in the past. Let's not repeat that, please? If we're going to enforce new doctrine it should perhaps have the imprimatur of the Council, since if people disagree then they can fire the folks who made the ultimate decision. (Of course, if there's general consensus, then that's not really necessary.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpOol9Fy0RYG.pgp Description: PGP signature
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Tue Apr 04 2006, 12:12:28AM CDT] > On Monday 03 April 2006 22:57, Grant Goodyear wrote: > > Oh, one more probably useless comment: I would argue that the decision > > to enforce an etiquette guide that devs never really got to vote on has > > lead to a lot of grief in the past. Let's not repeat that, please? If > > we're going to enforce new doctrine it should perhaps have the > > imprimatur of the Council, since if people disagree then they can fire > > the folks who made the ultimate decision. (Of course, if there's > > general consensus, then that's not really necessary.) > > the idea is that it's common sense and to need to vote on something > like this seems asinine > > if devs are uncomfortable with common courtesy and need to be told by > the council in order for this to happen, so be it > > hopefully devs will just "get it" I'm sorry, I should have been more clear. Yes, common courtesy should certainly be encouraged. I really wasn't trying to suggest otherwise. What I had intended to say was that in the past devrel has used the etiquette guide as a basis for censuring devs. The logic was sound enough: the etiquette guide is policy, some devs violate that policy, and devrel kicks their tails. The problem was that when the guide was created, it wasn't clear that it was intended as policy. Well, I didn't think of it as policy, anyway; I figured it was just a helpful guide for the clueless. The result was that when devrel started enforcing the etiquette guide, many devs complained that a policy was being enforced that was never really approved as such by the devs. Of course, the pretty thorough hashing that this current proposal is getting pretty much means that this time is much different than the last, and that I should probably just shut up now. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpBMC3bPkfkN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Improving Gentoo User Relations
Christopher O'Neill wrote: [Fri Apr 07 2006, 03:51:58AM CDT] > As a Gentoo user, one thing that I'd very much like to see is improved > communication between the dev teams and the users. At the moment it > feels pretty much like I am in the dark as regarding to how we are > progressing on certain things. Let me pick some examples: As was already mentioned, bugs.g.o is almost always the place to look. I realize that it's counterintuitive, but we use bugs to track just about everything. Of course, finding stuff in bugs can be a real pain, but it's still better than searching the mailing lists. > Ideally, what I'd like is for the various dev teams to compile a > weekly status report, which could then be compiled into the weekly > newsletter (which currently seems to be lacking much useful > information). I think you (and many others, too) may have a somewhat incorrect perception of how devs are spread across Gentoo. The phrase "dev teams" would seem to suggest that we have well-coordinated groups of people targeting all of the various areas of Gentoo. In some cases, of course, that's quite true, but in some others the "dev team" is predominantly a one-person show, and taking the time to write a weekly status report would seriously impact how much developing actually got done. On the other hand, this problem does have a solution--another level of indirection. Anybody who wishes, dev or user, could spend time tracking Gentoo development (through bugs and the mailing lists) and submit status reports to the GWN. Care to volunteer? I'd be happy to provide pointers on how to get started. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpoGkpFk6QUs.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo theming during bootup
Curtis Napier wrote: [Mon Apr 10 2006, 09:53:04AM CDT] > I'm willing to theme *.gentoo.org to match [...]. Speaking of which, what is the current status of the web redesign? Thanks, g2boojum -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpxlftH6CmLI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo theming during bootup
Curtis Napier wrote: [Mon Apr 10 2006, 11:21:14AM CDT] > The redesign as it was known up until this point is no more. There were > things the winner of the contest had to do and he failed to do them > (after almost 2 years of trying to get him too). I discussed it with > klieber a little and after much thought I have decided that the > WWW-Redesign Contest is now officially dead and abandoned. Thanks for the update. One question that your thorough response didn't answer (assuming that I didn't miss it) is if you have plans to improve the site's navigation? My understanding during the original redesign contest was that the majority of the complaints we received about our site from users was the difficulty involved in finding things. In any event, I think we need to remove the flying saucer guy. When drobbins left and turned over the Gentoo IP to us, one thing that he kept was the flying saucer guy. I believe that he was allowing us to use it while we got the redesign put together, but since that's dead it seems unfair to hold on to that flying saucer guy indefinitely. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpCd7pANS7e0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo theming during bootup
Vapier wrote: [Mon Apr 10 2006, 05:25:23PM CDT] > On Monday 10 April 2006 15:37, Grant Goodyear wrote: > > In any event, I think we need to remove the flying saucer guy. When > > drobbins left and turned over the Gentoo IP to us, one thing that he > > kept was the flying saucer guy. I believe that he was allowing us to > > use it while we got the redesign put together, but since that's dead it > > seems unfair to hold on to that flying saucer guy indefinitely. > > i'll miss him :( > > any way we can beg to keep him in the one place on the front page ? Feel free to ask him. I believe that [EMAIL PROTECTED] should still work. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpjzHBCBSaZi.pgp Description: PGP signature
[gentoo-dev] [Fwd: [gentoo-core] Council meeting log]
Whoops --- Begin Message --- I've attached a log of today's meeting. The agenda included Gentoo's participation in Google's Summer of Code and an update on portage gpg signing. In the former case, Gentoo has applied to participate, and assuming we get one of the handful of remaining slots then gerrynjr will be Gentoo's "organization admininstrator" (with userrel's help) for the project. In the latter case, council developement of a reasonable key policy has stalled, and they are soliciting GLEPs to help solve the problem. Best, g2boojum 19:00 <@g2boojum> Thank you all for being here. Today's agenda includes (1) Google's Summer of Code, (2) an update on portage gpg signing, and (3) the usual developer floor. We'll start w/ the Summer of Code. gerrynjrserver? 19:00 -!- spb [EMAIL PROTECTED]/developer/spb] has joined #gentoo-council 19:00 -!- g2boojum changed the topic of #gentoo-council to: meeting at 1900UTC (proxies swift->fox2mike vapier->josejx az->uberlord||halcy0n agriffis->g2boojum) | Topic: Google SOC 19:00 < gerrynjrserver> well, I'd like to propose that gentoo sign up to join google's summer of code 19:01 < gerrynjrserver> if done, it would fall under the fairly new userrel subproject 19:01 < gerrynjrserver> seems like it will be an excellent pr opportunity and would possibly allow us to get some fresh, energetic developers in 19:02 < gerrynjrserver> I would definitely be willing to take on a lead position for this project 19:02 -!- agriffis [EMAIL PROTECTED]/developer/agriffis] has joined #gentoo-council 19:02 -!- mode/#gentoo-council [+o agriffis] by ChanServ 19:02 <@agriffis> hey g2boojum, I made it back in time (I think) 19:02 <@Koon> g2boojum: impostor ! 19:02 <@agriffis> heh 19:02 * agriffis just walked in 19:02 * g2boojum continues to chair the meeting, but no longer votes. 19:03 < gerrynjrserver> this would entail overviewing proposed projects, maintianing a page of ideas developers have proposed, as well as keeping a list of possible mentors 19:03 <@agriffis> if you'd like, I can just duck back out :-) 19:03 < gerrynjrserver> would also ensure student summer of coders get thier review mid way 19:03 < gerrynjrserver> process shoould go this way 19:03 < gerrynjrserver> -students should be familiar with gentoo 19:03 <@Koon> gerrynjrserver: is there a point in catacting Google before we get a final list of projects ? 19:03 <@Koon> contacting 19:04 < gerrynjrserver> yes 19:04 < gerrynjrserver> contact has actually already been made 19:04 <@g2boojum> gerrynjrserver: You're willing to be Gentoo's "organization administrator", then? (http://code.google.com/soc/mentorfaq.html#2) 19:04 < gerrynjrserver> g2boojum: indeed 19:04 <@g2boojum> agriffis: No, please do stay! 19:04 < gerrynjrserver> contact has been mde by the userrel project, as it was thought that if we wait, it would be too late 19:04 < gerrynjrserver> and considering gentoo is shooting down most applications now, it was probably a wise decision 19:05 < nattfodd> s/gentoo/google/ 19:05 < gerrynjrserver> (only 4 seats now remain, and we still do not yet know if we have been accepted) 19:05 < gerrynjrserver> but, we have not yet received a "denial" notice as most other new signups have received 19:05 < gerrynjrserver> nattfodd: thanks 8-) 19:05 <@Koon> gerrynjrserver: OK. When should the final list of projects be sent ? May 1st ? 19:06 < gerrynjrserver> yes 19:06 < gerrynjrserver> the following week students will be allowed to submit thier applications as well as ideas 19:06 < nattfodd> we also need a firm list of mentors by then 19:06 < gerrynjrserver> nattfodd: yes 19:07 <@g2boojum> Okay, any other questions from council members? 19:08 <@Koon> gerrynjrserver: Like I said, I approve that project, but a look on the list of proposed projects would be nice, even if I trust you to remove the non-worthy ones 19:08 < gerrynjrserver> Koon: of course 19:08 < gerrynjrserver> i've jsut been notified that gentoo is still on the "maybe" list 19:08 < gerrynjrserver> with two seats available 19:09 < gerrynjrserver> so.. still nto shot down 19:09 < gerrynjrserver> *not 19:09 < gerrynjrserver> (thanks christel) 19:09 <@g2boojum> Otherwise I'm going to suggest a vote on giving this an official "go-ahead". 19:09 <@Koon> gerrynjrserver: They decide based on the org and not the project if I understand correctly 19:09 < gerrynjrserver> Koon: yes 19:09 <@Koon> voting yes for the go-ahead 19:09 < gerrynjrserver> i'd also request that a mailinglist be setup for this purpsoe 19:10 < gerrynjrserver> if we are accepted 8-) 19:10 <@solar> that wont be a problem. just file an -infra bug 19:10 < gerrynjrserver> will do 19:11 <@g2boojum> Is anybody actually opposed? 19:11 <@agriffis> sounds okay to me 19:11 -!- Irssi: #gentoo-council: Total of 13 nicks [7 ops, 0 halfops, 0 voices, 6 normal] 19:11 <@JoseJX> I think it's a good idea to try to be involved. 19:11 <@Koon> and also a good trhing that someone stepped up to organize everyth
Re: [gentoo-dev] Gentoo: State of the Union
, the large number of moribund GLEPs was always an intended outcome. They represent ideas that never got any traction, and thus went nowhere. By having them publicly available we help reduce the number of "hey, what about this bad idea" posts to -dev. > __Problem: Voting__ > > Gentoo has over 200 developers. People are generally against the > voting idea, but I'm not sure why. I think voting should work like > this: if 30 developers (or someother specified number) vote yes to an > idea then that idea passes. It doesn't require everyone to vote, be > at home, be on the computer, and not be on vacation. *Shrug* I don't really have a problem w/ trying some sort of voting. At the same time, it's not clear to me that the outcome will be all that different from what we have now, with the possible exception that debate might get cut off sooner when some sort of threshold vote is reached. > What is interesting is that Source Mage Linux has already voted on a > proposal similar to mine[2]. I truly think that making some changes > in the "gentoo way" would benefit us and make gentoo a truly better > distribution. I tend to agree that our current system is suboptimal, but I'm not quite convinced that the proposed changes would actually improve things. There's a lot here, but perhaps we can streamline things a tad. What's the major problem that you're looking to solve? Is it the shortage of developers, or the lack of progress in a certain area, or the (perceived?) difficulty in getting "foo" accomplished? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpJ8lPd6LqVq.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Grant Goodyear wrote: [Fri Apr 28 2006, 01:55:01PM CDT] > It's not quite true that the Council votes on GLEPs, but that's not > really germane to your overall point. Oh, that was your point. Mea culpa. Okay, to address that point, the way that the current system works is that a GLEP is sent to the GLEP editors, and assuming that it is not obviously going to be DOA it's generally added to the website. At that point, if they haven't already, the GLEP authors initiate a discussion on -dev that is supposed to be iterative. The authors are supposed to revise their proposal to account for comments and ideas from the community. When the authors feel it is ready, they ask for the GLEP to be approved. At that point the GLEP is sent to either a project lead (if it falls under a specific project) or the Council if it crosses project boundaries for approval. I assume that the only part of the process you would really wish to change is who does the approving, and perhaps removing the initial send-it-to-the-editors step. In reality, though, the approval process is rarely the rate-limiting step. In almost all cases, a stalled or failed GLEP either never gets sent for approval, or is approved but never gets implemented. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpDLnBJpwh7K.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT] > I disagree. The developers should make *all* the decisions. Originally, Gentoo was effectively a meritocracy. It's now, in some respects, a republic. If you want a democracy, feel free to draft a new "metastructure" proposal (feel free to name it something less awkward), and drum up support to get it voted upon. > Bypass the council. The council should be there only for when we get > sued, and manage the money we make. For what it's worth, the Council does neither of those things. That's what the Gentoo Foundation is for. > Does anyone agree that having a council is too political? I strongly > believe it stifles gentoo. Do you have some specific examples of how you've seen the Council stifle Gentoo, or is it mainly just a general impression? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpjHkscJlgrf.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: [Fri Apr 28 2006, 03:35:33PM CDT] > To reiterate, changing SCMs would allow us to work better. I have > not heard of a proposed change, a date to change, etc. I strongly > urge that we get something rolling. Go for it! *Grin* More seriously, the only thing standing in the way of migrating away from CVS is actual evidence that something else will work better. If you want to do the testing, I don't think anybody is going to stand in your way. Indeed, I'm sure that if you wanted to solicit help with testing from our users, I suspect that infra could make a tarball of the repository available. Some questions that need to be answered: * Can the repo be converted while maintaining the history? * How long does a full checkout take? * How much disk space does a full checkout require? * Is there a viewcvs equivalent available? * Others that I can't think of right now? (Please feel free to add.) (As an aside, it's perfectly possible to set up git so that anybody in the appropriate group can make changes.) You seem to have an obvious preference for svn; care to to the benchmarking for that case? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpG8lLk2QGJl.pgp Description: PGP signature
Re: [gentoo-dev] ACCESS DENIED during emerge
A. Khattri wrote:
> On Fri, 28 Apr 2006, Donnie Berkholz wrote:
>
>> A. Khattri wrote:
>>> Does this sound right or is there a better (preferred?) way?
>> Try to fix --enable-conf-install to respect DESTDIR or whatever other
>> install method you're using, or look to see what flag it will take at
>> 'make install' time to use a prefix.
>
> Right now, in src_compile I have this:
>
> ./configure \
> --prefix=/usr \
> --infodir=/usr/share/info \
> --mandir=/usr/share/man \
> --localstatedir=/var \
> --enable-conf-install=no \
> --enable-mk-localstatedir=no || die "./configure failed"
>
> The last two flags tell it to not install the sample configs in /etc and
> to not create a local state directory under /var. I imagine I will have to
> do that myself in pkg_postinstall?
You should never use pkg_postinstall to bypass the "fake install" that
we stole from OpenBSD long ago. Instead, you need to install to ${D}:
http://dev.gentoo.org/~plasmaroo/devmanual//ebuild-writing/functions/src_install/
Also see man 5 ebuild; it's extremely helpful.
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] staffing needs expirations?
I just had somebody ask me about whether or not we still needed LDAP help. It's a good question, and I didn't know the answer, which is rather embarrassing since I'm the one who filed the LDAP staffing request. Since then I believe that lcars had taken LDAP over, or is otherwise assisting robbat2 (or the LDAP team, if we have one now). In any event, I doubt that I'm the only irresponsible dev who's added an entry to the staffing-needs page and forgot about it, so perhaps we need to have items expire unless explicitly renewed? Thoughts? -g2boojum- PS. Does anybody know if we do still need people to help w/ LDAP? -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpYpfv7VBNGY.pgp Description: PGP signature
Re: [gentoo-dev] Re: Heritage
Simon Stelling wrote: [Tue May 09 2006, 06:32:48AM CDT] > Is there really a story behind it that can be explained? If so, I'd be > curious too, but I doubt there's a "real" story. Larry and the UFO guy > just came up at some time, people got used to them and even liked them. Actually, they aren't contemporaries at all. We've had "Znurt", the UFO guy, since the beginning. (http://web.archive.org/web/20001018091553/http://www.gentoo.org/) I'm pretty sure that drobbins created him, but I don't know anything else about him. As for Larry, my (possibly incorrect) recollection is that drobbins swiped the image from an open-source font for that infamous poster. I've no idea where the name came from, but after a discussion about Larry's gender we had an e-mail from an author of a comic who had "Larry the cow" as a character (quite unknown to drobbins) who was amused at the coincidence. (That author also gave us permission to continue using the name, if it were to turn out that we needed it.) I don't seem to have that e-mail archived, so if anybody else does, please let me know. > Trying to explain why we have a cow's face on a 404 page or trying to > explain why we like Larry is like trying to explain a love story: You > just can't without everybody looking strange at you afterwards. True! -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpf0G1RUMNPR.pgp Description: PGP signature
Re: [gentoo-dev] Heritage
Curtis Napier wrote: [Tue May 09 2006, 09:49:27PM CDT] > Larry our wonderful mascot is from a font collection that we DO NOT OWN > THE COPYRIGHT TOO. Our esteemed ex-architect STOLE Larry. Legally > speaking we have no rights to use Larry whatsoever and if the owner of > the copyright ever stumbles onto gentoo.org and sees it we are looking > at a big fat lawsuit. Both Jon and I (separately) addressed this earlier, but I'm pretty sure that although we don't own the copyright to Larry, the font it is from has a license that allows us to use it freely. If you have evidence to the contrary, please let me know, and I'll see what I can do to obtain any necessary rights. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpNDUDbMRug5.pgp Description: PGP signature
Re: [gentoo-dev] Heritage
Chris Gianelloni wrote: [Wed May 10 2006, 08:32:01AM CDT] > I have a copy of the font. > > It is ©2000 Ethan Dunham ‐ Fonthead Design ‐ http://www.fonthead.com Thanks! Okay, it's part of their freeware font "font heads". -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpeiydF2pMVP.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Christian Hartmann wrote: [Tue May 16 2006, 12:10:18PM CDT] > Oh lovely. - If noone has any strong reasonable objections, I'd like > to add a $ians-playground profile to the tree. Furthermore I will > start to keywording ebuilds with the new ~fridge keyword I just > invented. Hyperbole? > How is paludis related to gentoo? Hardened and the other things you > mentioned are gentoo projects. - Paludis is not. That's not really a fair statement. Porthole and various other tools began (and in some cases remain) as non-Gentoo-owned projects, but numerous portage changes have been made over the years to support those tools better. Paludis and pkgcore are related to gentoo because they are both designed to work with Gentoo's portage tree. > It's not about the size or the number of files. We have got enough - let's > call it $stuff - in the tree. I'd really like to see valid and reasonable > things added to the tree. - Adding things just because someone thinks it > would be funny to add it to the tree can't be the way gentoo wants to go. It appears, at least from what I've read, that the additions to the tree would be both minimal and narrowly focused. Why would that not be valid or reasonable? Also, I don't believe that anybody is attempting to be "funny", but instead to provide a potentially useful set of tools that need a lot of hammering on. > > Comments? Wouldn't a paludis profile lead to an explosion of children profiles that depend on it, or is the profile "mixed-in" with a standard profile? In either case, might it be easier to have a /usr/portage/paludis directory for paludis-specific content? (The opposite, but equally ignorant, question that I had was if it wouldn't be simpler to add the paludis-specific stuff to the existing files, and have portage ignore it.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpAQhR879eWT.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh wrote: [Tue May 16 2006, 01:07:05PM CDT] > | Bluntly, you break compatibility with vdb/tree, paludis has no real > | future with gentoo beyond forking- requiring 100,000 users to > | reinstall because you don't want to do backwards compatibility is > | daft. > > A reinstall isn't needed at all. Just to clarify my own poor understanding, if somebody builds a box using paludis and then decides that she'd really prefer to use portage instead, isn't that going to require a reinstall (at least until there's a program that takes a paludis installed-package database and can generate the equivalent portage db)? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpCeUn97oRES.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
Henrik Brix Andersen wrote: [Wed May 17 2006, 04:57:59PM CDT] > Hear, hear. It should be clear to everybody by now that the thread in > question is not going to lead to a solution. Actually, I tend to disagree with that sentiment. Sure, it's quite a long thread, but it's also covered a great deal: (a) what are the advantages and disadvantages of such a profile, (b) what such a profile would look like, (c) should an alternative package manager influence the tree before it becomes stable, (d) would bug reports for such an unstable package manager be unduly burdensome, (e) what are the invariants for an alternative package manager, (f) what would be required for an alternative package manager to become a replacement package manager, (g) is it reasonable to have an alternative, potentially replacement, package manager that is not Gentoo-owned, and I'm sure there are others. More importantly, there seem to have been reasonable answers to many of those questions. Also, it seems to me that this thread was moving towards a consensus that most people would like to see paludis mature a bit more before a profile is added, but that if there were clear evidence that paludis wasn't doing any of those things described on the paludis website then many people would, indeed, support a paludis profile in the future. (As an aside, I don't happen to agree with that presumed consensus, as I always thought that keeping the *BSD stuff in an overlay made the barrier to entry too high, and I'd hate to see that mistake repeated.) In any event, there's a common knee-jerk reaction that any lengthy thread is, by definition, a "flamewar". Despite the occasionally heated rhetoric, I've seen a lot of valuable content in that thread, and that sort of discussion is certainly not something that I would want to discourage! -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpNAVhQZhJFm.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh wrote: > | 4) Will Paludis ever become a Gentoo Project? > > Pretty unlikely, past events considered. Personally I kind of like > having commit access to my own code... I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev committers? I'm pretty sure that was one of the main goals behind stuart's overlay.gentoo.org proposal. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
Paul de Vrieze wrote: >> At present I ask not for support, but for a minor addition for >> convenience purposes. > > One that has more disadvantages than advantages as already pointed out. Many of your comments have been quite valuable, but I've noticed that your recent posts fail to distinguish between facts and your opinion. This last statement falls into that latter category, of course, since the relative weighting of advantages and disadvantages has been pretty subjective so far. Incidentally, in reading this thread it seems to me that a tendency to offer opinions (or predictions) as though they were facts has been a common theme. Please try to separate the two, whenever possible. Thanks, g2boojum signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
Grant Goodyear wrote: > Incidentally, in reading this thread it seems to me that a tendency to > offer opinions (or predictions) as though they were facts has been a > common theme. Please try to separate the two, whenever possible. Just to clarify, I was not limiting that comment to pauldv. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
Carsten Lohrke wrote: > Stop making such odd and wrong comparisons. The package manager is part of > what defines a distribution, choosing a shell is the users choice. If you > want to make the package manager matter of choice, start your own > distribution. Just because it has historically been the case that a package manager often defines a distribution, that hardly means that it must do so. (Incidentally, I think that apt-with-rpm probably broke that perception long ago.) In any event, the ultimate issue, as far as I can tell, is whether or not it makes sense to have a package manager that would need to be chosen at the point of installation, but that would use the existing tree of ebuilds just as portage does. Would that be a Gentoo system? Personally, I don't see why it wouldn't, as it doesn't seem that different from deciding at install time to choose a BSD kernel and userland. Some modifications are required to use the system successfully compared to a default Gentoo Linux installation, but the overall philosophy remains the same. Now, would it be vastly more convenient if one could switch between portage and a portage alternative with no more hassle than running some sort of "conversion" scripts? Of course, and I suspect that somebody would write such scripts even if the lead devs didn't do it themselves, but I'm not sure that the bar for acceptance needs to be that high. -g2boojum- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!
Ciaran McCreesh wrote: [Thu May 18 2006, 04:01:42PM CDT] > On Thu, 18 May 2006 16:41:09 -0400 Peter <[EMAIL PROTECTED]> wrote: > | However, continuing the thread serves no useful purpose except, IMHO, > | to completely obfuscate the original point of the thread > > Nonsense. There is still productive discussion going on in that thread. > The only reason it is so noisy is because a small group of malcontents > who hold grudges against some of the Paludis developers. That's not entirely fair. In the case of both pauldv and wolf31o2, I suspect that holding grudges was not the reason for the heightened tempers. Instead, it looked to me like both devs had very strong opinions on what an alternative package manager should do, and neither was happy with the fact that paludis would work differently. Consequently, they both attacked paludis quite strongly, asserting their opinions as "obvious" facts, and received strongly-worded, not entirely helpful counterarguments in return. A larger dose of patience, or perhaps a few controlled substances, would have dramatically lowered the heat. Despite all that, there's been a lot of useful content in this thread. > | While I am completely against any form of censorship, I certainly > | wish I had the ability to block that thread and all further postings > | to it. > > Then learn how to use your mail client. I wouldn't have stated it that way, but a threaded mail client does work wonders for this sort of thing. Both mutt and thunderbird, for example, allow one to fold, delete, or otherwise just ignore a thread quite nicely. > And hey, look, by starting yet another thread you're just making noise > in an attempt to justify a personal grudge, thus making things harder > for the people who do real work around here. If you don't have anything > useful to contribute, shut up and go away. *Sigh* Be nice, please. Incidentally, he did have a point that this thread is now darn hard to follow. Perhaps it's time to split off a thread or two...? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgprUHyLJIiJN.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 49 - take 2
Jon Portnoy wrote: [Mon May 22 2006, 09:38:23AM CDT] > On Mon, May 22, 2006 at 09:21:34AM -0400, Ned Ludd wrote: > > Please don't change your wording on that. The feel really strongly > > about the primary pkg manager of Gentoo needing remain under the full > > control of Gentoo Linux. > > > > Agreed, I'm of the opinion it would be inappropriate to let an outside > entity steer our primary package manager. I'm not sure I understand why. After all, mandriva, suse, ubuntu, and many others have survived quite well. More to the point, though, it's not clear to me what awful things happen if Gentoo does not own the package manager code, as long as that code is under a reasonable license. Suppose that such a package manager did became a Gentoo default, and at some point the program diverged from what Gentoo really wanted; wouldn't Gentoo then just fork the package manager? Am I missing something obvious? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpRDW94TT7bg.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 49 - take 2
Paul de Vrieze wrote: [Mon May 22 2006, 06:29:19AM CDT] > I have put a new revision of the alternative package manager requirements > GLEP on line. The html version can be found at: > http://www.gentoo.org/proj/en/glep/glep-0049.html It seems to me that the main concerns addressed in that GLEP are (a) that an alternative package manager should not lead to ebuilds that are incompatible with the official package manager, and (b) that no package manager should be the official package manager unless it can provide the services provided by the official package manager (with "generating release media" being on obvious example). Perhaps something like the following would suffice: GLEP: xx Title: Supporting alternative package managers Version: $Revision: 1.3 $ Last-Modified: $Date: 2005/11/13 17:16:50 $ Author: Grant Goodyear <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2006 Abstract To support alternatives to the official package manager (portage, at the time of this writing), some sane ground rules need to be set. Specifically, no alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. Moreover, no ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Specification = * No alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. If an alternative package manager is runtime incompatible with the official package manager, then it must be masked and provide appropriate warnings. * No ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Rationale = The first rule sets a reasonable bar for adding an alternative package manager to the tree. Note that if an ebuild currently in the tree doesn't work with the official package manager, it isn't expected to work with an alternative package manager either. The second rule ensures that an alternative package manager cannot become a de-facto requirement by supporting packages that the official package manager cannot handle. In order to keep this proposal as simple and focused as possible, it has nothing to say about the process by which an alternative package manager might one day become the official package manager. It is assumed that sanity will reign, and no package manager will become official without being able to build installation media, providing a transition path from or to the existing official package manager, etcetera. Backwards Compatibility === Pretty much the whole point, and it's explicit here. Copyright = This document has been placed in the public domain. -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpESBeb1Shvr.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Devmanual
Mark Loeser wrote: > At long last the devmanual is official. You can find it at > http://devmanual.gentoo.org. I would like to thank plasmaroo for helping > me with converting it to XML (since he did all of the XSL work to add in > the features we needed to make it easy to write and expand upon). How was the conversion done? Do we now have a tool to convert rst to guidexml, or was the conversion all done by hand (which would be a truly frightening thought), or something else entirely? -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: Gentoo Devmanual
Peter wrote: [Thu May 25 2006, 07:00:16AM CDT] > On Thu, 25 May 2006 12:34:13 +0100, Stephen Bennett wrote: > > snip... > > "at a minimum such credit will appear where any other comparable > > authorship credit appears and in a manner at least as prominent as such > > other comparable authorship credit." > > > > Two names are credited on the front page. One is conspicuously absent, > > despite having done the vast majority of the original work. > > > The two names listed are as editors. Plainly, clearly. Ciaranm is clearly > listed alone as a main contributor and author. His name is more > conspicuous than any other. Not to mention on the contributors page where > is name is..first? I could be wrong, but I believe your statement misses the point that ciaranm actually raised. The passage he quoted seems to be fairly clear: "...at a minimum, such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit." I would read that passage as suggesting that the document cannot have a section titled "Authors" on the first page that lists only the current editors and also a "contributors" page in an appendix that lists all of the original authors. Incidentally, there seems to be an implicit assumption that ciaranm posted his message because he felt that he had not been properly credited. His actual e-mail was polite, gracious, and to the point, which was that the CC-SA license was probably violated. Nowhere was there any whining about not getting the appropriate credit. (On the other hand, I don't mind doing so. I was certainly a tad taken aback to discover that my name was not listed in the section titled "Authors".) Finally, the whole issue goes away by either changing the heading on that first page from "Authors" to "Maintainers" or "Editors", or by adding the list of contributors back to this page. It's not exactly rocket science, folks. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgphCs5kqJIZd.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Devmanual
Mark Loeser wrote: [Thu May 25 2006, 12:39:56PM CDT] > I changed "Authors" to be "Editors". I hope that will kill some of the > controversy. Thanks. That should certainly satisfy the license, and I, at least, appreciate it. > Ciaran, we recognized you on the front page and appreciate everything > you did. We cut the author list from the front page because it was > getting incredibly long and we didn't feel it should take up that much > room. The only reason Tim and myself are listed there is because we are > the ones maintaining it now, and want people to be able to easily find > who they should contact about changes. For what it's worth, I never suspected otherwise. (Nor, I suspect, did ciaranm, although I haven't asked him.) Despite the lack of any intentional malice, however, I do happen to believe that removing the author list from the front page is a serious error that is worth fixing. Giving people appropriate credit for writing documentation is just the right thing to do, and that credit shouldn't be buried somewhere. Indeed, my recollection was that a fair amount of thought went into where the author list should go when drobbins created our documentation XSL. That said, I would certainly agree that a long list of authors, with one author per line, down the center of the page would, indeed, not look so good. A simple set of names (with links to the contributors page which provides additional detail, perhaps) would suffice, I'd think: Authors --- Ciaran McCreesh, Grant Goodyear, Aaron Walker, Robert Coie, Tom Martin, Paul Varner, Ilya Volynets-Evenbakh, Diego Patteno Fernando J. Pareda, Simon Stelling, Alin Dobre, and Joseph Jezak Seem reasonable? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpnsnhtBOAF8.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Devmanual
Mark Loeser wrote: [Wed May 24 2006, 04:37:44PM CDT] > Grant Goodyear <[EMAIL PROTECTED]> said: > > How was the conversion done? Do we now have a tool to convert rst to > > guidexml, or was the conversion all done by hand (which would be a truly > > frightening thought), or something else entirely? > > Be prepared to be frightened then, because it was all done by hand :) I'm certainly not complaining; I'm quite grateful that this document is being maintained! I am curious, though. I thought that neysx had made all of the desired modifications to guide-xml so that the dev guide could be translated to standard guide-xml. Is something still missing? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpvfz7sZ6efE.pgp Description: PGP signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Mark Loeser wrote: > Basically, it would be something that allowed you to "browse" the current > tree of submitted ebuilds. This way users that submit something can > categorize it for devs to easily look for ebuilds they may be interested > in, and we can make it so we could easily grab the ebuilds from this hacked > up idea of a tree. It would make it a lot easier to do automated checks > against submitted ebuilds for QA issues, and we would offload all of those > submissions from bugs.g.o to this app. I guess you could think of it as > the overlays.g.o idea, but I tend to think overlays are experimental > things that aren't necessarily going to be added to the tree. This > would be for ebuilds/packages that are ready to be added to the tree, > but just lack someone that wants to maintain them. A big advantage of the current system is that people tend to add bug reports to those maintainer-wanted ebuild bugs, so the community can actually iterate through ebuilds for a non-tree package without too much pain. Separating the pending ebuilds from bugs would make that harder. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Paul de Vrieze wrote: [Thu Jun 01 2006, 02:44:39PM CDT] > I would like the council to discuss GLEP 49 as has been discussed on > the list some weeks ago. It is about the package manager requirements. Incidentally, I drafted a competing GLEP that I posted to -dev (<[EMAIL PROTECTED]>) that was either overlooked in the rest of that thread or ignored because people considered it to be useless; I'm not sure which. In any event, I just want to bring it to the council's attention as an alternative approach. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 GLEP: xx Title: Supporting alternative package managers Version: $Revision: 1.3 $ Last-Modified: $Date: 2005/11/13 17:16:50 $ Author: Grant Goodyear <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2006 Abstract To support alternatives to the official package manager (portage, at the time of this writing), some sane ground rules need to be set. Specifically, no alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. Moreover, no ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Specification = * No alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. If an alternative package manager is runtime incompatible with the official package manager, then it must be masked and provide appropriate warnings. * No ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Rationale = The first rule sets a reasonable bar for adding an alternative package manager to the tree. Note that if an ebuild currently in the tree doesn't work with the official package manager, it isn't expected to work with an alternative package manager either. The second rule ensures that an alternative package manager cannot become a de-facto requirement by supporting packages that the official package manager cannot handle. In order to keep this proposal as simple and focused as possible, it has nothing to say about the process by which an alternative package manager might one day become the official package manager. It is assumed that sanity will reign, and no package manager will become official without being able to build installation media, providing a transition path from or to the existing official package manager, etcetera. Backwards Compatibility === Pretty much the whole point, and it's explicit here. Copyright = This document has been placed in the public domain. pgpZbopQvTPXT.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Stefan Schweizer wrote: [Mon Jun 05 2006, 11:03:57AM CDT] > -fortran - Do we really need this outdated language as a default in gcc? Although outdated, there are still a lot of applications that use it. More importantly, there are a lot of well-tested numerical libraries that exist in fortran that really aren't worth porting to another language, so a lot of stuff in our tree still requires a fortran compiler. (I don't have good statistics on exactly how much of the tree does, however, so if somebody wants to compile some) Until use-based dependencies arrive, I think it's still required. > -motif - is unmaintained in portage and rather outdated, does not look good. > Should not be default for optional interfaces I believe that flag is mainly there to reduce the "Hey, my xpdf package lacks the xpdf binary" bugs. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpvktp4GzQDp.pgp Description: PGP signature
[gentoo-dev] evolution of x86 stabling procedures
I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcIG0ZQQWuA.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
Mark Loeser wrote: [Mon Jun 05 2006, 03:25:02PM CDT] > Well, since you decided to bring this up on here, I guess we'll just try > to address everything. Where else would I have brought this up? Paraphrasing, I noted that the x86 team is now doing peer review, I asked if other arch teams are doing the same thing, and I asked how the new system is working, and whether or not the old fears that peer review would slow things down too much seemed to be valid. If that isn't a question for the Gentoo development list, I don't know what is. Nowhere did I say anything evenly remotely negative about what the x86 team is doing, as far as I can tell. If I did, then I sincerely apologize, as it was definitely not my intention. > Peer review should be part of any stablization process. The glep that > *you* wrote even provides for it: > > For a package to move to stable, the following guidelines must be met: > ... > * The relevant arch team must agree to it. Heh. That'll teach me! > Maybe it was not what you intended, but we have not been slowing down > any process as far as I'm aware, since we get to our bugs as quickly as > we possibly can. And every arch team has their own keywording policy. > I don't see why x86 can not have the poilcy that we decided on. If you > have MIPS hardware and you mark something ~mips, I'm pretty sure they > will be pissed if they didn't give you prior permission. Probably the > same for a few archs. I didn't say that the x86 policy was a bad one. I was rather hoping that x86 was doing peer review and at least one other arch team wasn't, since then we could try to make some sort of quantitative comparison. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpVRXLsKvjd5.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] > Mike Frysinger wrote: > > this is a *huge* con ... developers are lazy, *i'm* lazy ... i > > certainly do not want to go through every single package i maintain > > and add 'debug-build' to IUSE or 'inherit some-new-eclass' > > Sometimes it takes a little extra work to do things right, but > hopefully it will pay off in the long run. A poor design decision > made now can haunt us for years to come. A "little extra work"? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That rationale seems especially true in this case, where nostrip and debugging flags will do no harm for packages that aren't C or C++. > > if the large majority of packages are going to be taking advantage of a > > feature, isnt the logical thing to opt everyone in rather than forcing the > > majority to opt themselves in ? > > It really depends on the pros/cons applying something on a *global* > scale, like you propose. A package manager (such as portage) will > never be able to make debug-build decisions that work well for *every* > ebuild. That's why it's better for ebuilds to make those decisions > themselves (with the help of eclasses). I would think that your argument would depend on the probability of a package being an exception to the general rule. How many packages actually fail to do what is expected when compiled with -g and nostrip (noting that those cases without binaries to strip don't count)? Unless that percentage is significant, then I would think that a simple solution that handles the common case is a very good thing. Wouldn't the "simple" solution be to have package.* files that allow the user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, I do realize that it's the lack of such files that lead vapier to propose his solution, which is rather more convenient for one-off builds.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp5cgkviFCsQ.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] > Initially jokey and myself will be working on this. The current focus is to > migrate ebuilds from bugzilla into the overlay and to get contributors to > commit their changes to the overlay instead of updating the bugzilla every > time. I'm not opposed to what would essentially be an overlay of maintainier-wanted ebuilds, but I would actually prefer to see that happen by pulling from the bugzilla database instead of trying to replace bugzilla altogether. My reasoning is that bugzilla provides a place for community development of an ebuild (including commentary!), which would not be true of just the overlay. If one were instead to add a magical bugs whiteboard status or keyword that let a script know that there's an ebuild to pull from bugzilla that should be added to the there-be-dragons-here overlay, I'd think that would make life much simpler for everybody. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcquPFfyhuM.pgp Description: PGP signature
[gentoo-dev] herds.xml
So, what would people think of moving herds.xml from gentoo/misc into the portage tree, with the rationale being that local tools could use that information for various useful purposes (compiling statistics, doing something that I can't think of right now, whatever)? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpfhsskhp9M2.pgp Description: PGP signature
[gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Over the years we've had a fairly consistent stream of suggestions that we should open up the e-build maintaining process to users instead of just devs. The main arguments against it are the security issues and an expectation that it would add to developer workloads. The former is certainly a real problem, although signing (assuming a reasonable web-of-trust) could mitigate that some (at least we'd know who to blame). The latter, however, is conjecture, and the only good way to verify it would be to actually try it and see what happens. Oh, and there's also a very real fear that if things go horribly wrong, that Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I tend to think that if we were to advertise project sunrise as experimental, temporary, use-at-your-own-risk, and might-break-your-system, and even put it on hardware without a gentoo.org address and add a portage hook that warns whenever the project sunrise overlay is used, then our reputation isn't really likely to suffer even if it's a complete disaster. So, Chris, what have I failed to address that would make this a really bad idea? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpYv7ECVebb2.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:30:27PM CDT] > On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote: > > I did. Sources don't affect anything. The ck-sources are in the tree, and > > there is dire warning associated with them. Only the -mm sources have any > > sort of warning. If a user CHOOSES to use a hacked up kernel, then they > > obviously choose to. Just like, if a user chooses to try out reiserfs-4, > > they get what they pay for. Sources don't affect anything. > > I rest my case. Care to elaborate? The wise, all-knowing Zen argument isn't particularly helpful -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpa5qAbFbRMh.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:52:18PM CDT] > All software runs on top of the core of the operating system, the > kernel. If the kernel is buggy it will be reflected in all the > software running on top of it, be it portage, compilers, daemons or > graphical user environments. Oh, I'm sorry, I thought you were referring to the kernel in terms of ebuild dependencies. Isn't your reason why "emerge --info" lists the kernel? (Also, the kernel probably isn't the best example, since I suspect that if there's any single package that people are likely to install outside of portage, the kernel would be it.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpong75Uwgt9.pgp Description: PGP signature
Re: [gentoo-dev] nss_* and system users
Mike Kelly wrote: [Thu Jun 15 2006, 08:36:25PM CDT] > As part of my original plans for my GLEP27 implementation, I was > going to have my scripts automatically add the users requested by a > package (for example, the cron user), to all the passwd backends > listsed in /etc/nsswitch.conf. However, in consultation with some > folks, it seems that what may be more desirable is to just add > users/groups to the local files/compat backends instead, and not make > any changes to the remote databases. > > Does anyone have any strong notion of any cases where it would be > excessively bad for the package manager to try adding to, say, the > nss_nis backend in addition to the nss_files backend, or cases where > that would be a strongly desired behavior? I think it's unlikely that one would want to add an account to both files and nis/ldap, but there's no good reason that I can think of not to let the user choose. That said, I'm not exactly an uber-sysadmin. One thing that I might think would be common, though, would be to have system accounts pre-defined in ldap/nis, with the expectation that your scripts would look up the remote values and then create local accounts with those values. Anybody who actually has a clue want to chime in? Oh, it might be a good idea to ask in [EMAIL PROTECTED], too. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpysqpuKYc6M.pgp Description: PGP signature
