Re: [gentoo-dev] per-package USE defaults
On Tue, 08 Aug 2006 12:18:10 -0700, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: Any chance of per-package USE defaults support? That's much more useful to me. Attached to bug 61732 there's a patch that implements this via a new IUSE_DEFAULTS ebuild variable. I see USE_ORDER becomes ...:pkg:conf:iuse_defaults:... in your patch. Have you considered using ...:pkg:iuse_defaults:conf:... instead? Imo, the feature would better this way, because: - one would still benefit of the package defaults when using a make.conf with USE=-* This would be a good thing especially when a +foo default has been used to replace an old IUSE=nofoo. - one would get the best flags everywhere when a global flag, for instance a library flag, which is good in general (and thus that people set in their make.conf) is just not the best alternative in the context of one particular package. And also, it just sounds more logical/intuitive to me that some per-package defaults are only overridable at a per-package level. Sure, this may also complicates life of a user who don't want libfoo at all, if the libfoo flag is set per-default in 20 packages he uses. But i would expect this won't happen; flags which are good defaults in general would rather stay in make.defaults i guess. -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On 8/9/06, Brian Harring [EMAIL PROTECTED] wrote: General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Is it really magic? Admittedly I know exactly nothing about portage internals, but it seems to me that use-specific restrictions and version-specific restrictions are two completely separate concepts, and that you have to deal with them separately, regardless of whether you put the directives all in the same file or not. I see the normal case for gcc being something like: sys-devel/gcc[-cxx] =sys-devel/gcc-5.0 The above is very clear and obvious to me...all versions of gcc should be built with USE=cxx, and you should not try = version 5.0. If you tried to combine those two concepts into a single directive, you would end up with: =sys-devel/gcc-5.0[-cxx] and I can think of at least 3 useful and logical interpretations of that single statement. This is quite different than the same token in an [R]DEPEND, where only one sane interpretation exists. So in fact I think that in the context of masking/unmasking packages, you must deal with the version and use flag masking separately. You should not even allow the combined syntax form, since it is so ambiguous. And if you do that, then the unmasking of use-specific or version-specific masks becomes quite obvious. Placing sys-devel/gcc[-cxx] in package.unmask has no effect on the _versions_ of gcc that are masked, as it isn't a version-specific directive. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
On Tuesday 08 August 2006 22:36, Enrico Weigelt wrote: As an end user and also an administrator, I am very pleased to see this laid out so clearly. I mean, I knew it, but it seems like it needs to be yelled once in a while... hmm, now that I know of these flags, I can take a look at them (although its not very comfortable having to look at those details). Yes, I could have read the whole docs to learn about this, but I never expected such things. IMHO many people may get into such pitfalls. You're probably one of the new users of the installer. I knew that we shouldn't do that. The whole point of gentoo having (a reputation of having) good documentation is because people need it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpseQ8PrKYKO.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
On Thu, 2006-08-10 at 14:24 +0200, Paul de Vrieze wrote: On Tuesday 08 August 2006 22:36, Enrico Weigelt wrote: As an end user and also an administrator, I am very pleased to see this laid out so clearly. I mean, I knew it, but it seems like it needs to be yelled once in a while... hmm, now that I know of these flags, I can take a look at them (although its not very comfortable having to look at those details). Yes, I could have read the whole docs to learn about this, but I never expected such things. IMHO many people may get into such pitfalls. You're probably one of the new users of the installer. I knew that we shouldn't do that. The whole point of gentoo having (a reputation of having) good documentation is because people need it. Alright, you seriously need to quit this sort of FUD. The Installer really doesn't make it that much easier to install, it simply makes it quicker. If you don't believe me, try following gli-bugs on bugzilla or hanging out in #gentoo-installer for a while. Trying to blame one user's refusal to read documentation on a project that you seem to know little about does nothing to serve Gentoo. -- 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] Council polls now open
Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. Incidentally, I'm currently serving as an election official since I'm not running for a spot on the Council. It would be good to have a couple other people acting as officials, too. Volunteers? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpfPnAu5SYqC.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 10:57 -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. Incidentally, I'm currently serving as an election official since I'm not running for a spot on the Council. It would be good to have a couple other people acting as officials, too. Volunteers? Sure, just let me know what you need me to do Grant :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Council polls now open
On Thu, 2006-10-08 at 10:57 -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. Incidentally, I'm currently serving as an election official since I'm not running for a spot on the Council. It would be good to have a couple other people acting as officials, too. Volunteers? I volunteer (again).. What's the status on the search for voting software ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
Olivier Crete wrote: It was chosen by brad_mssw to match the way it is done on ia64. And I think we should continue to put the binary app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be reserved for properly installed packages using portage whenever we manage to get portage to support it. It makes sense that you wouldn't want these binary packages going into /lib32 or /usr/lib32, but /emul seems like an odd choice compared to something like /opt/lib32. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council polls now open
Christel Doty wrote: [Thu Aug 10 2006, 12:34:50PM CDT] Sure, just let me know what you need me to do Grant :) Thanks! Um, I'm not quite sure what's going to be needed just yet, but I'll keep you informed. -g2boojum- PS. With three election officials, we probably have enough now. -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpa27hbJT3gJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Olivier Crete wrote: It was chosen by brad_mssw to match the way it is done on ia64. And I think we should continue to put the binary app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be reserved for properly installed packages using portage whenever we manage to get portage to support it. It makes sense that you wouldn't want these binary packages going into /lib32 or /usr/lib32, but /emul seems like an odd choice compared to something like /opt/lib32. Thanks, Donnie IIRC, /emul predates FHS acceptance. also, while they are binary packages, they arn't in the same catagory as binary-only packages. We distribute them to assist multilib and to overcome problems that portage wasn't really designed for. We're getting to the point where most emul stuff could be made obsolete. The amd64 team is having a meeting next week and I'll bring the point up. - -- === 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) iQCVAwUBRNtsMIBrouQZ9K4FAQKtnAP+KmCnEVjj8yeoscAXLZybg9oInK1+0eQy VDAVU7q0gVf+WxCpiiQ8t+uhPL0tV6EGnJAkCx09dDNM6C+aOJrW8a7KEiR9S6g5 SJWN4szCtaYNiPWzpvTvGwdHQ94jPvDDPq3tX4GQN22fF1fG2Xxz56cBmvx+pXIU 40RLYip7wNs= =Xpt4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council polls now open
Olivier Crete wrote: I volunteer (again).. What's the status on the search for voting software ? We follow two trails : fixing countify or find something else. I'll have a look at countify, but more monkey eyeballs can't hurt. We didn't find a good alternative yet, so you can also help in that area. -- Koon -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council polls now open
On Thu, Aug 10, 2006 at 10:57:14AM -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. What is the current election name that we should use when running votify? thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council polls now open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: On Thu, Aug 10, 2006 at 10:57:14AM -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. What is the current election name that we should use when running votify? thanks, greg k-h council2006 - -- === 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) iQCVAwUBRNtw5oBrouQZ9K4FAQITPwP/Zq+JrI1GTIiZsscSheAai8WJ9YZUCubi FbC8KWL9/P/M0p8FdtdcPB74chOSt8bwtJel+EXRoi8QD1XCeO7LcA1tmpqsWT9v JXIiW58iX+e3VtYwYDKCZesa9Qaqy5uatGdZpqL9e9TEVqXvruukpyxqOQTcozV7 5FW6HdKMp70= =oPWB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
Hi everybody, I propose the `emerge --info` included in arch testers' comments on stabilisation bugs should rather be posted as attachments. The AT comments clog up the bugs and are usually not interesting at all to devs other than those who are arch devs for the relevant arches. It would certainly improve my RSI not to have to scroll past them. On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some =foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council polls now open
On Thursday 10 August 2006 21:42, Greg KH wrote: On Thu, Aug 10, 2006 at 10:57:14AM -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. What is the current election name that we should use when running votify? council2006 -- voxus :wq pgpq6Q4iFamVG.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
Olivier Crete wrote: [Thu Aug 10 2006, 11:42:14AM CDT] On Thu, 2006-10-08 at 10:57 -0500, Grant Goodyear wrote: I volunteer (again).. What's the status on the search for voting software ? Well, fmccor has suggested STV[1], so the current plan is to use countify to assemble the usual master ballot, and then write some sort of glue script that will take the master ballot and transform it into whatever STV needs. Of course, the glue bit still needs to be written. [1] http://stv.sourceforge.net/ Thanks! -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpFfOf1MT6mA.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
On Thu, 10 Aug 2006 10:42:47 -0700 Greg KH [EMAIL PROTECTED] wrote: What is the current election name that we should use when running votify? To vote, log into dev.g.o and type votify --help for instructions. Doing that explained everything. :) Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 19:50:55 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: I propose the `emerge --info` included in arch testers' comments on stabilisation bugs should rather be posted as attachments. The AT comments clog up the bugs and are usually not interesting at all to devs other than those who are arch devs for the relevant arches. It would certainly improve my RSI not to have to scroll past them. Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some =foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. I totally agree. An AT or arch team member should know which category, package, and version to test from the bug summary alone. -Thomas pgp53iXA6klQv.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
Greg KH wrote: [Thu Aug 10 2006, 12:42:47PM CDT] On Thu, Aug 10, 2006 at 10:57:14AM -0500, Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. What is the current election name that we should use when running votify? council2006 For those who are likely to forget, votify --help will actually tell you the names of the elections that are currently open (although that information shows up above the Instructions, making it easy to skip over). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp1OXGv5L5j5.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
On Thu, Aug 10, 2006 at 08:00:25PM +0200, Jeroen Roovers wrote: On Thu, 10 Aug 2006 10:42:47 -0700 Greg KH [EMAIL PROTECTED] wrote: What is the current election name that we should use when running votify? To vote, log into dev.g.o and type votify --help for instructions. Doing that explained everything. :) Well, the name scrolled off the top of the screen, sorry for being dense this early in the morning :) greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Thu, 10 Aug 2006 12:26:10 -0500
Mike Doty [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
Olivier Crete wrote:
It was chosen by brad_mssw to match the way it is done on ia64.
And I think we should continue to put the binary
app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be
reserved for properly installed packages using portage whenever we
manage to get portage to support it.
It makes sense that you wouldn't want these binary packages going
into /lib32 or /usr/lib32, but /emul seems like an odd choice
compared to something like /opt/lib32.
I though exactly this when I saw SpanKY's query. Having a directory in
'/' is not pretty.
IIRC, /emul predates FHS acceptance. also, while they are binary
packages, they arn't in the same catagory as binary-only packages. We
distribute them to assist multilib and to overcome problems that
portage wasn't really designed for.
More generally we have varying approaches to pre-built packages;
app-office/openoffice-bin installs to /usr for example, while
mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
install to /opt.
In these cases, where they are installed on the same target
architecture as they were built, I think it makes sense to have them
install as if they were built with 'emerge -B' for installation via
'emerge -K' - i.e. in /usr rather than /opt.
x86-built binary packages for x86_64 are not the same, of course. One
idea that springs to mind immediately is to put them in a
{bin,include,lib...} hierarchy under /usr/ctarget (which is also
where the compiler stuff for ctarget ends up). Conceptually at least
(although no doubt problematic in practice) on x86_64 one could use a
x86(_32) cross-compiler to build stuff to ROOT=/usr/${CTARGET}. Again
in concept a /${CTARGET}/{bin,include,lib...} would exists for
essential boot stuff, althought that's a bit academic.
Just a thought for the pot ;)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 21:49 +0200, Danny van Dyk wrote: Am Donnerstag, 10. August 2006 18:51 schrieb Grant Goodyear: Olivier Crete wrote: [Thu Aug 10 2006, 11:42:14AM CDT] On Thu, 2006-10-08 at 10:57 -0500, Grant Goodyear wrote: I volunteer (again).. What's the status on the search for voting software ? Well, fmccor has suggested STV[1], so the current plan is to use countify to assemble the usual master ballot, and then write some sort of glue script that will take the master ballot and transform it into whatever STV needs. Of course, the glue bit still needs to be written. Hm, i see a problem here. IIRC STV expects one line of input per ballot, which lists all candidates sperated by spaces. Now, per votifiy, developers can put more than one developer per line, if they deem them to be equally competent. Isn't that incompatible behaviour? Yes, but if we use STV (and there are issues with it if Condorcet is a requirement, because Condorcet is really designed to pick one winner, and it takes some extra work to get a ranking), I have a tiny ruby script which can take any number of raw ballots and convert them into one (internal form) STV .blt file. (The equally competent part might be another problem with STV, but I have to go back and look at it carefully to verify that.) So the glue is rather easy; problem is the specific balloting method. STV supports several protocols for selecting some number of winners from a list of candidates, but Condorcet is not among them, because Condorcet is really a pick single winner method. (By the way, if the ballots from council2005 are still around, and if someone can make them anonymous (convert names to something like C1, C2, etc.), I can take them and show what results STV would give, if you'd like a controlled test.) Anyone having better information than I have, please correct my mistakes here. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project 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] Council polls now open
On Thu, 10 Aug 2006 20:03:26 + Ferris McCormick [EMAIL PROTECTED] wrote: | So the glue is rather easy; problem is the specific balloting | method. STV supports several protocols for selecting some number of | winners from a list of candidates, but Condorcet is not among them, | because Condorcet is really a pick single winner method. All you need to do is delete the single winner from the election and repeat the process. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Thursday 10 August 2006 15:42, Kevin F. Quinn wrote: On Thu, 10 Aug 2006 12:26:10 -0500 Mike Doty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Olivier Crete wrote: It makes sense that you wouldn't want these binary packages going into /lib32 or /usr/lib32, but /emul seems like an odd choice compared to something like /opt/lib32. I though exactly this when I saw SpanKY's query. Having a directory in '/' is not pretty. it doesnt matter whether it's in /emul or /opt or /fooie, if it isnt in the system lib32 paths, it's going to be a pita using the system lib32 paths allows the compiler/linker/loader to automatically locate the libraries More generally we have varying approaches to pre-built packages; app-office/openoffice-bin installs to /usr for example, while mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin install to /opt. which is broken ... OOo-bin should be in /opt ... -mike pgpoGtrgJGite.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 21:11 +0100, Ciaran McCreesh wrote: On Thu, 10 Aug 2006 20:03:26 + Ferris McCormick [EMAIL PROTECTED] wrote: | So the glue is rather easy; problem is the specific balloting | method. STV supports several protocols for selecting some number of | winners from a list of candidates, but Condorcet is not among them, | because Condorcet is really a pick single winner method. All you need to do is delete the single winner from the election and repeat the process. True. I was hoping no one would notice, however, because that gets tedious (although once you have the ballots, it can be automated to a large extent). At some point, we should re-examine policy and run some controls to see if a voting method more closely designed for what we are actually doing might be more appropriate. In the middle of a voting cycle is probably not the right time for that, though, no matter what makes things easiest for me. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk Thanks, I guess :), 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] Council polls now open
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Grant Goodyear wrote: Well, we don't yet have reliable software in place to _count_ votes, but that's no reason not to start collecting them. The polls are now open, and will remain so until UTC 20060911 (one month). To vote, log into dev.g.o and type votify --help for instructions. If you run into any problems, please let me know. All current devs are eligible to vote. **All current devs are eligible to vote.** This includes Staff as well. Staff is anyone with an @gentoo.org address who doesn't have commit access to the ebuild tree. People like Forums, Bug Wranglers, Infra, Devrel, Userrel, etc... - --Curtis ps. thanks for getting the election process going and staying on top of it Grant. We all appreciate it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRNubFUb8Q0uRCeTQAQFEawgAyWxt750f0OX3TV5yWxcLJBU6gAq36SSL SwIB/eJpQZLqpwB4XQ3NhWIxfULX9FhIRKbqbXP3t+Gn/1BjoGaEic7RM7VybWAs 9pRoXzLPUpHVkPRgJ3WZTrl1MHna6wNU/NrCJWLDlcOFzSsaQrffJWAyInU9wsIC 8fFxg8R6mJ6r2iyRggTQ+rpHDSMXdEeMy/SqNm2VptTti/vuXj60bpiwQsFtWQQM s7pqW9Jtay6RpBJta3x1LtIaoI1SAZ0MPuvyOQDsJulJ5MbrsnV/Q0LAXgGWXa1x SFJvAdTEg+z7ueMTwgEkWxjOOXQcWhUN5LnC1q30wjutdpFAZbb3/w== =TtvN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 14:44:13 -0400 Thomas Cort [EMAIL PROTECTED] wrote: On Thu, 10 Aug 2006 19:50:55 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: I propose the `emerge --info` included in arch testers' comments on stabilisation bugs should rather be posted as attachments. The AT comments clog up the bugs and are usually not interesting at all to devs other than those who are arch devs for the relevant arches. The problem with attachments is that processing the report takes longer - you have to go to the web to read the attachment to find out what config worked (or failed, if that was the case). It's best to have it in-line, I think. If you're not interested in the AT emerge --info data, why are you watching the stabilisation bug? It would certainly improve my RSI not to have to scroll past them. Why do arch testers need to post `emerge --info` if everything works? So that you know what configuration worked. This is useful information. Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
Thomas Cort [EMAIL PROTECTED] wrote: Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpVGA6cHb38q.pgp Description: PGP signature
Re: [gentoo-dev] Who wants to tinker with a Palm Zire 71?
Steev Klimaszewski wrote: Noack, Sebastian wrote: Hi, I have a Palm Zire 71 device, with Palm OS on it and a 400 MHz ARM-Processor in it. Actually I don't use this device anymore, so if somebody wants try to get Gentoo Linux run on it, I would give it to him. There is an SD/MMC-Slot which could become used to get data on the devie an there is also an IR interface and a USB-Adapter. But the biggest problem I see is that the OS is on a ROM, but maybe there would be a way to manipulate the BIOS if it has one, to boot from somewhere on the RAM. In any case I guess it would require to maipulate the hardware. If somebody here have the skills and motivation to try that, he or she should tell me and I will send him or her my device. Best Regards Sebastian Noack I'd love to - if anyone else hasn't already claimed it :) I'll take his sloopy seconds, I've had enough of my original palm zire one that only has 2mb ram.. I think i might just be able to pull it off too :-D Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 23:58:46 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. I get that posting `emerge --info` provides a known good set of CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at times. However, we don't require that developers post their emerge --info when a package works, so why do we require that ATs do it? -Thomas pgpdK7lzralER.pgp Description: PGP signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Thu, 2006-08-10 at 12:26 -0500, Mike Doty wrote: We're getting to the point where most emul stuff could be made obsolete. The amd64 team is having a meeting next week and I'll bring the point up. Just don't screw over games in the process. ;] -- 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: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 23:58:46 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: The problem with attachments is that processing the report takes longer - you have to go to the web to read the attachment to find out what config worked (or failed, if that was the case). It's best to have it in-line, I think. The problem with inlining is that processing the info takes longer - you have to wade through all the AT spam to find out what is being changed over time. It's best to have it in attachments, I think. Besides, you're wrong. ATs can add comments to attachments informing their arch devs of success or failure, and name the `emerge info` attachment properly so everybody knows what the attachment actually is (and when to ignore it). If you're not interested in the AT emerge --info data, why are you watching the stabilisation bug? Because as an arch dev not on an AT-equipped arch, I still need to find the interesting-not-your-arch-info between all the your-arch-cruft. All these `emerge info` comments are completely irrelevant to every arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' preparations have their work cut out for them, it seems, having all that info in their mailbox, while non-AT arches have to fork through all the spam, both in their mailboxes and on bugs.g.o, to get to the good bits (ouch, sparc beat us again, must stabilise before mips!). Inlining emerge info in comments bloats the e-mail message to roughly 2.5 times the normal size. I could have spoken out to get AT comments banned altogether or to urge arches with AT teams to find a proper technical solution to communicate outside of bugs.g.o. I think using attachments instead of inlining is a pretty good temporary solution to a communication problem that has for now been solved by making every stabilisation bug report a dumping ground for a ton of information that becomes obsolete within a few days. Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 2006-08-10 at 18:29 -0400, Thomas Cort wrote: On Thu, 10 Aug 2006 23:58:46 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. I get that posting `emerge --info` provides a known good set of CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at times. However, we don't require that developers post their emerge --info when a package works, so why do we require that ATs do it? Honestly, it might be sufficient to only post 'emerge --info' when it *doesn't* work. If we need corroboration from someone where it did work, we can ask. -- 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: AT emerge info cruft attachments on bugs.g.o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Aug 2006, Matti Bickel wrote: Thomas Cort [EMAIL PROTECTED] wrote: Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Unless this causes problems for people, I'd like to be able to find it. As you see from my signature, I'm extrapolating from sparc here, but on sparc, at least, the specs and configuration of a failing system (or of a system which cannot be made to fail) is sometimes highly relevant. Having this sort of information can't hurt and might help, so I'd ask please provide it someplace if convenient. Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. Yes. Well, if you say everything is good, I just don't read it. I sometimes compromise on bugs and give a two or three line indication of just which system(s) I am reporting on. If people want more information, they can ask me or go to a summary page sparc maintains --- all my systems are described there. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFE28DyQa6M3+I///cRAqWRAKCSzbmYM8G16DzXuqdUHbYgVnivsQCgyVqS mO5HEmm6oc3yrqfX0IfrMug= =T6kP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
Mike Frysinger wrote: On Thursday 10 August 2006 12:48, Olivier Crete wrote: And I think we should continue to put the binary app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be reserved for properly installed packages using portage whenever we manage to get portage to support it. either you use the prebuilt binaries or you dont keeping these things in /emul just bloats the default amd64 system and makes typical use a pita (adding -L/emul/... is wicked lame) -mike Did you just want to use wicked in a sentence? I bet you did. Also, I can probably hit brad_mssw for you if you want. Since I work with him now. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Thursday 10 August 2006 19:32, Doug Goldstein wrote: Also, I can probably hit brad_mssw for you if you want. Since I work with him now. hindsight is 20/20 eh ? no point in blaming people for decisions made when at the time, said decisions were the best -mike pgp0p9SR79Nsv.pgp Description: PGP signature
Re: [gentoo-dev] Council polls now open
Ferris McCormick wrote: (By the way, if the ballots from council2005 are still around, and if someone can make them anonymous (convert names to something like C1, C2, etc.), I can take them and show what results STV would give, if you'd like a controlled test.) Please see the following -core mail. If you don't have it, it's at ~jkt/gentoo-core-20050901120915.GF11365 on woodpecker. Date: Thu, 1 Sep 2005 07:09:15 -0500 From: Grant Goodyear [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [gentoo-core] Election results Message-ID: [EMAIL PROTECTED] Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
Mike Frysinger wrote: On Thursday 10 August 2006 15:42, Kevin F. Quinn wrote: More generally we have varying approaches to pre-built packages; app-office/openoffice-bin installs to /usr for example, while mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin install to /opt. which is broken ... OOo-bin should be in /opt ... There's a reason for that, it breaks switching between the two because the .openoffice dir or something has the path in it. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Matti Bickel [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 10 Aug 2006 23:59:51 +0200: Thomas Cort [EMAIL PROTECTED] wrote: Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. Even back before it became the in thing, I was posting emerge --info as attachments, because it simply fit the bill -- bugzy /says/ to put long stuff as attachments. I never did quite understand why all that admittedly often useful high-volume spew was tolerated in the bug comments themselves. I like the idea above, tho. For ATs especially, having some place where emerge --info could be posted just once, with a link to it instead of the duplicated inline /or/ attachment, makes even more sense. Presumably, where it's posted could have dated versions, too, allowing for updated flags without invalidating the info pointed to for older links. If variation off the norm was needed or used for an individual package, that could be noted in the comments along with the link to the standard info. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
