Re: [gentoo-dev] Re: Nominations for council
Duncan wrote: Ryan Hill [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 03 Jun 2008 22:26:20 -0600: AFAIR nominating has always been open to anyone, dev and user alike. Which does make sense. Giving the community nomination power gives them some input, while limiting the actual power and damage potential, since they can't vote on their nominees, only devs do. As with any nominee, if the devs don't like them, they simply vote for someone else. No harm done unless the devs consent to it. Agreed, but since there is a trend towards taking everything literally these days I do want to point out that this opens up a DoS attack - you could end up with a ballot 40 miles long if people use throwaway email addresses to make and second and accept nominations. Normally I'd just assume that if this were to happen common sense would prevail and these nominations would be excluded, but since there is a trend towards policy-trumps-sense perhaps the policy should be that anybody can nominate, but only devs can second a nomination? After all, if not even one dev supports a nomination what is the point of putting it on a ballot that only devs vote on? We could call the policy G:ACNBDMS (Gentoo: Anybody can nominate but devs must second) in tribute to another project where ability to quote policy is becoming more important than ability to add value... :) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Nominations for council
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Freeman wrote: | Duncan wrote: | Ryan Hill [EMAIL PROTECTED] posted | [EMAIL PROTECTED], excerpted below, on | Tue, 03 | Jun 2008 22:26:20 -0600: | | AFAIR nominating has always been open to anyone, dev and user alike. | | Which does make sense. Giving the community nomination power gives | them some input, while limiting the actual power and damage potential, | since they can't vote on their nominees, only devs do. As with any | nominee, if the devs don't like them, they simply vote for someone | else. No harm done unless the devs consent to it. | | | Agreed, but since there is a trend towards taking everything literally | these days I do want to point out that this opens up a DoS attack - you | could end up with a ballot 40 miles long if people use throwaway email | addresses to make and second and accept nominations. | Richard, you're forgetting that only devs can be nominated and that one has to accept a nomination to be part of the ballot. At most, you could have the total number of devs on the ballot and that is something you can't prevent. | Normally I'd just assume that if this were to happen common sense would | prevail and these nominations would be excluded, but since there is a | trend towards policy-trumps-sense perhaps the policy should be that | anybody can nominate, but only devs can second a nomination? After all, | if not even one dev supports a nomination what is the point of putting | it on a ballot that only devs vote on? We could call the policy | G:ACNBDMS (Gentoo: Anybody can nominate but devs must second) in tribute | to another project where ability to quote policy is becoming more | important than ability to add value... :) No need to complex rules here. See above point. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhGfDEACgkQcAWygvVEyAKC4wCaAm7hWHj82wV+oHQxi8H+XigL jfoAmwWt77qtSTvmDI9juBT0jkCPp8Yl =OEOJ -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary
I stumbled across another ebuild today that used the upstream-provided bootstrap script to rebuild autotools. Please refrain from using those if you can. Upstream doesn't always know better for our setup (it may try to second guess our settings by looking for particular automake/autoconf versions), it will show to the user information we don't care about, almost all the bootstrap scripts I've seen don't even try to catch when a step in the rebuild fails, they mask the need for autotools, and as you don't inherit autotools eclass for running them, you usually forget to add the autoconf/automake dependencies. And it makes very difficult to track down which ebuilds do actually use autotools to track down if there are changes to do. Let's not even start to talk about bootstrap scritps that run ./configure by themselves, those are just plainly evil. Please note that sometimes the bootstrap script is used to add extra m4 search directories and options like --foreign to automake. Well, here's the deal: - AT_M4DIR is the variable to use to pass extra m4 search directory to aclocal, no need for the bootstrap script; - eautomake takes care by itself to identify the cases where --foreign is needed (this usually means when some of the standard documentation files are missign); beside, if upstream is providing a bootstrap script for just these two reasons, then it's time they learn about ACLOCAL_AMFLAGS. Also make sure that autotools gets not rebuilt through maintainer mode, that will make the configure run twice, wasting users' time, and is usually evil if you are using unpack to check for the generated configure (yes it happened to me a couple of time). THANKS! -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgp2TEcsoe1ye.pgp Description: PGP signature
[gentoo-dev] Re: Remember, please don't use upstream-provided bootstrap unless necessary
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: Please refrain from using those if you can. As I was asked for an example see this commit I made today: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-backup/boxbackup/boxbackup-0.10.ebuild?r1=1.9r2=1.10 the original ebuild used the bootstrap script (in src_compile by the way, which is very bad for me), and depended on autoconf directly, without forcing which version should have been used. The new version instead uses autotools.eclass, calls eautoreconf, sets its AT_M4DIR as the bootstrap script did (and again, ACLOCAL_AMFLAGS is what upstream should have used). This way warnings and errors from autotools won't be seen by the users, but will be logged in case stuff fialed, and you don't have to rely on the bootstrap script not making stupid stuff. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpL2ZKCbyV3n.pgp Description: PGP signature
[gentoo-dev] Re: USE=threads vs. USE=threadsafe
Jeroen Roovers wrote: On Mon, 02 Jun 2008 20:25:29 +0200 Christian Hoffmann [EMAIL PROTECTED] wrote: I think we should be consistent here You may also want to consider the following: threadsonly [dev-libs/boost] No, you don't want to: That flag got removed in later versions and will fade out together with the old version. Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Default blank lines for error, elog, einfo, etc
Just a quick thought looking over a couple ebuilds. It seems most times anyone does a error, elog, einfo, or similar. They start and end with a few blank lines. Calls with no arguments. Is there any reason not to make that a default? Other than difficulty of implementation. Anytime they are invoked back to back. Default blank lines are added at the beginning or end. Now granted that is WAY easier said than done. The command would need to know it's being called back to back. And/or be aware of any interruptions and insert a blank line. Maybe an extra argument passed on? Not sure about cases like einfo elog Something einfo Or similar. Could just be a pipe dream, or something that is not practical or feasible to implement. Just a quick thought I had, no ties to it. Toss it in the trash for all I care. :) -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Nominations for council
On Tue, 2008-06-03 at 11:31 +0100, George Prowse wrote: Alex Howells wrote: 2008/6/3 George Prowse [EMAIL PROTECTED]: Thirded Someone can clarify but don't you need to be a Foundation member to nominate or support nominations? Either way, all of the current Council get my nomination, plus welp gets a second. Anyone can nominate but only members get a vote. Foundation members, and Gentoo Developers are not the same. I do not believe Council elections have anything at all to do with the Foundation. There are similar stipulations for time on board, etc before one can vote in either Foundation or Council elections/votes. But they are different. One needs to only be a developer, that has met time requirements, to vote for Council. Pretty sure same stipulations apply to running for Council position. At this time Foundation Membership has nothing do with developer status, or qualifications to vote in Council elections. In fact I believe a current Gentoo Developer could elect to not be a member of the foundation. They would still retain all status and rights as a developer. Including voting rights on any vote or election put forth by any entity Council, etc other than the Foundation to it's members. -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Wed, 2008-06-04 at 18:45 -0600, Ryan Hill wrote: I just throw a couple echos around any output. Surely more than one way I think doing any kind of automatic pretty-print formatting is overkill, but that's just my opinion. Yes to a point. Starting having multiple blocks like that, and your added 2 lines per for really no reason. I think a more ideal solution, less drastic to implement might be allowing 2 arguments to be passed. So you could do like elog A blank line precedes this one elog A blank line follow this one Then maybe if a argument = it can be swapped out for echo :) -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote: I think a more ideal solution, less drastic to implement might be allowing 2 arguments to be passed. So you could do like elog A blank line precedes this one elog A blank line follow this one Actually 3, not sure there would be any need for more. 3 for 1 liners elog USE flag milf not set -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
William L. Thomson Jr. wrote: On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote: I think a more ideal solution, less drastic to implement might be allowing 2 arguments to be passed. So you could do like elog A blank line precedes this one elog A blank line follow this one Actually 3, not sure there would be any need for more. 3 for 1 liners elog USE flag milf not set Well, I'm not sure how that adds anything over just using echo, and if I simply wanted to statically insert a blank line, I'd rather use echo on a separate line in the ebuild, since that would be more clear. The problem with a simple echo is that no * appears on the left to maintain continuity with the rest of the output - and in a color that makes sense in the context (maybe this isn't a problem - it depends on whether that visual continuity is desired). Also, there are those times when inserting a blank line depends on what comes after (or before) - and if a * is used, the color depends on this too. That can only be solved at a higher level (i.e. in portage). This is all just food for thought. I happen to be into aesthetics (and, BTW, I think Gentoo does a great job already in its use of colors, etc.), so I think it is important to think about these things, but it's certainly not the *most* important issue to ponder. :) -Joe -- gentoo-dev@lists.gentoo.org mailing list
