Re: [gentoo-dev] Need guidance for updating CHOST
On Tue, Sep 12, 2006 at 07:40:01PM -0700, Richard Fish wrote: Is there a Readers Digest version you can give the userreps so we can at least answer the question properly when it comes up? The current version is text only and ugly, but at least there is one and from the feedback i got so far it works quite well. http://dev.gentoo.org/~amne/temp/change-chost.txt I intend to xmlify this and give it to the docs people, if someone wants to volunteer for that job let me know. Otherwise i hopefully get to it myself soon. For questions about the howto or feedback this thread on the forums (http://forums.gentoo.org/viewtopic-t-494147.html) would be best, or just drop me an email. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpMacViL8V4Y.pgp Description: PGP signature
Re: [gentoo-dev] Toys for arch / release people
Ciaran McCreesh wrote: [...] I remain, Sirs, your most humble and obedient servant, ^^^ LOL -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Council] #gentoo-council
Just a short note: The new council will be showing more presence in #gentoo-council. This means: even when no meeting is taking place you can reach us all together on IRC to discuss Gentoo development or to point out problems. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] using -j1 with distcc?
From bind-9.3.2-r4.ebuild:
# idea from dev-libs/cyrus-sasl
if has distcc ${FEATURES}; then
einfo You have \distcc\ enabled
einfo build with MAKEOPTS=\-j1\
jobs=-j1
else
einfo build with MAKEOPTS=${MAKEOPTS}
jobs=
fi
emake ${jobs} || die failed to compile bind
I think this is bogus. If building with distcc reveals a parallel
build issue, then the issue exists with or without distcc, it just
seems to happen less often without it. We've been down this road
before, maybe people have forgotten?
bind-9.3.2-r4.ebuild failed to build for me on dual ia64. Building
with -j1 works.
Unless somebody can explain how this is valid, I'll go ahead and fix
the bind ebuilds (where fix means use -j1 unconditionally since the
Makefiles aren't parallel safe).
Aron
pgp0AJ5e1FDg4.pgp
Description: PGP signature
Re: [gentoo-dev] using -j1 with distcc?
On Wed, Sep 13, 2006 at 10:34:52AM -0400, Aron Griffis wrote:
From bind-9.3.2-r4.ebuild:
# idea from dev-libs/cyrus-sasl
if has distcc ${FEATURES}; then
einfo You have \distcc\ enabled
einfo build with MAKEOPTS=\-j1\
jobs=-j1
else
einfo build with MAKEOPTS=${MAKEOPTS}
jobs=
fi
emake ${jobs} || die failed to compile bind
I think this is bogus. If building with distcc reveals a parallel
build issue, then the issue exists with or without distcc, it just
seems to happen less often without it. We've been down this road
before, maybe people have forgotten?
bind-9.3.2-r4.ebuild failed to build for me on dual ia64. Building
with -j1 works.
Unless somebody can explain how this is valid, I'll go ahead and fix
the bind ebuilds (where fix means use -j1 unconditionally since the
Makefiles aren't parallel safe).
Similar trickery in app-office/openoffice, although they enable -jN if
distcc is enabled, else -j1 ...
Always wondered how that was valid, just avoid OO compiles enough it
wasn't something I ever got around to looking into :)
~harring
pgpRjBbqszVRI.pgp
Description: PGP signature
Re: [gentoo-dev] AutoMake and paralle safe makefiles [WAS: using -j1 with distcc?]
Aron Griffis wrote: From bind-9.3.2-r4.ebuild: Unless somebody can explain how this is valid, I'll go ahead and fix the bind ebuilds (where fix means use -j1 unconditionally since the Makefiles aren't parallel safe). Aron If I'm using Autotools, aren't they smart enough (given that I specify the proper headers, and source files and whatnot) to generate parallel safe makefiles? Or is it a shot in the dark as to whether it works or not? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] AutoMake and paralle safe makefiles [WAS: using -j1 with distcc?]
On Wednesday 13 September 2006 16:51, Alec Warner wrote: If I'm using Autotools, aren't they smart enough (given that I specify the proper headers, and source files and whatnot) to generate parallel safe makefiles? Or is it a shot in the dark as to whether it works or not? If you use automake, 90% they are parallel make safe. There are issues in cases a) you refer to a library in the same directory as the Makefile providing the full pathname; b) you don't put the SUBDIRS variable in the correct order for things to being built; c) you provide custom targets for instance to run scripts that create source files. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpAbErQnrwoD.pgp Description: PGP signature
Re: [gentoo-dev] AutoMake and paralle safe makefiles [WAS: using -j1 with distcc?]
On Wed, 13 Sep 2006 10:51:47 -0400 Alec Warner [EMAIL PROTECTED] wrote: | Aron Griffis wrote: | From bind-9.3.2-r4.ebuild: | | Unless somebody can explain how this is valid, I'll go ahead and fix | the bind ebuilds (where fix means use -j1 unconditionally since | the Makefiles aren't parallel safe). | | If I'm using Autotools, aren't they smart enough (given that I | specify the proper headers, and source files and whatnot) to generate | parallel safe makefiles? Or is it a shot in the dark as to whether | it works or not? You can quite easily screw up Makefile.am and generate unsafe code when using automake. It doesn't remove the need to know what you're doing. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] using -j1 with distcc?
On Wed, 2006-09-13 at 07:52 -0700, Brian Harring wrote:
On Wed, Sep 13, 2006 at 10:34:52AM -0400, Aron Griffis wrote:
From bind-9.3.2-r4.ebuild:
# idea from dev-libs/cyrus-sasl
if has distcc ${FEATURES}; then
einfo You have \distcc\ enabled
einfo build with MAKEOPTS=\-j1\
jobs=-j1
else
einfo build with MAKEOPTS=${MAKEOPTS}
jobs=
fi
emake ${jobs} || die failed to compile bind
I think this is bogus. If building with distcc reveals a parallel
build issue, then the issue exists with or without distcc, it just
seems to happen less often without it. We've been down this road
before, maybe people have forgotten?
bind-9.3.2-r4.ebuild failed to build for me on dual ia64. Building
with -j1 works.
Unless somebody can explain how this is valid, I'll go ahead and fix
the bind ebuilds (where fix means use -j1 unconditionally since the
Makefiles aren't parallel safe).
Similar trickery in app-office/openoffice, although they enable -jN if
distcc is enabled, else -j1 ...
Always wondered how that was valid, just avoid OO compiles enough it
wasn't something I ever got around to looking into :)
~harring
I don't see how it can be valid, especially ferringb's example.
Enabling distcc doesn't mean the build will distribute; only that the
possibility is there. If you happen to build when the other system(s)
is(are) unavailable for some reason, you get everything on the host, so
for ferringb, e.g., this would mean -jN on one system.
As for Aron's case, I agree with him.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Devrel, Sparc)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] using -j1 with distcc?
Brian Harring wrote: [Wed Sep 13 2006, 10:52:17AM EDT] Similar trickery in app-office/openoffice, although they enable -jN if distcc is enabled, else -j1 ... Always wondered how that was valid, just avoid OO compiles enough it wasn't something I ever got around to looking into :) The openoffice ebuild is okay. It disables parallel builds by default, since openoffice isn't parallel safe. But the ebuild provides a sekrit variable WANT_DISTCC that can be set to use -j* from MAKEOPTS. In this case WANT_DISTCC is a misnomer but the technique isn't actually bad. Aron pgp9u1W5PkBKJ.pgp Description: PGP signature
Re: [gentoo-dev] using -j1 with distcc?
Aron Griffis wrote: [Wed Sep 13 2006, 10:34:52AM EDT] Unless somebody can explain how this is valid, I'll go ahead and fix the bind ebuilds (where fix means use -j1 unconditionally since the Makefiles aren't parallel safe). Maybe this was quick on my part, but I've gone ahead and fixed the ebuilds. They can always be fixed back if I'm wrong, but I'm pretty certain... Regards, Aron pgpY8wazrX7sn.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. I would much prefer new files to be treated as if replacing an existing zero length file. When something is installed into /etc, etc-update should alert me to this, because logically speaking a new configuration file is a big configuration change. Ideally the package manager would unconditionally respect the config protection area, and it should be up to tools like etc-update to (configurably) automerge new files and identical files, just like it can be configured to automerge trivial/comment changes. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Council] #gentoo-council
Danny van Dyk wrote: Just a short note: The new council will be showing more presence in #gentoo-council. This means: even when no meeting is taking place you can reach us all together on IRC to discuss Gentoo development or to point out problems. Great! It's good to hear this. But how about the possibility of getting decisions outside of the official, once a month meeting time with 2 weeks advance notice? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Council] #gentoo-council
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Danny van Dyk wrote: Just a short note: The new council will be showing more presence in #gentoo-council. This means: even when no meeting is taking place you can reach us all together on IRC to discuss Gentoo development or to point out problems. Great! It's good to hear this. But how about the possibility of getting decisions outside of the official, once a month meeting time with 2 weeks advance notice? Thanks, Donnie I was thinking about bringing that up tomorrow. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRQhJPYBrouQZ9K4FAQLBfAP/dABSPzijT3HZmVB7qwZzMAB02pVehjM/ ISuVeO0T7ED16ijJT8NXi2yOloW9ke4lfSkLvhB+PPSA8p6Q1mf47XWqXuZiDtdY ZlleHYcBELJUR6bUncvlpLCFg3m2MEgW+aj742z9JbC1gwPRqhSCQhuBVziBm9bw wA/LXL8S2cI= =Damk -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Council] #gentoo-council
On Wed, 2006-09-13 at 13:09 -0500, Mike Doty wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Danny van Dyk wrote: Just a short note: The new council will be showing more presence in #gentoo-council. This means: even when no meeting is taking place you can reach us all together on IRC to discuss Gentoo development or to point out problems. Great! It's good to hear this. But how about the possibility of getting decisions outside of the official, once a month meeting time with 2 weeks advance notice? Thanks, Donnie I was thinking about bringing that up tomorrow. Well, it isn't on the agenda, so we won't be able... oh wait... *grin* I see no problem with this. I was planning on writing up something a bit more formal for this, just so we could fit it into the current discuss on -dev, then add to agenda way of doing things, to cross all the t and dot all the i so to speak. -- 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] RFC: Package Manager Specification: configuration protection
On 2006-09-11 at 20:30 -0400, Michael Cummings wrote: Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. Just one poor dev's opinion, but I prefer it when these files are created as .sample's or examples. .sample or .example files are not related with configuration protection and as it was already decided on such files should go into /usr/share/doc. Invariably there is some tweaking that needs to be done to the file, even when it's the initial version of the file. And this breaks General guidelines in gentoo developer handbook: Your package, when complete and unmasked, is supposed to just work for the end-user. Tweaking the installed product to get it to work should be optional; thus you need to install the package with reasonable default settings. Regards, Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Wed, 2006-09-13 at 19:47 +0200, Benno Schulenberg wrote: Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. I would much prefer new files to be treated as if replacing an existing zero length file. When something is installed into /etc, etc-update should alert me to this, because logically speaking a new configuration file is a big configuration change. Ideally the package manager would unconditionally respect the config protection area, and it should be up to tools like etc-update to (configurably) automerge new files and identical files, just like it can be configured to automerge trivial/comment changes. I disagree. If there is a sane default configuration for something (which is most things), I want it installed, so it works out of the box. I don't want to have to fiddle with config files to get sshd up and running. Obviously, if there's no sane default configuration (samba?), then the installed configuration shouldn't do anything. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] using -j1 with distcc?
On Wednesday 13 September 2006 19:30, Aron Griffis wrote: Aron Griffis wrote: [Wed Sep 13 2006, 10:34:52AM EDT] Unless somebody can explain how this is valid, I'll go ahead and fix the bind ebuilds (where fix means use -j1 unconditionally since the Makefiles aren't parallel safe). Maybe this was quick on my part, but I've gone ahead and fixed the ebuilds. They can always be fixed back if I'm wrong, but I'm pretty certain... thanks. -- voxus :wq pgpblvdZv5Vrw.pgp Description: PGP signature
[gentoo-dev] Sunrise trusted committers with bugzilla access
To my fellow Gentoo developers, in the Sunrise project we have some users who are ambitious and cotribute more than a few ebuilds. Those regulars have the possibility to take the ebuild quiz and acquire the title Sunrise trusted committer. Those sunrise committers can use extended bugzilla permissions to edit keywords EBUILD and REQUEST for example in the maintainer-wanted@ and maintainer-needed@ bugzilla region where usually developers clean up litle or have no interest in spending time on. Now I tried to get this done with the [GLEP] Bugzilla access for contributors and I was told it is to undefined and misses out the point of removing access levels again. Also I was told that a GLEP for this is overkill. All this is addressed and working with the current arch testers procedure. The plan is to just treat Sunrise trusted committers the same as arch or herd testers. The difference is that they operate on ebuilds of all flavours that interest themself in the sunrise overlay and not on a certain herd of packages. Neither do they focus on testing for a specific architecture. Just coding is their work, not testing - which explains the difference in the name. Now how do people feel about this approach? -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] treecleaner: package.mask cleanup
I just removed these no longer valid entries from package.mask since the packages have been removed from the tree: =net-dns/dnsmasq-2.21 =app-editors/vim-core-7.0_alpha* =app-editors/vim-7.0_alpha* =app-editors/gvim-7.0_alpha* Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] colon separated variables in /etc/env.d/
On Sunday 10 September 2006 21:44, Zac Medico wrote: For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. /etc/env.d makes most sense ... we just have to worry about how to handle the chicken egg problem ... so if you have FOO=... in '10file' but COLON_SEPARATED=foo doesn't appear until '20file', what then ? -mike pgplwtvYbeuQZ.pgp Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Sunday 10 September 2006 21:44, Zac Medico wrote: For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. /etc/env.d makes most sense ... we just have to worry about how to handle the chicken egg problem ... so if you have FOO=... in '10file' but COLON_SEPARATED=foo doesn't appear until '20file', what then ? -mike It's alright, because the tool will make one pass over all the files in order to accumulate COLON_SEPARATED and SPACE_SEPARATED. After it has those values, it will make another pass to process the other variables (FOO, etc...). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFCMo8/ejvha5XGaMRAuvkAJ0YGD1kozu4hFXxdTbauI1koRM8TQCfdWNF nhueyuoinBXgVvw60FmOrso= =ZC/4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Toys for arch / release people
Ciaran McCreesh wrote: If anyone has any other suggestions for this kind of user configuration independent tool, give me a prod here or in #paludis. Writing these is really trivial and almost certainly worth the effort... I remain, Sirs, your most humble and obedient servant, Ciaran, Stop being nice and polite... It's freaking me out. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] planet gentoo upgrade
Planet Gentoo's backend got upgraded today, so if anyone notices any weird funkies, please let me know. Thanks for beta-testing. :) Steve -- gentoo-dev@gentoo.org mailing list
