Re: [gentoo-dev] SCHEDULED DOWNTIME: {cvs,svn}.gentoo.org - 2006-10-05 - 1900UTC - 2300UTC
On Tue, Oct 3, 2006 at 10:38:32 +0200, Nick Devito wrote: On Mon, 2006-10-02 at 18:29 -0400, Michael Cummings wrote: On Mon, 2006-10-02 at 14:13 -0700, Chris White wrote: On Monday 02 October 2006 13:30, Robin H. Johnson wrote: We'll keep status in the topic at #gentoo-dev while we're working on it. Alright, I'm starting a pool on how many people will still ask why cvs and svn are down. Starts at $5, who'se in? Depends - is it a forfeit if I'm both in the pool and one of the first to ask? That's considered cheating, yes ;) I'm sure we'll be able to find an arrangement... -- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpDXFpHzR85c.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On Tue, 2006-10-03 at 02:56 +0200, Lionel Bouton wrote: Here's an updated draft. I included most of your remarks and added some notes on append-flags/filter-flags. I'll probably submit it to Ulrich around the end of the week. I surely hope you don't submit it to Ulrich if you want it to actually ever get in the GWN. Instead, you should submit it to [EMAIL PROTECTED] like the GWN tells you to do. =] Thanks, --- Draft BEGIN --- section titleCFLAGS/title body p Being able to tune the CFLAGS is part of one of the core principles of Gentoo: let the user be in control. Being in control brings both benefits and problems and CFLAGS tuning is not an exception. /p p The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. Example of this are : ul linss_ldap stopped working with c-ffast-math/c (reported to break many packages changing with the actual gcc version)/li lic-fvisibility-inlines-hidden/c still breaks some code/li liif you used gcc-4.0, c-ftree-loop-linear/c now breaks in gcc-4.1(at least with mesa)/li liagain for gcc-4.0 users, c-ftree-vectorize/c is known to be broken in gcc-4.1 (at least for x86 and ppc, amd64 users seem to be safe)/li lic-fforce-addr/c and c-fweb/c break regularly on x86 with video libraries or graphic processing apps which use hand-optimised ASM/li /ul /p p Users with unsupported CFLAGS (see the uri link='http://gentoo-wiki.com/CFLAGS_matrix'CFLAGS matrix/uri for example) might want to return to safe CFLAGS (see uri link='http://gentoo-wiki.com/Safe_Cflags'Safe CFLAGS/uri) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control. /p p Notes: ul liThe gcc man page contains warnings for some unsafe optimization options. You should read it carefully when you experiment with CFLAGS or upgrade GCC on a CFLAGS-customized Gentoo./li liSome options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developper deems them safe (by redefining CFLAGS or using append-flags of the flag-o-matic eclass). For example c-ffast-math/c is added by the xmame/xmess ebuilds on most architectures even if you don't put it in your CFLAGS./li liYou might get an idea of the stability issues of a specific optimization option by running: cfind /usr/portage -name '*.ebuild'| xargs grep -- '-your-risky-optimization-option'/c. It takes quite some time, but might be enlightening: look for the 'filter-flags'./li /ul /p /body /section --- Draft END --- Lionel -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Mon, 2006-10-02 at 22:58 -0400, Mike Kelly wrote: I have a list of all packages in the tree that currently use either of those functions[2]. If you maintain one of these packages, I'd especially appreciate your feedback. You missed games-* (yes, all of them) via the games.eclass, but I'm sure there's a couple more eclasses that do user/group modification. Summarized, the format is: For each profile dir (e.g. profiles/base, profiles/default-linux, etc), a new subdirectory, called accounts is created as necessary. Inside that is a file called defaults, containing default uid/gid ranges, shells, etc for the given profile. Also, there are two directories, user/ and group/, which contain files named after the users and groups to be added. Those files contain more specific uid/gid info, etc. All the files are handled like other files in cascading profiles. Each line in the file is either a shell-style comment, or of the form: key: value. The keys are: uid, shell, home, groups, comment, and gid. What about applications that aren't tied to a profile? How do they work? Doesn't this increase the size of the profiles pretty dramatically? Does it need to be tons and tons of small files, or can we get away with a set of larger files with some sort of header? eg. $ cat defaults [default] uid: 1-999 shell: /bin/false home: /dev/null groups: comment: user created by portage gid: 1-999 $ cat accounts [portage] uid: 250 shell: /bin/false home: /var/tmp/portage groups: portage comment: portage gid: 250 [apache] uid: 81 shell: /bin/false home: /var/www/localhost groups: apache comment: apache gid: 81 As you can see, this changes very little, but reduces the number of small files in the portage tree. Is this necessary? Who knows? Will it makes syncs slightly faster? Not a clue. I'm just throwing out an idea. Anyway, this looks really good. =] -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for October
On Sunday 01 October 2006 02:18, Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC), same bat channel (#gentoo-council @ irc.freenode.net) ! due to some council members needing to do lame stuff like study for school, this has been pushed back to the 19th -mike pgppjWDpUvveT.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lionel Bouton wrote: Here's an updated draft. I included most of your remarks and added some notes on append-flags/filter-flags. I'll probably submit it to Ulrich around the end of the week. --- Draft BEGIN --- section titleCFLAGS/title body p Being able to tune the CFLAGS is part of one of the core principles of Gentoo: let the user be in control. Being in control brings both benefits and problems and CFLAGS tuning is not an exception. /p p The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. Example of this are : ul linss_ldap stopped working with c-ffast-math/c (reported to break many packages changing with the actual gcc version)/li lic-fvisibility-inlines-hidden/c still breaks some code/li liif you used gcc-4.0, c-ftree-loop-linear/c now breaks in gcc-4.1(at least with mesa)/li liagain for gcc-4.0 users, c-ftree-vectorize/c is known to be broken in gcc-4.1 (at least for x86 and ppc, amd64 users seem to be safe)/li lic-fforce-addr/c and c-fweb/c break regularly on x86 with video libraries or graphic processing apps which use hand-optimised ASM/li /ul /p p Users with unsupported CFLAGS (see the uri link='http://gentoo-wiki.com/CFLAGS_matrix'CFLAGS matrix/uri for example) might want to return to safe CFLAGS (see uri link='http://gentoo-wiki.com/Safe_Cflags'Safe CFLAGS/uri) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control. /p p Notes: ul liThe gcc man page contains warnings for some unsafe optimization options. You should read it carefully when you experiment with CFLAGS or upgrade GCC on a CFLAGS-customized Gentoo./li liSome options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developper deems them safe (by redefining CFLAGS or using append-flags of the flag-o-matic eclass). For example c-ffast-math/c is added by the xmame/xmess ebuilds on most architectures even if you don't put it in your CFLAGS./li liYou might get an idea of the stability issues of a specific optimization option by running: cfind /usr/portage -name '*.ebuild'| xargs grep -- '-your-risky-optimization-option'/c. It takes quite some time, but might be enlightening: look for the 'filter-flags'./li /ul /p /body /section --- Draft END --- Lionel Uh, Gentoo-wiki does not get linked. Period. Not in official Gentoo stuff -- the wiki is not supported or endorsed by the developers. It's not remotely official, and in fact contains a great deal of false and/or misleading information, which is why you don't see it mentioned in any documentation (for example). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIouvrsJQqN81j74RAqzwAJ9w6kdDnw1JAKPHfEqBiINVaRTEUQCfYkvX EN1gr+9l5s065I46PRB59U8= =dfSI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Josh Saddler wrote the following on 03.10.2006 18:11 : (...) Lionel Uh, Gentoo-wiki does not get linked. Are there many trying to link to the Gentoo Wiki in official documentation? It seems guns are warm and devs quick to jump to conclusions (re-read the title and the previous discussion on this very subject) :-) Keep cool, I agree with your statement (for numerous reasons), it's just out of context: I propose a 'reminder' chapter for the GWN, that's all. Lionel. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On Tue, 2006-10-03 at 19:16 +0200, Lionel Bouton wrote: Josh Saddler wrote the following on 03.10.2006 18:11 : (...) Lionel Uh, Gentoo-wiki does not get linked. Are there many trying to link to the Gentoo Wiki in official documentation? It seems guns are warm and devs quick to jump to conclusions (re-read the title and the previous discussion on this very subject) :-) Keep cool, I agree with your statement (for numerous reasons), it's just out of context: I propose a 'reminder' chapter for the GWN, that's all. Ok...lets try this... Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... It is inherently unreliable and outside of Gentoo's control. It will eat your dog, kill your cat, club baby seals and make the hole in the O-Zone layer bigger... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 03 Oct 2006 08:09:08 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: I have a list of all packages in the tree that currently use either of those functions[2]. If you maintain one of these packages, I'd especially appreciate your feedback. You missed games-* (yes, all of them) via the games.eclass, but I'm sure there's a couple more eclasses that do user/group modification. Oops, I forgot to account for eclasses. I'll redo my script and run it again later to account for that. What about applications that aren't tied to a profile? How do they work? Well, user management is inherently tied to the userland which is being used, which is in turn tied to the profiles (default-linux, default-bsd, etc). Settings which are userland-agnostic (like default uids, member groups, GECOS comment fields), would be in the settings for the base/ profile. Doesn't this increase the size of the profiles pretty dramatically? I don't think it makes that much of a size difference. Most of this information is now duplicated over many enewuser/group lines in many different ebuilds. With this system, ebuilds just need to have a EUSERS and EGROUPS variable defined listing the users/groups needed. Does it need to be tons and tons of small files, or can we get away with a set of larger files with some sort of header? As you can see, this changes very little, but reduces the number of small files in the portage tree. Is this necessary? Who knows? Will it makes syncs slightly faster? Not a clue. I'm just throwing out an idea. Hmm, parsing that would be a more difficult task for my scripts (which are just basic bash code doing some greps). Also, it seems like the many small files are easier to maintain. I don't know enough about rsync to know how it would affect efficiency, though. It's something I'll try and look into further. Anyway, this looks really good. =] Thanks! -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On 03/10/06, Daniel Ostrow [EMAIL PROTECTED] wrote: Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/xen/xen-3.0.2.ebuild?rev=1.6 See pkg_postinst :P -- Charlie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Daniel Ostrow wrote the following on 03.10.2006 19:22 : Ok...lets try this... Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... It seemed to me that although it is hosted in the www.gentoo.org space the GWN isn't official Gentoo stuff. Plus : http://www.gentoo.org/news/en/gwn/20060424-newsletter.xml I can understand the problem with linking to the Wiki but I believe this source of information is not too bad, considered what google returns for gentoo cflags. It is inherently unreliable and outside of Gentoo's control. It will eat your dog, kill your cat, club baby seals and make the hole in the O-Zone layer bigger... I can add a reminder that this is unofficial stuff if it's important to devs, but as stated above I believed content in the GWN should be approved by the GWN people not devs (I remember there were discussions of making GWN official, but I believe it isn't yet). Feel free to sched more light on this for me. Lionel. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Charlie wrote: On 03/10/06, Daniel Ostrow [EMAIL PROTECTED] wrote: Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/xen/xen-3.0.2.ebuild?rev=1.6 See pkg_postinst :P That's a QA bug that needs to be filed... -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 03 Oct 2006 10:20:53 +0200 Luca Barbato [EMAIL PROTECTED] wrote: beside the syntax, as pointed by Donnie, it looks ok. I guess could be possible extract automagically from the current tree the data and create the datafile from it, isn't it? Yeah, it should be. I'm writing up a few scripts now to do that, along with one to let me file bugs with maintainers of packages that need porting (I won't run that one for a while still). -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Daniel Ostrow wrote: It is inherently unreliable and outside of Gentoo's control. Sorry, I really tried hard, but I just couldn't anymore... Must... say... __ _ _ _ _ _ / \ | | | | | | | | _ \ | __ ) / \ / ___|| | / _ \ | | | | | | | | |_) | | _ \ / _ \ \___ \| _| / ___ \| |___| |___ | |_| | _ | |_) / ___ \ ___) | |___ /_/ \_\_|_| \___/|_| \_\ |/_/ \_\/|_| _ _ _ _ ___ _ _ _ ___ / \ | _ \| | | __ )| | | / _ \| \ | |/ ___| |_ _/ _ \ / _ \ | |_) | _| | _ \| _| | | | | | | \| | | _| || | | | / ___ \| _ | |___ | |_) | |___| |__| |_| | |\ | |_| | | || |_| | /_/ \_\_| \_\_| |/|_|_\___/|_| \_|\| |_| \___/ _ _ | | | / ___| | | | \___ \ | |_| |___) | \___/|/ -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On Tue, 2006-10-03 at 19:49 +0200, Lionel Bouton wrote: It seemed to me that although it is hosted in the www.gentoo.org space the GWN isn't official Gentoo stuff. The GWN is staffed entirely by developers. We have non-developer writers, but the staffers are all developers. To be honest, rather than providing links to an external resource that may or may not be correct, and may be changed at any time by anyone, I would much prefer to duplicate the information in the GWN itself. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Chris Gianelloni wrote the following on 03.10.2006 22:46 : On Tue, 2006-10-03 at 19:49 +0200, Lionel Bouton wrote: It seemed to me that although it is hosted in the www.gentoo.org space the GWN isn't official Gentoo stuff. The GWN is staffed entirely by developers. We have non-developer writers, but the staffers are all developers. To be honest, rather than providing links to an external resource that may or may not be correct, and may be changed at any time by anyone, I would much prefer to duplicate the information in the GWN itself. Thats fine with me. It may be a bit too long as is so I'll update my draft trying to make things short and let you point out errors in the result (this was the main idea of bringing the draft on this list: use the devs' experience to bring new content and filter out errors). Thanks for the heads up. Lionel PS: I was worried that GuideXML might be a little unreadable, but apparently everyone here has an xsltproc ready to run in their brain :-) so I'll go on with it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Ciaran McCreesh wrote the following on 03.10.2006 14:26 : On Tue, 03 Oct 2006 02:56:42 +0200 Lionel Bouton [EMAIL PROTECTED] wrote: | Being able to tune the CFLAGS is part of one of the core principles of | Gentoo: let the user be in control. What? No it isn't. Maybe it depends on what you mean by 'in control'. What I mean is that you have a good stable base from which to work on, but nothing prevents you to tweak things like you want: Gentoo doesn't get in your way. http://www.gentoo.org/main/en/about.xml mentions Extreme Configurabiliy and the main picture states Larry the Cow was in control. And he liked it.. | linss_ldap stopped working with c-ffast-math/c (reported to | break many packages changing with the actual gcc version)/li Uh, -ffast-math has never been and will never be a safe thing to stick in CFLAGS. I agree (how could I say otherwise after spending several days with a hole in my foot finally finding that I had a gun named fast-math in my hand :-) ). Apparently many developpers think that it might be in CFLAGS though (see the amount of 'filter-flags -ffast-math' in ebuilds) so a reminder might not be wasted for some users. | Users with unsupported CFLAGS (see the uri | link='http://gentoo-wiki.com/CFLAGS_matrix'CFLAGS matrix/uri for | example) might want to return to safe CFLAGS (see uri | link='http://gentoo-wiki.com/Safe_Cflags'Safe CFLAGS/uri) if recent | updates caused them stability problems. On the other hand, more | adventurous users might want to experiment with CFLAGS that didn't | work properly with gcc-3.4.6... As always, the user is in control. Linking to that is a very bad idea. The wiki is in control of the minority ricer fringe. Ok. Anyway I'm now convinced that a dev-proofed version of its content in the GWN would be far better. GWN shouldn't be advocating this kind of thing at all. Here's a better paragraph: pWe would like to remind you that using anything beyond -O2 -fomit-frame-pointer -march/-mcpu/-mtune in CFLAGS or CXXLFAGS (and -mieee, -mabi etc on selected archs that tell you to do this), and using anything at all in LDFLAGS or ASFLAGS, is pointless and will lead to a broken system. Your penis length is not proportional to the size of your CFLAGS./p Hum, I'll leave out the last sentence or rephrase it... I'd prefer to be more soft-spoken: pointless might be a little too much too. Let's say that the cost-risk/benefit ratio is not worth it for the vast majority of users. CFLAGS tuning should probably only be used by people with very specific needs (gcc devs/testers, HPTC people with extensive knowledge/experience of the problems involved). For LDFLAGS and ASFLAGS I'll take your word for it (I never even tried modifying them myself). Lionel. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] CFLAGS paragraph for the GWN, 3rd version
Here's the third version of the draft, wiki-free and with less sugar too. More warnings. Thanks again for the input. --- Draft BEGIN --- section titleCFLAGS/title body p Being able to tune the CFLAGS is part of one of the core principles of Gentoo: let the user be in control. Being in control brings both benefits and problems. CFLAGS tuning is not an exception. /p warn We would like to remind you that using anything beyond -O2 -fomit-frame-pointer -march/-mcpu/-mtune in CFLAGS or CXXFLAGS (and -mieee, -mabi etc. on selected archs that tell you to do this), and using anything at all in LDFLAGS or ASFLAGS, is usually not worth it for most users. There's usually very little benefit, high risks and much time spent on frustating tuning that could be enjoyed doing far more interesting things. /warn p The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the CFLAGS landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. /p pExample of this are :/p ul linss_ldap stopped working with c-ffast-math/c (reported to break many packages changing with the actual gcc version)/li lic-fvisibility-inlines-hidden/c still breaks some code/li liif you used gcc-4.0, c-ftree-loop-linear/c now breaks in gcc-4.1 (at least with mesa)/li liagain for gcc-4.0 users, c-ftree-vectorize/c is known to be broken in gcc-4.1 (at least for x86 and ppc, amd64 users seem to be safe)/li lic-fforce-addr/c and c-fweb/c break regularly on x86 with video libraries or graphic processing apps which use hand-optimised ASM/li /ul pThere are known-to-be-broken flags for all GCC versions that you want to check for too:/p ul li-fvisibility=hidden/li li-frename-registers/li li-ftracer/li li-D_FILE_OFFSET_BITS=64/li li-msse -mmmx -m3dnow/li li-W/li li-mfpmath=sse,387/li li-malign-double/li /ul p Users with unsupported CFLAGS might want to return to safe CFLAGS (see warning above) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control (and the gun pointed to their feet is in his/her hand). /p pFinal notes:/p ul liThe gcc man page contains warnings for some unsafe optimization options. You should read it carefully when you experiment with CFLAGS or upgrade GCC on a CFLAGS-customized Gentoo./li liSome options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developper deems them safe (by redefining CFLAGS or using append-flags of the flag-o-matic eclass). For example c-ffast-math/c is added by the xmame/xmess ebuilds on most architectures even if you don't put it in your CFLAGS./li liYou might get an idea of the stability issues of a specific optimization option by running: cfind /usr/portage -name '*.ebuild'| xargs grep -- '-your-risky-optimization-option'/c. It takes quite some time, but might be enlightening: look for the 'filter-flags'./li /ul /body /section --- Draft END --- Lionel -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Linking to Gentoo-wiki from www.gentoo.org
Daniel Ostrow wrote: Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... Really? http://www.gentoo.org/news/en/gwn/20060424-newsletter.xml http://www.gentoo.org/proj/en/overlays/devguide.xml#doc_chap3 http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=1chap=6#doc_chap2 (Yes, it's only a draft, but it still meets your criteria) Mind you, I'm not saying that I agree with linking to Gentoo-wiki - I just think it's important to point out that your statement is incorrect. Cheers Andrew signature.asc Description: OpenPGP digital signature
[gentoo-dev] Linking to Gentoo-wiki from www.gentoo.org
Daniel Ostrow wrote: Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... Really? http://www.gentoo.org/news/en/gwn/20060424-newsletter.xml http://www.gentoo.org/proj/en/overlays/devguide.xml#doc_chap3 http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=1chap=6#doc_chap2 (Yes, it's only a draft, but it still meets your criteria) Mind you, I'm not saying that I agree with linking to Gentoo-wiki - I just think it's important to point out that your statement is incorrect. Cheers Andrew signature.asc Description: OpenPGP digital signature
[gentoo-dev] new eclass: java-gnome.eclass
To facilitate the maintenance of the java-gnome packages (ie libgtk-java, libgnome-java, and company), I've created a new eclass. There are currently seven packages which would be able to use this, and the number is expected to increase as the java-gnome project adds more bindings. The initial motivation for this came when I was cleaning up and migrating these packages to the new Java eclasses. As I was going along, I kept changing my mind about how to best package them... and each time I did, I would have to update 7 ebuilds. It got silly after awhile, so I sat down to make an eclass in order to make it trivial to maintain the actual packages with all the heavy lifting in the eclass. The eclass can be seen at: https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/eclass/java-gnome.eclass A package using it: https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/libgtk-java/libgtk-java-2.8.7.ebuild I would like to add this to the tree this weekend, and consequently bump java-gnome up to 2.14.3 which was released recently. -- Joshua Nichols Gentoo/Java Project Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Linking to Gentoo-wiki from www.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Ross wrote: Daniel Ostrow wrote: Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... Really? http://www.gentoo.org/news/en/gwn/20060424-newsletter.xml http://www.gentoo.org/proj/en/overlays/devguide.xml#doc_chap3 http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=1chap=6#doc_chap2 (Yes, it's only a draft, but it still meets your criteria) Mind you, I'm not saying that I agree with linking to Gentoo-wiki - I just think it's important to point out that your statement is incorrect. Cheers Andrew That draft is invalid -- it was an old project by SwifT; he was doing a trial rewrite of the entire handbook quite some time ago just to make it more generic, less Gentoo-centric. So it's no good; mentioning that draft is a red herring. And /proj/en/ is up to the individual projects; /proj/ docs have nothing to do with /doc/, which is where the primary official Gentoo documents reside. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIyHsrsJQqN81j74RAvFjAKC7hHHlSTV4r97NvWXhhksweIhAxwCeO0iP locLB5Gg2fhYlGQGvIWXuAs= =2Thv -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Linking to Gentoo-wiki from www.gentoo.org
Josh Saddler wrote: And /proj/en/ is up to the individual projects; /proj/ docs have nothing to do with /doc/, which is where the primary official Gentoo documents reside. Daniel Ostrow wrote: or anything else within the www.gentoo.org namespace... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 3 Oct 2006 00:44:57 -0400 Mike Kelly [EMAIL PROTECTED] wrote: On Mon, 02 Oct 2006 21:28:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: I'd prefer that the format be key=value for easier use by bash, as pretty much everything else in profiles is bash. Only issue I can think of is that we'd have to be sure to pick key names that don't conflict with bash variables like UID and SHELL, which shouldn't really be that hard, so I'm sure there had to be some stronger reason to not make it shell variables... I'll dig through logs and try to figure out what it was. Well, I couldn't find anything in my IRC logs, all I could find is that I switched away from using the key=value stuff at r10 in my svn repo, on 5 July (it's now at r213). No one else I talked to remembered why the switch was done in the first place, so I'm just going to change the format back to key=value, like bash variables. Unlike most other variables in profiles, though, I am keeping these with all lowercase variable names, e.g. uid=5. I'll update the documentation in my dev space tomorrow. -- Mike Kelly signature.asc Description: PGP signature
