Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
Marius Mauch wrote: If not, i *personally* could go slowly removing the entries, along with other people willing to help, or any other _better_ suggestion to deal with this? Don't do this without explicitly checking with the maintainer for a package (if existant). Generally redundant entries in package.mask don't hurt, so if it's not absolutely clear that the entry is not needed anymore keep it. Thanks for everyone's suggestions. I am gonna tweak even more the script. I only don't see any reason to keep non-existent entries there. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wednesday 23 November 2005 05:01, Andrew Muraco wrote: (I've read all of the comments up until now, but my response is not directed at any particular post.) Facts: (according to me, and what I've read) -The releng team DID make a good decision by making stage 3 default in the instructions. -The releng team _DID_NOT_ do a sufficient job of making the community aware of the changes BEFORE they occurred (I didn't know about this change until after it was done, and Gentoo.org is my home page, I read the GWN) -Stage 1 2 tar balls and instructions ARE available OPINION: - This change should be GLEP'd, as it effects everyone that installs Gentoo (to some degree, most do not suffer tho) - Stage 1 SHOULD continue to be released and maintained, instructions clearly stating risks and LACK of SUPPORT and easily visibility from the install docs (which it seems it does not have (according to posts), although, It is perfectly clear to me.) This whole issue has been discussed on [EMAIL PROTECTED] before. While not quite as noisy as dev, everyone had their say. It is clear to me that the decision is right the way it was made. A GLEP wasn't necessary as it was discussed and approved by all involved (on the releng list). Most people that complain are probably misinformed about the usefulness of stages 1 and 2. They are really only useful if you know what you're doing and don't really need the handbook that much. Those users should be able to find the alternative installation docs. I do agree however that there should be some link to the relevant documentation from the handbook. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsNPvsBu78N.pgp Description: PGP signature
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
On Wednesday 23 November 2005 05:05, Donnie Berkholz wrote: Luis F. Araujo wrote: | So, i wrote a script to try to get a list of those orphaned entries, | and it looks like there are more than 400 packages/ebuilds which are | still listed in p.m but that don't exist in the tree anymore. | (A bunch of them from the KDE herd btw) It would be really helpful if your script could retain the category. And provide sorted output. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYZ8XiW8uV2.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wednesday 23 November 2005 07:40, Curtis Napier wrote: Aarons design uses a smaller default font, that is not acceptable from an accessibility POV. The main font is at 1em and all cursory fonts multipliers of 1em. The main font will remain at 1em which is the standard for the accessibility guidelines. If you don't like the standard font size every single graphical browser offers a font zoom capability, use it. First of all, this new design looks already a lot better. Then, I can see your point about the font sizes. However, if you want to aid people with bad eyesight, wouldn't it be a better solution to follow the browser's default size. That way the page shows the prefered user size regardless of being zoomed or not. Paul ps. I also found two graphical glitches: - There is a misterious white bar just below the overview bar (see ws1.png) - The corners of the jump pads do not have the proper background color (see ws2.png) pps. Maybe have the design by Aaron Shi actually point to his homepage -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net ws1.png Description: PNG image ws2.png Description: PNG image pgpNnHIPv8ReA.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: status of http://wwwredesign.gentoo.org
On Tuesday 22 November 2005 18:45, Duncan wrote: I run Konqueror/KHTML, and obviously it isn't setting it, either. However, I do run thru privoxy, and may be able to whip up a filter to add it... I'll have to think a bit... I've not gotten into wget, much more than being aware it's often used in scripted applications including many I rely on here. Thanks for the useful hint, however -- I'll keep it filed away as it seems likely to be found to be useful at some point! Konqueror can do some archiving in the tools menu (creates a .war archive), but does not save the stuff as html + deps. Paul ps. The version of IE that did that was probably already 6, but I'm not certain. In any case it would only do it for downloads, not for view source. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpiaDUPuFXWM.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
Paul de Vrieze wrote: On Wednesday 23 November 2005 07:40, Curtis Napier wrote: ps. I also found two graphical glitches: - There is a misterious white bar just below the overview bar (see ws1.png) - The corners of the jump pads do not have the proper background color (see ws2.png) Fixed. In CVS If anyone with experience in Internet Explorer can figure out what is causing it to push the page off the left side of the window I would greatly appreciate it. I have never seen an error like that before and can't figure it out. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: new developer Joshua Nichols (nichoj)
Petteri Räty posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 00:26:57 +0200: Jochen Maes wrote: Hello all, I'd appreciate a nice welcome and a descent slap on the butt when you pass him... Joshua, welcome! http://tinyurl.com/n9qb I hope to see this list near hundred soon! OK, this is a gripe of mine, so... 1) There's only the tinyurl, no indication at all of where it actually points, or what the list is! Surely, a bit of a description might be useful. Something like (buglist of whatever). (I'm composing this having gone to the URL but still have no idea of what whatever is, because there's no title and the URL is too long to easily figure out what's being searched on.) 2) The URL actually pointed to is: http://bugs.gentoo.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=exactemail1=java%40gentoo.orgemailassigned_to2=1emailreporter2=1emailqa_contact2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=changedin=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Obviously that's waaa... too long to be of much use, so a tinyurl is appreciated. However, a lot of those query substrings are empty or the default or otherwise unneeded. Trimming the cruft should result in a far shorter URL that actually conveys a bit of information. With a URL of this lenth, the easiest way to do that is to paste the URL into an editor and trim from there. Trim a bit, then try the link to see if it still works, then trim some more... Here's what I came up with after a bit of trial and error. Note that the original URL poster, knowing what he's after and thus knowing which fields are likely to be relevant, could have done the same with rather less trouble. http://bugs.gentoo.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=exactemail1=java%40gentoo.org Still not short, so a tinyurl is still useful, but /far/ shorter than the above, and it's actually possible to see what this one is looking for: a) bugstatus=NEW/ASSIGNED/REOPENED and b) [EMAIL PROTECTED] (exact match). OK, how much easier would it have been to just post this: List of open bugs assigned to java@: http://tinyurl.com/whatever Note also that some don't like clicking on blind URLs, even with descriptions. Thus, optionally: List of open bugs assigned to java@: http://tinyurl.com/whatever (points to) http://bugs.gentoo.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=exactemail1=java%40gentoo.org That way, both those who don't want to trust a blind link, and those that are reading the list on long-url munging clients, have a link to click. Further, even if the long URL ends up munged, it's possible to see what it is, and to reassemble it, if desired. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote: If there are no more outstanding issues reported I will submit this current layout for approval. there's still a ton of wasted space in the purple bar ... if that was tightened up, more news could be displayed ... having the last two or three news items on the front page is pretty helpful imo and would help to offset all the space created by the large ad sidebar The artwork is all part of the winning design. Any issues with the infinity symbol should have been addressed a year ago. well it clearly wasnt, might as well cover it now before the site goes live ... as i pointed out, considering its location, this means that our new logo basically becomes gentoo with an infinity sign I actually implemented a search that used google much like the example that was posted here. The search was discussed at length with the project lead and it was decided that using a third party search engine such as google was unacceptable. why ? we all know google is great and the implementation would be both cheap and quite usable Gentoo is a not-for-profit but, unfortunetly, it is the wrong kind of non-profit so Google will not sponsor us. i dont see why a simple form redirect to google would require any sort of sponsorship ... the thread fork to hardware at google was weird anyways *all extraneous information and decorative news headers were removed from the front page to help readability and to bring focus to the information. This includes the cow image and text. Overwhelming amounts of information on the front page should no longer be a problem. This also brings the jumppads closer to the top so new users will be better able to spot them. seems like everything was cut ... now the frontpage is just a simple site index page ? i liked the simple cow/about blurb myself -mike -- gentoo-dev@gentoo.org mailing list
Re: Re[6]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wednesday 23 November 2005 01:55, Jakub Moc wrote: emerge -e world emerge -e world emerge depclean You've missed revdep-rebuild to fix the borkage that emerge depclean produced. ;) After double rebuilding of the complete world I would seriously doubt it that any stray dependencies were still around. If there were, it would be because of broken ebuilds. That should be reported as bugs and fixed instead of relying on revdep-rebuild. About revdep-rebuild, that is an ugly kludge that is only there to aleviate that portage does not record the metadata needed to know what should be rebuilded without having lib files searched. In 99% of the cases it is also not needed to use it, and those people advocating its use should probably put their attention into fixing portage that it records and uses information about what package was used to satisfy what dependency. (and to verify the package tree state after each install) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpo3G1wCuR0P.pgp Description: PGP signature
[gentoo-dev] Possible solution: email subdomain
Marius Mauch posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 00:26:05 +0100: On Mon, 21 Nov 2005 11:19:17 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: Why not just @at.gentoo.org Makes clear what it is. Arch testers are not staff. Not that we have any staff. Can't we just let the whole subdomain stuff die and be done with it? If not, I'd like to propose we make a vote amongst all current devs with the options: - give ATs a @g.o email - give them a subdomain - give them no mail - don't care Just to get some numbers how many people actually want this subdomain crap. I don't think there are many. There's an idea Jeroen Roovers posted (message [EMAIL PROTECTED] ) that would, AFAIK, solve the problem for infra, while still giving AT/HTs a distinctive address. Unfortunately, noone seemed to pickup on it besides me. (No other comments to the subthread, thus I'm changing the title this time around, hoping to get a bit better response.) Here's the proposal again. If there's an issue with it, shoot it down, but from here, it certainly seems to fit the bill. Again, I'd /love/ to say I was the one that came up with it, but I wasn't. =8^) * give [AH]Ts a name[EMAIL PROTECTED] address. - It's not a subdomain, so the existing infrastructure should have no problems with it. - [EMAIL PROTECTED] remains distinctive enough it should alleviate any doubts or confusion over status. - the biggest possible objection I can see is that the root, [EMAIL PROTECTED], is already in use. Thus, in particular, I'd like to see his reaction to this proposal. We could, of course, take the same idea and change the root, if necessary. My previous suggestion, intern, would work, or assistant, or something else. Tester is of course short and concise, but intern or assistant would be more generic, allowing the possiblity of other non-tester additions, in the future, with the same root. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
On Wednesday 23 November 2005 11:52, Mike Frysinger wrote: yes, i imagine there are a bunch of these false positives ... you can see the gcc-config mask is wrongly flagged for this reason And the complete KDE mask that is around 300 ebuilds... Really, don't have hurry to fix those entries before a true check is done. [as I said on #-dev, there's enough code to parse and check p.mask on my ruby-checker in gentoo-alt overlay... I actually did use it to check senseless masking with 4 lines of extra ruby code a part the already present classes, when I first noticed this problem and referred it on #-dev (before Doug opened the bug, that is)] -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppFB645Zd4Q.pgp Description: PGP signature
Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
23.11.2005, 11:25:58, Paul de Vrieze wrote: On Wednesday 23 November 2005 01:55, Jakub Moc wrote: emerge -e world emerge -e world emerge depclean You've missed revdep-rebuild to fix the borkage that emerge depclean produced. ;) After double rebuilding of the complete world I would seriously doubt it that any stray dependencies were still around. If there were, it would be because of broken ebuilds. That should be reported as bugs and fixed instead of relying on revdep-rebuild. You've probably missed the point. It's emerge depclean that's broken; again - we are lacking any reliable way to punt unneded packages. BTW, I'd still like to know how I'll get nptl(only) hardened install once stage1 is gone. i386 does not have nptl, and I've done change CHOST emerge -e system emerge -e world job a couple of times and it never went smoothly. -- jakub pgpqyAFKp9Nmd.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote: If there are no more outstanding issues reported I will submit this current layout for approval. the links in the footbars still dont have 'on mouse over' behavior like all the other links -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Update of http://wwwredesign.gentoo.org
Curtis Napier posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 01:40:45 -0500: Here is a list of items that have changed since my last post: Wow! Very good (near perfect!) and dramatically improved (beyond what I would have considered possible). Thanks for addressing directly all the issues brought up, either changing them or explaining why they couldn't be changed within current scope. The only thing left here, and I there may be no direct solution, is that at high zoom levels, the text in the purple boxes moves out of them and into the white of the main content area, where it becomes invisible. It it some way possible to have the purple boxes expand as the content within them expands? If not, that's deliberately TRYING to find fault anyway, and already better than it was in this regard. (The text stays inside the boxes better than it did.) If that's all I can find, when I'm LOOKING to find fault... =8^) This is getting very close to what I'd call the perfect page, far closer than I thought was even /possible/ on complex content, given the imposed project constraints as you outlined. It really /does/ show what's possible! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev]
unsubscribe
[gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
R Hill posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 00:16:38 -0600: this is why things need to be made clear before the fact, not after they happen, and need to be discussed with both devs and users to make sure everyone's on the same page, instead of spending all day violently misunderstanding each other. .. All day violently missunderstanding each other... LOL, but unfortunately what has seemed to be the case, both with this, the stage-1 thing, and with the mail subdomain issue regarding GLEP 41, the arch-tester thing. Certainly lessons for the future. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, 2005-11-23 at 12:06 +0100, Jakub Moc wrote: BTW, I'd still like to know how I'll get nptl(only) hardened install once stage1 is gone. i386 does not have nptl, and I've done change CHOST emerge -e system emerge -e world job a couple of times and it never went smoothly. Please calm down. Chances are for 2006.0 hardened will no longer produce a set of 2.4.x stages, by providing 1 less set of stages it frees up some of our mirror space for providing a set if i386-gentoo-linux-gnu and a set of i686-gentoo-linux-gnu set of stages. If your start from a stage1 and remove the hardened USE flags it's functionality the equivalent as starting from a vanilla set by the time you ./bootstrap.sh and then your emerge -e world would remove any remaining traces. Of course I think it's silly to remove the hardened USE flag. Please calm down. Chances are for 2006.0 hardened will no longer produce a set of 2.4.x stages, by providing 1 less set of stages it frees up some of our mirror space for providing a set if i386-gentoo-linux-gnu and a set of i686-gentoo-linux-gnu set of stages. If your start from a stage1 and remove the hardened USE flags it's functionality the equivalent as starting from a vanilla set by the time you ./bootstrap.sh and then your emerge -e world would remove any remaining traces. Of course I think it's silly to remove the hardened USE flag. You can have your cake and eat it too as long as catalyst support remains. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: new developer Joshua Nichols (nichoj)
Henrik Brix Andersen posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 11:36:11 +0100: On Wed, Nov 23, 2005 at 03:14:25AM -0700, Duncan wrote: OK, this is a gripe of mine, so... [snip unuseful rant] Political point: Calling someone's hard work unuseful without qualification is likely to cause offense. If it's so useless, after all, would someone have spent the time to post it? Therefore, it's useful to /someone/, even if that /someone/ is only the poster. IMO unuseful gets the point across, without being quite so offensive. (Who can fault someone for having an opinion and expressing it?) Do you always have this much time on your hands? Perhaps if you try cutting down on the length of your emails someone might actually read them - instead you could then spend the time on trying to understand an internal developer joke? Got the joke, but the point was, it wasn't directly apparent from the URL (with no description) what the joke was, and like many jokes, it isn't so funny once it has to be explained. Cutting down on the mail length, right, so I'll stop here. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: (unknown)
Chris posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 11:42:42 +: List-Unsubscribe: mailto:[EMAIL PROTECTED] unsubscribeunsubscribe Read the headers in every post on the list, including yours, and quoted above for your convenience. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wednesday 23 November 2005 12:06, Jakub Moc wrote: 23.11.2005, 11:25:58, Paul de Vrieze wrote: On Wednesday 23 November 2005 01:55, Jakub Moc wrote: emerge -e world emerge -e world emerge depclean You've missed revdep-rebuild to fix the borkage that emerge depclean produced. ;) After double rebuilding of the complete world I would seriously doubt it that any stray dependencies were still around. If there were, it would be because of broken ebuilds. That should be reported as bugs and fixed instead of relying on revdep-rebuild. You've probably missed the point. It's emerge depclean that's broken; again - we are lacking any reliable way to punt unneded packages. Emerge depclean is very reliable in its behaviour. That behaviour is not always what is desired though. When however all packages on the system are consistent with the present USEFLAGS and eachother, depclean does exactly what it should do. The fault is that it asumes that packages have been build with the current environment. This is generally not true (thanks to for example auto-use, missing dependencies, and configure script automagic). BTW, I'd still like to know how I'll get nptl(only) hardened install once stage1 is gone. i386 does not have nptl, and I've done change CHOST emerge -e system emerge -e world job a couple of times and it never went smoothly. Probably what you want is to create static bash gcc binutils etc. stuff like in stage1. With those one can change the c library at hearts content. I never tried it, but I believe that there is a USE flag for building them that way. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpht0cp85L7Z.pgp Description: PGP signature
Re: Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, Nov 23, 2005 at 08:19:40AM -0500, Ned Ludd wrote: ha ok new rule for me. drink coffee before sending first mail of the morn. What's this supposed to imply? That you didn't intend to repeat yourself in the original mail - or that hardened will continue to ship 2.4.x stages for 2006.0+? ;) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpcQfdrfqNro.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, 2005-11-23 at 10:24 +0100, Paul de Vrieze wrote: Most people that complain are probably misinformed about the usefulness of stages 1 and 2. They are really only useful if you know what you're doing and don't really need the handbook that much. Those users should be able to find the alternative installation docs. I do agree however that there should be some link to the relevant documentation from the handbook. There is a link. It was in since the docs were moved. Also, I plan on working with the documentation team to come up with an Advanced Installation Topics type guide that will not only give information on the lower stages, but also how to make a stage1 install from a stage3 tarball. It will likely also cover things like Hardened, provided they want it that way. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, 2005-11-23 at 16:57 +0100, Henrik Brix Andersen wrote: On Wed, Nov 23, 2005 at 08:19:40AM -0500, Ned Ludd wrote: ha ok new rule for me. drink coffee before sending first mail of the morn. What's this supposed to imply? That you didn't intend to repeat yourself in the original mail - or that hardened will continue to ship 2.4.x stages for 2006.0+? ;) That I did not intend to repeat myself. Before hitting send I usually take whatever mail copy and paste it into $EDITOR then wrap it at 72 chars wide and delete the unwrapped block. Clearly I forgot the last step. As for hardened and 2.4.x it seems most of our users are wanting 2.6.x now and unless users/devs show interest I can't really see us needing to produce a new set of 2.4.x based 2006.x stages. -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: new developer Joshua Nichols (nichoj)
Duncan wrote: Petteri Räty posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 00:26:57 +0200: Jochen Maes wrote: Hello all, I'd appreciate a nice welcome and a descent slap on the butt when you pass him... Joshua, welcome! http://tinyurl.com/n9qb I hope to see this list near hundred soon! OK, this is a gripe of mine, so... It is customary to write stuff with a humorous note to new developers. If you join [EMAIL PROTECTED] you will see the following topic: 16:19 -!- Topic for #gentoo-java: Java on Gentoo Linux | For Java issues not related to Gentoo, please refer to ##java | Java Bugs: http://tinyurl.com/n9qb | [EMAIL PROTECTED] | Have a bug? http://bugs.gentoo.org/ | http://gentoo-wiki.com/Java | http://www.gentoo.org/proj/en/java/ | http://gentooexperimental.org/svn/java/ (Its back!) | Theme of the century: 1.5 (http://gentoo-wiki.com/Java_FAQ Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Possible solution: email subdomain
On Wed, 23 Nov 2005 03:39:08 -0700 Duncan [EMAIL PROTECTED] wrote: Here's the proposal again. If there's an issue with it, shoot it down, but from here, it certainly seems to fit the bill. Again, I'd /love/ to say I was the one that came up with it, but I wasn't. =8^) * give [AH]Ts a name[EMAIL PROTECTED] address. - It's not a subdomain, so the existing infrastructure should have no problems with it. - [EMAIL PROTECTED] remains distinctive enough it should alleviate any doubts or confusion over status. - the biggest possible objection I can see is that the root, [EMAIL PROTECTED], is already in use. Thus, in particular, I'd like to see his reaction to this proposal. We could, of course, take the same idea and change the root, if necessary. My previous suggestion, intern, would work, or assistant, or something else. Tester is of course short and concise, but intern or assistant would be more generic, allowing the possiblity of other non-tester additions, in the future, with the same root. Has the same problem as a subdomain as it creates two classes of devs. So it would solve the potential technical problems, but we still have the semantic issues. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
On Wed, 23 Nov 2005 08:26:03 +0200 Alin Nastac [EMAIL PROTECTED] wrote: Marius Mauch wrote: If not, i *personally* could go slowly removing the entries, along with other people willing to help, or any other _better_ suggestion to deal with this? Don't do this without explicitly checking with the maintainer for a package (if existant). Generally redundant entries in package.mask don't hurt, so if it's not absolutely clear that the entry is not needed anymore keep it. Hmm.. I fail to see why package.mask shouldn't be cleaned without everyone's consent. Assuming the script is correct, why would you contact the maintainer of package foe when the oldest version in the current tree is bigger than the masked one? Because there are more scenarios than the one you see. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] R/O CVS access and its purpose for ATs (was Email subdomain)
On Tue, 2005-11-22 at 17:56 -0600, Lance Albertson wrote:
Marius Mauch wrote:
On Sun, 20 Nov 2005 09:32:55 +1100
Ben Skeggs [EMAIL PROTECTED] wrote:
Anyway, the most important reason for the GLEP (IMO) is giving AT's
r/o access to CVS. When working on bugs, it's always fun to find out
that the problem has already been resolved and just hasn't made it to
your local rsync mirror yet..
Out of curiosity, what's the more important aspect of r/o cvs:
- more up to date
Not necessarily true. We would not have the anon cvs access from our
primary cvs server. It would be synced on a regular basis to a separate
box. The newer cvs (which isn't on lark yet) may give us capabilities to
have a more 'live' cvs anon system. But as of now, the best infra can
provide is 30 minute updates. I don't want to poll the cvs more than
that to keep down the load.
- easier selective updates
Yup, that's definitely a plus.
And herein I think lies some confusion. Personally if I were an AT both
would be important but more to the point the more up to date issue
would be the most important. I think that there is a need for the ATs to
be able to work in direct conjunction with a dev, an AT catches an
error, a dev fixes it in CVS using a *well tested* patch, an AT does a
`cvs up` and retests to try and catch *other* errors all within a matter
of *single digit* minutes. This is a very powerful tool, rather then
what they have to do now which is either wait for it to hit the rsync
mirrors, a dedicated rsync mirror, a dedicated anoncvs box, or e-mail
the ebuilds (and patches) back and forth. Note the two highly stressed
things up there...this should not be used so ATs can vet patches (wither
to ebuilds or to source), the patches should be well tested long before
they reach our tree...
Lance:
I know this is a far cry from what you are proposing, and I understand
that the present CVS server cannot handle this sort of load but I
believe that this was the original intention at least...someone correct
me if I am wrong.
I think that this issue has to be nailed down *before* we get any
further in discussion.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: new developer Joshua Nichols (nichoj)
On Wed, 23 Nov 2005 06:05:09 -0700 Duncan [EMAIL PROTECTED] wrote: If it's so useless, after all, would someone have spent the time to post it? Apparently someone did. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Dev: Marien Zwart (marienz)
Hola all. Please welcome Marien Zwart, aka marienz to the crew. He's joining up as a python monkey, working on twisted (2.x stable ebuilds anyone? ^.^), portage 3 hacking, and pretty much anything python wise. Finally, he's been helping out in #gentoo for quite some time. His words- From Groningen, the Netherlands, where I study physics/mathematics. Interests: general messing around with computers, used to do scuba diving but haven't gotten around to it much recently, sailing, listening to and making music (I play keyboard). Oh, and one thing I'd like to add since I think I've seen bits snipped from this in new dev announcements: sorry people from New Zealand, contrary to what some people think my nick does *not* stand for Marie from New Zealand, it stands for Marien Zwart, I'm male, and I live on the opposite side of the globe. Please take a moment to make him feel welcome, and make the usual attempt to dump bugs off on the new blood. :) ~harring pgp8SHMkcVPZr.pgp Description: PGP signature
Re: [gentoo-dev] R/O CVS access and its purpose for ATs (was Email subdomain)
On Wed, Nov 23, 2005 at 10:38:39AM -0500 or thereabouts, Daniel Ostrow wrote: And herein I think lies some confusion. Personally if I were an AT both would be important but more to the point the more up to date issue would be the most important. I agree -- this was the main point of the original GLEP. an AT does a `cvs up` and retests to try and catch *other* errors all within a matter of *single digit* minutes. I do question the need for single digit minutes. 30 minutes may be too much, but I think we could probably live with something in the 10-15 minute range. (if folks disagree, please speak up) I know this is a far cry from what you are proposing, and I understand that the present CVS server cannot handle this sort of load but I believe that this was the original intention at least...someone correct me if I am wrong. Anything is possible -- it's merely a matter of how much money we want to spend in the process. So far, nobody has really come back and said that using CVS, specifically, is a requirement. So, at this point, all options are on the table, but the main goal is to provide something that is as close to real-time as possible and allows authorized individuals to synchronize far more often than the current public rsync mirrors. All this is for a targeted group of up to ~100 users. Can we agree on these requirements? Are there others that I've left out? If not, we can start working on an implementation plan. --kurt pgp7WBqBtm1do.pgp Description: PGP signature
[gentoo-dev] Re: Digest of gentoo-dev@gentoo.org issue 132 (7727-7776)
UNSUBSCRIBE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, 2005-11-23 at 01:40 -0500, Curtis Napier wrote:
big_snip
Accessibilty guidelines say that all text links should be underlined. I
made an exception for the grey menu bar for aesthetic purposes but will
not make an exception for any other links.
/big_snip
Given the above shouldn't the text links below each advertisement
graphic also be underlined. The implication of the current text is that
they are not links at all when they are.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] R/O CVS access and its purpose for ATs (was Email subdomain)
Daniel Ostrow wrote: Lance: I know this is a far cry from what you are proposing, and I understand that the present CVS server cannot handle this sort of load but I believe that this was the original intention at least...someone correct me if I am wrong. One of the issues we had with direct cvs access is managing all of the AT accounts. If we're talking 50-100 ATs, that increases our user account management load by a lot considering we only have 300 developers right now. The other reason is of course with load on lark itself. We can only do so many concurrent cvs up's of the full tree and adding this many users concerns me alot with that aspect. As what kurt said in a followup to this email, If we can nail down that the primary need of the GLEP is quick access to changes, that will help us a lot in figuring out the logistics of the issue. I know pylon had talked about the newer cvs allowing for a virtually 'live' update to another cvs box via a commit hook, but he's been rather busy lately and hasn't had a chance to work on that. I think that has the best hope down the road of resolving this GLEP. I would just like to keep the management of lark to the minimum if at all possible, so for now I would prefer a restricted rsync module or cvs box that gets updated every X minutes. Cheers- -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
Mike Frysinger wrote: On Tue, Nov 22, 2005 at 08:29:36PM -0800, Tuan Van wrote: Luis F. Araujo wrote: Hello everyone, A few days ago i glanced over package.mask , and i was surprised about how many non-existent ebuild/packages entries are there. please adjust your script. =cat/foo-1.2 is valid even though foo-1.2 is no longer in the tree. I looked at the top 4 line in your list, they are all valid entries. yes, i imagine there are a bunch of these false positives ... you can see the gcc-config mask is wrongly flagged for this reason -mike Yes, the script as you might already noticed only checks for specific ebuilds versions entries. I will try to tweak a it a bit more so it could filter more properly the list. Oh, and i am using a small interpreter i am writing for the script , so _many_ things are being proved here, so bear with me :-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
Marius Mauch wrote: On Wed, 23 Nov 2005 08:26:03 +0200 Alin Nastac [EMAIL PROTECTED] wrote: Marius Mauch wrote: If not, i *personally* could go slowly removing the entries, along with other people willing to help, or any other _better_ suggestion to deal with this? Don't do this without explicitly checking with the maintainer for a package (if existant). Generally redundant entries in package.mask don't hurt, so if it's not absolutely clear that the entry is not needed anymore keep it. Hmm.. I fail to see why package.mask shouldn't be cleaned without everyone's consent. Assuming the script is correct, why would you contact the maintainer of package foe when the oldest version in the current tree is bigger than the masked one? Because there are more scenarios than the one you see. Marius That's precisely why i m asking for every dev taking care of their own scenarios *if possible*. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
Looks nice in Firefox-1.0.7-r3 with SyncMaster710N (birghtness 35, contrast 65). Suggestions (wrt http://wwwredesign.gentoo.org): 1) The additional links in green at the top look out of place, a bit hard to read, and there lacks any break between the links adding to reading difficulty and, perhaps, difficulty in accessibility services; I don't run any, but take a look at http://webxact.watchfire.com. 2) Personally, I kind of like the infinity logo, but coupled with the bubble g is a little too much. 3) The links on the main bar (About, Get G, Docs) could use some separation between them to help the eye break the links. I thought the bar on w.aaronshi.com/gentoo did a fine job at that. 4) The next row of cells proclaiming Gentoo's goodness ... Interesting info for new people, but doesn't look quite right. Cell 2 (Packs + Docs = potential) is hard to read; perhaps breaking each part into its own line would help, but that almost creates more issues. Personally, when I see a Please Donate button at the top, it always feels like I'm being hustled. I'd suggest putting it at the bottom; really, the placement depends on if your point-of-view: if you're paying for the server or visiting the site. The last thing about this row of cells is the vertical space could be tightened up; going to play problems with larger fonts though. 5) The underline scheme used throughout the page for links looks like they should be acronyms and not links. There are two ways to help distinguish, but they are conflicting: hover and see if you get a title/acronym or the visual change of a new underline. In practice there is no real difference between a title and an acronym. I think the visual changes could be up'ed a bit. The change of underline style isn't really noticeable. Maybe a slightly different shade? *shrug* 6) I liked the white background of w.aaronshi.com/gentoo as opposed to the tinted purple of redesign; it adds more contrast. I also liked, and find them pretty essential, the breaks between the side bars and the main content. Lots of suggestions, but I definately like the new look overall. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 04:57:11PM +, Ciaran McCreesh wrote: I did bring this up a year ago. I brought it up before the close of voting too. Back then, it was claimed that the infinity was just a minor detail and not part of the design itself. Yes, I remember that - I just can't locate it in the archives. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpqV1gNUh5H2.pgp Description: PGP signature
[gentoo-dev] request for comments/review: twisted.eclass
Hi all,
Since it's policy and especially since it's the first time I write one
of these things I'm submitting an eclass I want to add to the tree for
review. It will only be used by the twisted subpackages I'll be
maintaining (see bug 80639).
Subpackage ebuilds using this only have to set MY_PACKAGE,
DESCRIPTION, KEYWORDS and DEPEND. I'd like to get rid of MY_PACKAGE but
I haven't figured out how to convert lowercase to uppercase without
using tr (MY_PACKAGE will be Conch if PN is twisted-conch). Also
adds the ability to run the unit tests for the package and updates
twisted's plugin cache.
Would like to hear about any ideas on how to do that case conversion
and any bugs spotted. If there are no objections I'd like to add this
to the tree in about two days, so bug 80639 can finally be fixed.
--
Marien.
# Copyright 2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: $
# eclass to aid installing and testing twisted packages.
# you should set MY_PACKAGE to something like 'Names' before inheriting.
# you may set MY_PV to the right version (defaults to PV).
inherit distutils versionator
MY_PV=${MY_PV:-${PV}}
MY_VERSION=$(get_version_component_range 1-2 ${MY_PV})
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/${MY_VERSION}/${MY_P}.tar.bz2;
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
twisted_src_test() {
python_version
# This is a hack to make tests work without installing to the live
# filesystem. We copy the twisted site-packages to a temporary
# dir, install there, and run from there.
local spath=usr/$(get_libdir)/python${PYVER}/site-packages/
mkdir -p ${T}/${spath}
cp -R ${ROOT}${spath}/twisted ${T}/${spath} || die
if has_version =dev-lang/python-2.3; then
${python} setup.py install --root=${T} --no-compile || die
else
${python} setup.py install --root=${T} || die
fi
cd ${T}/${spath} || die
PATH=${T}/usr/bin:${PATH} PYTHONPATH=${T}/${spath} \
trial -R ${PN/-/.} || die trial failed
}
twisted_src_install() {
distutils_src_install
if [[ -d doc/man ]]; then
doman doc/man/*
fi
if [[ -d doc ]]; then
insinto /usr/share/doc/${PF}
doins -r $(find doc -mindepth 1 -maxdepth 1 -not -name man)
fi
}
update_plugin_cache() {
einfo Updating twisted plugin cache...
python_version
# we have to remove the cache or removed plugins won't be removed
# from the cache (http://twistedmatrix.com/bugs/issue926)
rm
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/twisted/plugins/dropin.cache
# notice we have to use getPlugIns here for =twisted-2.0.1
compatibility
python -c from twisted.plugin import IPlugin,
getPlugIns;list(getPlugIns(IPlugin))
}
twisted_pkg_postrm() {
distutils_pkg_postrm
update_plugin_cache
}
twisted_pkg_postinst() {
distutils_pkg_postinst
update_plugin_cache
}
EXPORT_FUNCTIONS src_test src_install pkg_postrm pkg_postinst
pgpdTyhgtfMRU.pgp
Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, 23 Nov 2005 20:49:47 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: | On Wed, Nov 23, 2005 at 04:57:11PM +, Ciaran McCreesh wrote: | I did bring this up a year ago. I brought it up before the close of | voting too. Back then, it was claimed that the infinity was just a | minor detail and not part of the design itself. | | Yes, I remember that - I just can't locate it in the archives. It was on -core. But there was a nice forums post too. Sven Vermeulen writes at http://tinyurl.com/amyy3 : Afaicr, the infinity sign will be kept, but I know a huge discussion will be held on this. It's not important in this stage of the development though... And now we're told that it *was* important at that stage and it's too late to change things? Riiight. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] enewuser/enewgroup getting their own eclass
OK. I've been looking at some of these issues we've been having, and I've been thinking of moving enewuser, egetent, and enewgroup to their own eclass. This will resolve some issues with things in system, or otherwise early on, requiring shadow on Linux to get useradd. Two examples of this are bug #113298 and bug #94745. By putting them in their own eclass, we can keep from adding shadow to DEPEND in eutils, while still putting the dependency in the eclass that uses it. I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: new developer Joshua Nichols (nichoj)
Petteri Räty posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 16:25:21 +0200: 16:19 -!- Topic for #gentoo-java: Java on Gentoo Linux | For Java issues not related to Gentoo, please refer to ##java | Java Bugs: http://tinyurl.com/n9qb | [EMAIL PROTECTED] | Ahh.. well explained. Thanks! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote: I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. Well if you can give us an ISO date it would be simpler ;) Mainly because I have nfc when Thanksgiving holiday is... Anyway, please remember to put shadow's dependency under userland_GNU? ( ) conditional or it will break Gentoo/ALT systems. And I think we could move there egethome at that point, if there are no problems with moving functions around eclasses. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsbEPxom0kB.pgp Description: PGP signature
[gentoo-dev] ***SPAM*** Gentoo
I want have Gentoo in e-shop with Linux distributions. I find, that Gentoo is under GNU/GPL. Must I distribute in e-shop sources of Gentoo too? Where I can found them(sources)? Where I can found graphics, which I can use on CD with Gentoo? With best regards Filip Bartmann - Tento e-mail byl odeslany postovnim systemem https://horde.miramo.cz/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Possible solution: email subdomain
Marius Mauch posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100: On Wed, 23 Nov 2005 03:39:08 -0700 Duncan [EMAIL PROTECTED] wrote: Here's the proposal again. If there's an issue with it, shoot it down, but from here, it certainly seems to fit the bill. Again, I'd /love/ to say I was the one that came up with it, but I wasn't. =8^) * give [AH]Ts a name[EMAIL PROTECTED] address. - It's not a subdomain, so the existing infrastructure should have no problems with it. - [EMAIL PROTECTED] remains distinctive enough it should alleviate any doubts or confusion over status. Has the same problem as a subdomain as it creates two classes of devs. So it would solve the potential technical problems, but we still have the semantic issues. Viewpoint seen, and thanks for posting it. However, the proposed solution still appears from here to fit the bill, because... - The folks to whom it will apply are /not/ full devs, as they haven't gone thru the dev process, so it's not creating two classes of devs, but rather creating a distinction between devs and this not-dev class. - Lack of said distinction appears to have been one of the specific items on the list the first time thru thru. The council said it had to be added, so it was. The council then approved the change with the addition made at their instruction. Sure, we could go back and argue the wisdom of the original point made by the council, but to this point, I haven't seen that seriously debated, nor do I believe it should be, because either we accept that the council has the authority to make those sorts of decisions or we don't, and if we don't, what do we have a council for? It would seem to me that there are two opposing viewpoints, one taking the position that ATs should be practically treated as devs, no distinction, the other taking the position that they are just users and the whole AT position shouldn't exist. The council position seems to be a generally reasonable compromise, that they are a class of user that should be recognized as making a contribution and having responsibilities beyond that of an ordinary user, but that they should remain distinct from full devs, because they are NOT full devs. Part of that position is that they get a gentoo mail address, but one recongizably distinct from that of a gentoo dev. As proposed, that recognizably distinct address was a subdomain. However, infra has objected to that as unworkable. However, the wording of the GLEP makes it clear that the subdomain was a proposal and that the details were to be worked out. What this possible solution does is provide a way for that to happen -- something infra shouldn't have issues with, while at the same time, implementing that aspect of the GLEP as adopted by the council. What I'm saying is that this is a solution consistent with the situation on the ground as we no have it. Sure, we can argue that the situation should be different, but this, from my viewpoint, is a pragmatic solution to a very tough and controversial problem, that the council has none-the-less expressed its view on, with said view approaching IMO about the best possible compromise between the opposing viewpoints. I'm just trying to provide a way (thanks to the original suggestor) to get some progress on the ground, instead of seeing it constantly debated, with no real conclusion or practical application of the debate in sight. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] request for comments/review: twisted.eclass
On Wed, 23 Nov 2005 19:44:32 +0100 Francesco R. [EMAIL PROTECTED] wrote: | `tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ` | | ^^^ this one is chosen from MySQL configure script so it should be | portable (or as often I'm missing something ?) Can't use tr in global scope. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: OK. I've been looking at some of these issues we've been having, and I've been thinking of moving enewuser, egetent, and enewgroup to their own eclass. This will resolve some issues with things in system, or otherwise early on, requiring shadow on Linux to get useradd. Two examples of this are bug #113298 and bug #94745. By putting them in their own eclass, we can keep from adding shadow to DEPEND in eutils, while still putting the dependency in the eclass that uses it. You do this, and you'll break binpkgs that rely on it existing in eutils. Yes it's annoying, but you _have_ to lead the functionality in eutils, duplicating it into whatever class you shove it into. That's the other side of the can't remove eclasses rule- can't yank functionality that is going to break installed ebuilds and binpkgs. I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. I'd delay this a bit personally, since it's a widespread change, and because people are probably going to be offline due to holiday cruft. Yah... you probably have the time to do it during the holiday stuff, but again, affecting a sizable collection of packages and requires ebuild devs to change the eclasses they're using. Plus the binpkg issue from above. ;) ~harring pgpX1g6QWYb1d.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo
On Wed, 23 Nov 2005 19:49:18 +0100 Filip Bartmann [EMAIL PROTECTED] wrote: | I want have Gentoo in e-shop with Linux distributions. I find, that | Gentoo is under GNU/GPL. Must I distribute in e-shop sources of | Gentoo too? Where I can found them(sources)? Where I can found | graphics, which I can use on CD with Gentoo? Consult your lawyer. Any legal advice you get on this list will be bogus. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Possible solution: email subdomain
On 11/23/05, Duncan [EMAIL PROTECTED] wrote: Marius Mauch posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 15:40:49 +0100: On Wed, 23 Nov 2005 03:39:08 -0700 Duncan [EMAIL PROTECTED] wrote: Here's the proposal again. If there's an issue with it, shoot it down, but from here, it certainly seems to fit the bill. Again, I'd /love/ to say I was the one that came up with it, but I wasn't. =8^) * give [AH]Ts a name[EMAIL PROTECTED] address. - It's not a subdomain, so the existing infrastructure should have no problems with it. - [EMAIL PROTECTED] remains distinctive enough it should alleviate any doubts or confusion over status. Has the same problem as a subdomain as it creates two classes of devs. So it would solve the potential technical problems, but we still have the semantic issues. Viewpoint seen, and thanks for posting it. However, the proposed solution still appears from here to fit the bill, because... - The folks to whom it will apply are /not/ full devs, as they haven't gone thru the dev process, so it's not creating two classes of devs, but rather creating a distinction between devs and this not-dev class. Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, 2005-11-23 at 19:30 +0100, Diego 'Flameeyes' Pettenò wrote: On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote: I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. Well if you can give us an ISO date it would be simpler ;) Mainly because I have nfc when Thanksgiving holiday is... ISO date == anytime after tomorrow Anyway, please remember to put shadow's dependency under userland_GNU? ( ) conditional or it will break Gentoo/ALT systems. And I think we could move there egethome at that point, if there are no problems with moving functions around eclasses. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, 2005-11-23 at 12:52 -0600, Brian Harring wrote: On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: OK. I've been looking at some of these issues we've been having, and I've been thinking of moving enewuser, egetent, and enewgroup to their own eclass. This will resolve some issues with things in system, or otherwise early on, requiring shadow on Linux to get useradd. Two examples of this are bug #113298 and bug #94745. By putting them in their own eclass, we can keep from adding shadow to DEPEND in eutils, while still putting the dependency in the eclass that uses it. You do this, and you'll break binpkgs that rely on it existing in eutils. Yes it's annoying, but you _have_ to lead the functionality in eutils, duplicating it into whatever class you shove it into. I had thought that this was resolved already in portage. That's the other side of the can't remove eclasses rule- can't yank functionality that is going to break installed ebuilds and binpkgs. Fine. I can simply make a new eclass and change the affected ebuilds. I really don't have a problem with this. The main reason for it is that whatever eclass that enewuser is in really needs to DEPEND on shadow on Linux. Which brings up another point. I see that a good number of packages are calling enewuser in pkg_preinst. These packages do not need shadow (though the system might, but that's outside my scope) once they are installed, only to install. However, it is not needed to build. What *DEPEND is correct? I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. I'd delay this a bit personally, since it's a widespread change, and because people are probably going to be offline due to holiday cruft. I was planning on taking care of it myself. I was going to remove the functions from eutils.eclass as my last step, but now I would simply skip that step. I would probably do something like add a warning to the functions under eutils.eclass, too. Yah... you probably have the time to do it during the holiday stuff, but again, affecting a sizable collection of packages and requires ebuild devs to change the eclasses they're using. Plus the binpkg issue from above. ;) ~harring -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re[2]: [gentoo-dev] Re: Possible solution: email subdomain
23.11.2005, 20:07:15, Dan Meltzer wrote: Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] NO (I sincerely hope at least), and please let's finally stop messing w/ email addresses causing further confusion and administrative overhead for no good reason. :=( *sigh* -- jakub pgpVcDtneAbEB.pgp Description: PGP signature
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | These packages do not need shadow (though the system might, but that's | outside my scope) once they are installed, only to install. However, it | is not needed to build. What *DEPEND is correct? It fits into RDEPEND (oddly enough), since binpkgs will need it as well and they don't get DEPEND stuff. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhMWnXVaO67S1rtsRAv4RAJ45Wsjoz4wBzpjI+Tw3S7LAdw7NXACguR4H 9kHmi0rLZHbd69kQZlZNTW4= =GfzO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: Re[2]: [gentoo-dev] Re: Possible solution: email subdomain
forgot my sarcasm tags :) Get the idea though? On 11/23/05, Jakub Moc [EMAIL PROTECTED] wrote: 23.11.2005, 20:07:15, Dan Meltzer wrote: Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] NO (I sincerely hope at least), and please let's finally stop messing w/ email addresses causing further confusion and administrative overhead for no good reason. :=( *sigh* -- jakub -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, 2005-11-23 at 11:40 -0800, Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | These packages do not need shadow (though the system might, but that's | outside my scope) once they are installed, only to install. However, it | is not needed to build. What *DEPEND is correct? It fits into RDEPEND (oddly enough), since binpkgs will need it as well and they don't get DEPEND stuff. That is what I thought. I was just wondering if there were some other *DEPEND that I wasn't aware of that fit the bill of needed for installing from a package but not needed afterwards. It doesn't *really* matter since shadow is in system on any machine this would affect anyway, but you get my thinking. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On 11/22/05, Chris Gianelloni [EMAIL PROTECTED] wrote: Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. I may not be the typical user, but I use Stage1 to build servers, because I can fit a boot image + stage1 tarball on a small usb drive, boot to that, and then I nfs mount $DISTDIR and $PORTDIR from a central server. Mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: enewuser/enewgroup getting their own eclass
Diego 'Flameeyes' Pettenò posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 19:30:21 +0100: On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote: I'd be willing to make all the changes to the tree to facilitate this, and unless someone has a really good reason not to do so, I think I'll probably do it after the Thanksgiving holiday. Well if you can give us an ISO date it would be simpler ;) Mainly because I have nfc when Thanksgiving holiday is... Fourth Thursday in November... so tomorrow... However, traditionally, it's a long weekend, with office and government workers having Friday off as well, and Friday then becoming the biggest shopping day of the year (many stores open at 6 AM and have 1 hour, two hour, 'till noon, and/or rotating hourly specials) as the first day of the official Christmas shopping season, and often the only non-weekend day many office workers get. Thus, after the Thanksgiving holiday could mean either on Friday, or after the weekend, Monday/Tueday-ish, so it's still a bit ambiguous. In any case, it's relatively soon, altho with the message just posted, Friday would give half the time to respond compared to early next week. From an outside perspective, I'm sure it's amazing and crass that USians see nothing unusual about the national holiday of thanks being directly followed by the biggest day of commercial greed in the entire year, as the opening day of the biggest season of commercial greed, obsensibly as preparation for the day of celebration of the birth of Jesus Christ, the man seen as the Son of God, and quoted as saying it's easier for a camel to pass thru the eye of a needle than for a rich man to get into paradise! Interesting commentary on our culture! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On 11/23/05, Mike Owen [EMAIL PROTECTED] wrote: On 11/22/05, Chris Gianelloni [EMAIL PROTECTED] wrote: Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. I may not be the typical user, but I use Stage1 to build servers, because I can fit a boot image + stage1 tarball on a small usb drive, boot to that, and then I nfs mount $DISTDIR and $PORTDIR from a central server. Correct me if I am wrong, but doesn't the boot image itself have nfs built in? why a stage1 at all... Mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:06:18PM -0700, Duncan wrote: Fourth Thursday in November... so tomorrow... Except in Canada, where it falls on the second Monday in October. So Chris might to well to have a time-machine and make the change last month. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpijrmtmRNJ5.pgp Description: PGP signature
Re: [gentoo-dev] Re: enewuser/enewgroup getting their own eclass
On Wed, 2005-11-23 at 13:06 -0700, Duncan wrote: From an outside perspective, I'm sure it's amazing and crass that USians see nothing unusual about the national holiday of thanks being directly followed by the biggest day of commercial greed in the entire year, as the opening day of the biggest season of commercial greed, obsensibly as preparation for the day of celebration of the birth of Jesus Christ, the man seen as the Son of God, and quoted as saying it's easier for a camel to pass thru the eye of a needle than for a rich man to get into paradise! Interesting commentary on our culture! What the hell does this have to do with Gentoo development? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | That is what I thought. I was just wondering if there were some other | *DEPEND that I wasn't aware of that fit the bill of needed for | installing from a package but not needed afterwards. It doesn't | *really* matter since shadow is in system on any machine this would | affect anyway, but you get my thinking. /me begins clamoring for IDEPEND (install-time deps). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhNNUXVaO67S1rtsRAodMAJ0ZxD7gWiRU7r1SggpH/Bgd7NZ4mACg2N8Y onOzQzXwd/6hrO7+acpLonQ= =qGhH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 12:38:44PM -0800, Donnie Berkholz wrote: /me begins clamoring for IDEPEND (install-time deps). I've read the initial post a couple of times now, and I still don't get it. Could somebody please clarify how this differs from DEPEND? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpVP6KGCJR15.pgp Description: PGP signature
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: | I've read the initial post a couple of times now, and I still don't | get it. | | Could somebody please clarify how this differs from DEPEND? Because DEPEND is only needed for the actual build (src_* functions). With binary packages, all the pkg_* functions are run but DEPEND packages are not required to be installed. So anything external run in a pkg_* function must be in RDEPEND because it cannot be just in DEPEND, and those are the only two options. Does that help? Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhNkEXVaO67S1rtsRAgpEAJ9R9k6mFV4qJXCs86OR6ENDNJgq+gCeKesw hEdAKjFvheFx0rJFkRLFYso= =+Df3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On 11/23/05, Dan Meltzer [EMAIL PROTECTED] wrote: On 11/23/05, Mike Owen [EMAIL PROTECTED] wrote: I may not be the typical user, but I use Stage1 to build servers, because I can fit a boot image + stage1 tarball on a small usb drive, boot to that, and then I nfs mount $DISTDIR and $PORTDIR from a central server. Correct me if I am wrong, but doesn't the boot image itself have nfs built in? why a stage1 at all... Because I'm lazy, and used to doing the stage1 thing :) Mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:03:00PM -0800, Donnie Berkholz wrote: Because DEPEND is only needed for the actual build (src_* functions). With binary packages, all the pkg_* functions are run but DEPEND packages are not required to be installed. So anything external run in a pkg_* function must be in RDEPEND because it cannot be just in DEPEND, and those are the only two options. Does that help? Yes, thank you - now I understand the issue :) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpSDuYX1xG74.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass
On Wed, 23 Nov 2005 14:14:31 -0700 Duncan [EMAIL PROTECTED] wrote: | It may be possible to automate code creation, but it's not possible to | automate a community This list is not about making a 'community'. It's about getting development done. If you want to go and make lots of noise about communities, go and do it on the forums or somewhere else where you won't be wasting our time. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tuesday 22 November 2005 16:14, Chris Gianelloni wrote: Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. It's useful if you have to change compiler or other tool-chain part right from the start (e.g. use 3.4.* on i386, where 3.3.* is default) on PentiumM in order to use -march=pentium-m. It's certainly possible to start with stage 3, but makes total process last longer (Much more to recompile) and is more error-prone. Example of this risk: When installing GCC3.4 one may forget to install old libstdc++ (it has to be unmasked, and depending on use-flags it me not yes be reauested by portage!) and have a missing linking dependency on libstdc++ in python (no more portage to recompile python!) once GCC3.3 is unmerged. For some server-setups it may also be useful to start from a very minimal base in order to avoid hidden dependencies caused by unconditionnal operations of configure which add unwanted dependencies (e.g. USE-flags disables dep, but configure script still uses it, be it directly or indirectly) Sure you can depclean afterwards to removed unneeded packages, but as a precaution a emerge -e world would need to be done (loss of time). It's fine to make stage1/stage2 non-recommended as they bring no advantage over stage3 for most desktop systems, but should stay available and documented for minority who has valid use of it. Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass
23.11.2005, 22:14:31, Duncan wrote: [irrelevant twaddle omitted] It may be possible to automate code creation, but it's not possible to automate a community, and humans in such a community /don't/ tend to stay strictly on topic. That's just the way humans are, and have been for far longer than either you or I have been around. I can't speak for others, but personally I'm not interested in receiving such crap in my mailbox. There's enough traffic here as it is. Please, keep on topic or go chat elsewhere. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpPaxpB7jwvO.pgp Description: PGP signature
[gentoo-dev] Re: Update of http://wwwredesign.gentoo.org
Mike Frysinger wrote: On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote: The artwork is all part of the winning design. Any issues with the infinity symbol should have been addressed a year ago. well it clearly wasnt, might as well cover it now before the site goes live ... as i pointed out, considering its location, this means that our new logo basically becomes gentoo with an infinity sign well it's good enough for fedora. ;P http://capstrat.com/development/fedora/index.php?imagenumber=14 i actually like the new logo. but i'm also secure in my choice of distribution and don't care what other people might think. *all extraneous information and decorative news headers were removed from the front page to help readability and to bring focus to the information. This includes the cow image and text. Overwhelming amounts of information on the front page should no longer be a problem. This also brings the jumppads closer to the top so new users will be better able to spot them. seems like everything was cut ... now the frontpage is just a simple site index page ? i liked the simple cow/about blurb myself i did too. it does seem like there should be something between the purple blurbs and the news. i also wish the jump-pads were on the left, but if that's not an option, then there's no point arguing it. all in all i think it looks great. it's been a long time coming. thanks for doing this. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Possible solution: email subdomain
Kurt Lieber posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Nov 2005 22:28:35 +: This solution has the same yellow star stigma that the original proposal does. Agreed, altho it seems that's the way the council wanted it... The only outstanding administrative issue is how these aliases are managed. The same management issues exist regardless of whether we're talking about [EMAIL PROTECTED] or [EMAIL PROTECTED] Then I missunderstood. The infra objections I'D read appeared (to me) to be to the subdomain, as it wasn't an issue with the original GLEP. However, I now see the original GLEP's proposal of addresses vs. the new GLEP's proposal of aliases is a valid rendering of the objections as well, and indeed, as you so patiently explain, this doesn't affect that aspect. Being infra, that pretty absolutely quashes my previous understanding, and with it, the proposed solution. Thanks for making it clear to me. Shot down, indeed, but that's exactly what I asked for! =8^) Too bad it wasn't that simple! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Maintainer's guides?
As someone probably already know (thru my blog or by looking to my commits), I'm being lately working on documenting the process I use to maintain some of my packages, in particular xine[1], vlc[2] and alsa[3]. I'm going in the next days to add more and more documentation about this as I want to leave enough notes for someone else to step over if I have to go away for a medium/long period. Now the problem is that while xine vlc and alsa belongs to sound and video projects, and I'm writing the maintainers' guides there, other packages such as rtorrent, bsdtar and netatalk does not belong to a project, so I don't know where to stick those maintainers' guides in. Does anybody have options? [1] http://www.gentoo.org/proj/en/desktop/video/xine.xml [2] http://www.gentoo.org/proj/en/desktop/video/vlc.xml [3] http://www.gentoo.org/proj/en/desktop/sound/alsa.xml -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzZYV5uiFXS.pgp Description: PGP signature
[gentoo-dev] Multi hash support in portage - status
So, along with the gpg signing stuff came along again the question to have multiple hash formats in digests and manifests. Current status is that portage only generates MD5 checksums and can verify both MD5 and SHA1 checksums. Creation of SHA1 is also possible but has so far been disabled as older portage versions would break if they found a non-MD5 line in digest files (this was fixed somewhere last year in the .51 series). Ok I have three modifications that are pending to go into portage: - The first simply enables creation of SHA1 checksums (and others if implemented like with the second mod), if you want to try it yourself see the attached patch. - Another thing that has been requested often is to offer even more hashing functions. Earlier today I sent a patch to the gentoo-portage-dev list that adds optional support for SHA256 and RMD160 if dev-python/pycrypto is installed on the system. - The last and most intrusive change is support for a new enhanced Manifest format (called Manifest2 for now). Don't worry, there will be GLEP and more info before this gets added, I just list here for reference below The first two changes are ready to be added and deployed (in .54), so without looking at the third one it would be a no brainer. But of course there is a drawback: The current Manifest/digest format is quite inefficient wrt storing multiple checksums as it repeats the filename and filesize for every checksum added, it looks like this: MD5 82e806ed62f0596fb7bef493d225712f metadata.xml 269 RMD160 39d775de55f9963f8946feaf088aa0324770bacb metadata.xml 269 SHA1 4fd7b285049d0e587f89e86becf06c0fd77bae6d metadata.xml 269 SHA256 3787959f4a775b1e787b35ff8380949d8f68bd67b81c2cf5a748733c9740cb94 metadata.xml 269 The Manifest2 format solves this problem (and has some other benefits) by listing all checksums on one line: MISCFILE metadata.xml 269 RMD160 39d775de55f9963f8946feaf088aa0324770bacb SHA1 4fd7b285049d0e587f89e86becf06c0fd77bae6d SHA256 3787959f4a775b1e787b35ff8380949d8f68bd67b81c2cf5a748733c9740cb94 MD5 82e806ed62f0596fb7bef493d225712f Not much of a difference you might say, but this is just looking at a pure Manifest2 entry. To keep compability with existing portage versions we have to list both the old format and the new format in the Manifest (digests are handled differently with Manifest2, but the concept also applies to them), which can potentially increase the tree size by ~10% (at a guess). I'm talking about actual data size here, not required discspace. And before you ask why manifest2 if it adds this overhead?, the main point isn't the new format but a long term reduction of the tree size by removing the digest files (but wait for the GLEP to discuss this). So much for background information, now to the actual question: Would you rather have now the ability to create multi-hash digests and Manifests with the result of a short and mid-term larger portage tree (in the long term the format will be phased out hopefully) or rather wait for Manifest2 support (which will definitely include multi hash support)? Basically just getting some feedback before adding it and later getting the complaints about bloating the tree ;) Note that this is (technically) completely unrelated to gpg signing of Manifests, so any gpg related bitching doesn't belong here. Generally only reply here if you're replying to the question I posted (implementation discussions belong on gentoo-portage-dev, and the quota for whining/trolling/flaming for this month was already exceeded). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Multi hash support in portage - status
On Thu, 24 Nov 2005 01:04:32 +0100 Marius Mauch [EMAIL PROTECTED] wrote: Ok I have three modifications that are pending to go into portage: - The first simply enables creation of SHA1 checksums (and others if implemented like with the second mod), if you want to try it yourself see the attached patch. Bah, really have to port my old Outlook mods so I don't keep forgetting the attachments all the time. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. Index: pym/portage.py === --- pym/portage.py (revision 2316) +++ pym/portage.py (working copy) @@ -2095,11 +2095,6 @@ myline += +mysum myline += +myarchive myline += +str(mysize) - if sumName != MD5: -# This cannot be used! -# Older portage make very dumb assumptions about the formats. -# We need a lead-in period before we break everything. -continue mylines.append(myline) return mylines signature.asc Description: PGP signature
Re: [gentoo-dev] Multi hash support in portage - status
On Thursday 24 November 2005 09:32, Marius Mauch wrote: On Thu, 24 Nov 2005 01:04:32 +0100 Marius Mauch [EMAIL PROTECTED] wrote: Ok I have three modifications that are pending to go into portage: - The first simply enables creation of SHA1 checksums (and others if implemented like with the second mod), if you want to try it yourself see the attached patch. Looking through CVS, this was supported in at least portage-2.0.51_rc10 right? This implies that the only versions that will have problems are 2.0.50-r11 and under? If so, they've already got the cascaded profile problem so breaking things a little more won't hurt much. ;) Seriously though, those that can't handle the new format would have to do what? Regenerate digests for sandbox and portage and then emerge each of them with --oneshot? Am I missing anything else there? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: OK. I've been looking at some of these issues we've been having, and I've been thinking of moving enewuser, egetent, and enewgroup to their own eclass. This will resolve some issues with things in system, or otherwise early on, requiring shadow on Linux to get useradd. Two examples of this are bug #113298 and bug #94745. By putting them in their own eclass, we can keep from adding shadow to DEPEND in eutils, while still putting the dependency in the eclass that uses it. i think i suggested this somewhere before, but why dont we just add shadow to packages.build ... then it'll be in stage[123] and the DEPEND will be a moot point -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, Nov 23, 2005 at 06:05:53PM +, Ciaran McCreesh wrote: Afaicr, the infinity sign will be kept, but I know a huge discussion will be held on this. It's not important in this stage of the development though... And now we're told that it *was* important at that stage and it's too late to change things? Riiight. I said that in that stage of the redesign development the logo discussion shouldn't be held as it is part of the design the infinity sign will be kept but that we leave it open for discussion if enough shoulders are put under it (huge discussion). The primary concern at that stage of the development was to continue to develop the design/XSL so that we have something workable when we offer the design to the public... which is now. Like I said before, I rather like the infinity sign. The trustees have had a discussion on this part too. Their decision was that we need a strong, compelling case for not using it since it is something the community has voted on. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgphvGhgBwF9d.pgp Description: PGP signature
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Wed, Nov 23, 2005 at 10:24:55AM +0100, Paul de Vrieze wrote: Most people that complain are probably misinformed about the usefulness of stages 1 and 2. They are really only useful if you know what you're doing and don't really need the handbook that much. Those users should be able to find the alternative installation docs. I do agree however that there should be some link to the relevant documentation from the handbook. Actually the migration process did all that in one step: - Update the Handbook . Remove stage1/2 instructions . Add a /couple/ of references to the Gentoo FAQ - Update the Gentoo FAQ - Update the Gentoo Handbook FAQ Perhaps I should use the blink.../blink tags more often. Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpQD9X7xowdh.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Thu, Nov 24, 2005 at 06:23:37AM +0100, Sven Vermeulen wrote: On Wed, Nov 23, 2005 at 06:05:53PM +, Ciaran McCreesh wrote: Afaicr, the infinity sign will be kept, but I know a huge discussion will be held on this. It's not important in this stage of the development though... And now we're told that it *was* important at that stage and it's too late to change things? Riiight. Like I said before, I rather like the infinity sign. The trustees have had a discussion on this part too. Their decision was that we need a strong, compelling case for not using it since it is something the community has voted on. by 'voted on' you mean the vote that happened on the forums ? i thought that vote was for the different website designs, they didnt really cover aspects of different designs -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
Marius Mauch wrote: [..] So much for background information, now to the actual question: Would you rather have now the ability to create multi-hash digests and Manifests with the result of a short and mid-term larger portage tree (in the long term the format will be phased out hopefully) or rather wait for Manifest2 support (which will definitely include multi hash support)? I'd rather wait for Manifest2 support. What is the ETA for the GLEP and the implementation after i? Cheers, Marc. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] multiple hash functions
On Wed, 23 Nov 2005 14:12:22 -0600 Brian Harring [EMAIL PROTECTED] wrote: Add the keys only if there is a func that can be used- list of required chksums is a config thing (and repoman thing during commiting), so I'm not seeing any reason to have None as a value in your hashfunc mapping... Yeah, makes a bit more sense. Good that nobody saw the nasty trick I had before ;) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
