Re: [gentoo-dev] What's the use of mozilla-launcher?
Matthew Kennedy wrote: [Mon Nov 13 2006, 10:05:23AM EST] I'd be interested to hear what its purpose is exactly. All of the reasons are primarily historical, and I haven't kept track of which still apply and which don't: - separate distribution of the launcher script from the program so that fixes to the script don't require emerging the entire browser - don't confuse mozilla/thunderbird/firefox sessions - handle multiple URLs elegantly - catch ownership issues in the profile that lead to confusing bugzillas - clean up cache files from older browser versions since they can cause strange UI issues - set MOZILLA_LIBDIR and MOZ_PLUGIN_PATH so that the browser gets its own libraries and plugins rather than some arbitrary set from, for example, thunderbird If somebody wants to consider whether these issues are thoroughly alleviated by the official launcher scripts, or if mozilla-launcher should be modified in some way, go ahead and post your ideas. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Kurt Lieber wrote: [Wed Nov 08 2006, 12:02:04PM EST] On Wed, Nov 08, 2006 at 10:25:47AM -0500 or thereabouts, Aron Griffis wrote: Gentoo.org has elected to provide the SPF records, effectively marking gentoo.org mail originating from other SMTP servers as rogue. That simply is not true. Please read the write-up that I prepared that explains what we are, in fact, saying with our curret SPF record. Please pay special attention to the discussion around ?all. My bad! I hadn't seen your write-up previously. Thanks for clearing this up, Kurt. Regards, Aron pgpNb89Qpbfhg.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Lance Albertson wrote: [Tue Nov 07 2006, 12:37:53PM EST] Nothing is stopping you from sending from another smtp server. The problem people have been complaining about is that spamassassin is adding a score of 1-2 for anyone who sends from a host other than what we stated in the SPF rule. Any spam-filtering program should be able to trust the SPF information if a site provides it. Gentoo.org has elected to provide the SPF records, effectively marking gentoo.org mail originating from other SMTP servers as rogue. So it's misleading to tell devs they can send from any SMTP server... I personally don't remember the reasons for the SPF argument so I can't speak for that in a reasonable manner. When SPF was added, I don't believe SA was scoring emails in this way so it wasn't as much as a deal then. We probably should look into seeing if we can get around that, It seems a bit ridiculous to broadcast a list of authoritative gentoo.org SMTP servers, then suggest to devs to send from other servers, and try to handle the mismatch on the recipient end. Is that what you're suggesting? Aron pgpA3QDZsTVIe.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Lance Albertson wrote: [Tue Nov 07 2006, 01:55:39AM EST] Personally, after skimming through this thread, I'd say leave it as is and stick with Kurt's decision. Our developers clearly have nothing better to do than rant on about something as trivial as this. I especially didn't like the lets take this to the council first approach. I'm with genone on the I guess people can complain to the council every time emerge output changes crap. I can't believe what I read on here... People, this whole thread is silly and a disgrace to our user base to even read. I'm half tempted to submit iggy's vote-devs-off-the-island GLEP :P (Thanks SpankY for reminding me about that). Hi Lance, I appreciate that infra have put some thought and effort into setting up SPF for gentoo.org, but I don't think the complaints are silly. To recapitulate what's been said: some devs are having trouble sending email, infra's posted documentation is wrong, and infra hasn't provided suggested configs in an easily-accessible manner. Email is pretty central to Gentoo development, so could you provide some help instead of smacking people down? :-( Thanks, Aron pgpSo9htaMVHJ.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
Roy Marples wrote: [Mon Nov 06 2006, 12:44:42PM EST]
+if [[ $'\n'$(get_mounts) =~ $'\n'${svcdir}\ -w ${svclib} ]] ; then
Shouldn't this be:
if [[ $'\n'$(get_mounts) == $'\n'${svcdir} ...
because I don't think you want to treat the RHS as either a regex (=~)
or a glob (unquoted).
Aron
--
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?
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] The gnome king is dead, long live the gnome king
foser wrote: [Mon Jul 31 2006, 04:20:14PM EDT] tonight after a some deliberation I have decided to step down as gnome lead in favor of AllanonJL. Thanks for leading Gentoo's Gnome for so long, foser. thanks for your time, Marinus This must be a pretty serious announcement; I don't think I've ever seen you sign your name to an email :-) Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] architectures which support Java
I wouldn't know the first thing to do with Java, but jrocket-jdk-bin has support for 1.4 and 1.5 on ia64. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Vapier wrote: [Thu Jul 13 2006, 11:32:39PM EDT] On Wednesday 12 July 2006 13:37, Stefan Schweizer wrote: SpanKY complained that he cannot set a custom die message then. But this is not needed here, since every do* command can be clearly identified by the argument and the directory it will be installed to. except for the times where the do funcs can install the same file in different code paths Maybe fixup die() to include the call stack w/ function line numbers? I can't tell from your reply whether you dislike do* dying automatically, or if you just don't like some implementation details. Which is it? Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Danny van Dyk wrote: [Wed Jul 12 2006, 09:16:30AM EDT]
There are 505 ebuilds which are missing use flags in IUSE that they use
in other places.
I once wrote a script (attached) to update IUSE automatically. To use
it, simply:
$ cd games-emulation/xmess
$ fixiuse
It reports what it changed, and give you a resulting repoman commit
line which you can cut-and-paste.
Aron
#!/usr/bin/ruby -w
#
# fixiuse: update IUSE based on apparent usage in ebuild(s)
#
PORTDIR = %x{portageq envvar PORTDIR}.strip
ARCHLIST = IO.read(PORTDIR + '/profiles/arch.list').split(/\s+/)
$added = []
$removed = []
class Regexp
def +(rxp)
Regexp.new(self.to_s + rxp.to_s)
end
end
class Efile
attr_reader :inherits
FLAG = /[']?!?(\w[-\w+.]*)[']?/ # regex to match a USE-flag and put it in
$1
def initialize(filename)
@filename = filename
@old_iuse = nil
@new_iuse = nil
@inherits = []
if File.exists?(@filename)
@e = IO.read(@filename)
else
@e = IO.read(PORTDIR + /eclass/ + @filename + .eclass)
end
end
def inherits?(name)
name == @filename.sub(/\.eclass$/, '') or @inherits.index(name)
end
def write
# Short-circuit if there's nothing to do
return if @new_iuse == @old_iuse
# Remove the existing IUSE and remember the location
iuse_location = @e.index(/^IUSE=/)
@e.gsub!(/\bIUSE=(?:$|([']).*?\1)/m, )
# Insert at remembered location or just after KEYWORDS
if iuse_location.nil?
iuse_location = @e.index(/^KEYWORDS.*\n/) || @e.index(/\n\n/)
iuse_location += $.length
@e.insert(iuse_location, \n)
end
@e.insert(iuse_location, %Q(IUSE=[EMAIL PROTECTED] ' '}))
# Rewrite file
File.open(@filename, w) { |ios| ios.puts @e }
# Announce what we did
a = @new_iuse - @old_iuse
r = @old_iuse - @new_iuse
puts # [EMAIL PROTECTED]
if a.size != 0
puts + Added #{a.join ' '}
puts + * 70
a.each do |x|
system(fgrep, --color=always, -C2, x, @filename)
puts '--'
end
end
if r.size != 0
puts - Removed #{r.join ' '}
puts - * 70
(r + ['$IUSE', '${IUSE}']).each do |x|
system(fgrep, --color=always, -C2, x, @filename)
puts '--'
end
end
puts
# Add to the global accumulators
$added |= a
$removed |= r
end
def scan
# Collect the USE variables from inherited eclasses
inherited_iuse = []
@e.scan(/^inherit\s.*/).each do |line|
line.sub(/#.*/, ).split.each do |name|
next if self.inherits?(name)
@inherits name
eclass = Efile.new(name)
inherited_iuse eclass.scan
@inherits eclass.inherits
end
end
# Collect the content of the old IUSE
if @e =~ %r{^IUSE=.(.*?)[']}m
@old_iuse = $1.split.sort
else
@old_iuse = []
end
# Strip false matches to create e_nc (no comments)
e_nc = @e.gsub(/#.*/, )
e_nc.gsub!(/\b(?:echo|einfo|ewarn|eerror|ebegin|die)\b.*/, )
e_nc.gsub!(/^DESCRIPTION=([']).*?\1[^\n]*/m, )
# Find candidates for IUSE
@new_iuse = e_nc.scan(/\b(?:use_enable|use_with|use[qv]?)\s+/ +
FLAG).flatten
e_nc.scan(/(?:\bSRC_URI|\b[RP]?DEPEND)=.(.*?)[']/m).flatten.each do |dep|
@new_iuse += dep.scan(FLAG + /(?=\?)/).flatten
end
@new_iuse 'boundschecking' if e_nc =~ /\bwant_boundschecking\b/
@new_iuse 'nopie' if e_nc =~ /\bwant_pie\b/
@new_iuse 'nossp' if e_nc =~ /\bwant_ssp\b/
# Special treatment for ebuilds that inherit particular eclasses
if self.inherits? 'confutils'
@new_iuse += e_nc.scan(%r{\b
(?: confutils_use_conflict | confutils_use_depend_all |
confutils_use_depend_any )
}x + ('(?:\s+' + FLAG.to_s + ')+')).flatten
@new_iuse += e_nc.scan(%r{\b
(?: enable_extension_enable | enable_extension_disable |
enable_extension_enableonly |
enable_extension_without | enable_with | enable_withonly )
\s+}x + FLAG).flatten
end
if self.inherits? 'mozconfig'
@new_iuse += e_nc.scan(/\bmozconfig_use_(?:enable|with|extension)\s+/ +
FLAG).flatten
end
if self.inherits? 'x11'
@new_iuse += e_nc.scan(/\buse_build\s+/ + FLAG).flatten
end
# Special treatment for some ebuilds...
case @filename
when /^wine-/
@new_iuse += e_nc.scan(/\bconfig_cache\s+/ + FLAG).flatten
when /^qt-\d/
@new_iuse += e_nc.scan(/\bqt_use\s+/ + FLAG).flatten
when /^ezm3-\d/
@new_iuse += e_nc.scan(/\bseduse\s+/ + FLAG).flatten
when /^xmess-\d/
@new_iuse += e_nc.scan(/\btoggle_feature2?\s+/ + FLAG).flatten
@new_iuse += e_nc.scan(/\btoggle_feature2\s+\S+\s+/ + FLAG).flatten
end
# Clean up
@new_iuse -= [ 'the' ] # common false matches
@new_iuse -= ARCHLIST
@new_iuse.reject! { |x| x =~
/^kernel_|^elibc_|^linguas_|^video_cards_|^input_devices_/ }
(@old_iuse - @new_iuse).each do |u|
# don't remove items from IUSE that are in an
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Stefan Schweizer wrote: [Wed Jul 12 2006, 01:37:44PM EDT] This came up in Bug 138792 [dobin etc. should automatically die on failure] Since do* would become functions in this case, you'll have to fix the few ebuilds that use them on the RHS of xargs. grep -r --include \*.ebuild -E 'xargs do(bin|exe|ins|man|doc)' . Assuming the list is relatively short, it should be acceptable to convert these to something like: doman $(find man -name '*.?.gz') The speedtouch ebuild is screwy anyway. There's no reason for the echo. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Jakub Moc wrote: [Wed Jul 12 2006, 05:11:01PM EDT] Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. The point is to catch the problems at version-bump time or typo-time rather than put a broken ebuild into portage. IMHO this change can mean nothing but goodness for the overall quality of the portage tree. Surely you don't go around version-bumping and typo-ing without testing prior to commit, right? Regards, Aron pgp9OVi53Gv5D.pgp Description: PGP signature
Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)
Matthias,
Matthias Schwarzott wrote: [Sun May 21 2006, 05:40:53AM EDT]
* The eclass copies the downloaded sources to ${S} rather than to
${WORKDIR}/${HG_MODULE_NAME}.
* the unpack-function keeps the current working directory
in /usr/portage/distfiles/hg-src/${HG_MODULE}.
Could you try the version from my (new and shiny) overlay?
http://n01se.net/agriffis/overlay/
I think this solves both problems. I didn't create a variable
HG_MODULE_NAME because with mercurial the name of the module is always
the last component of the URL.
I don't think for your purposes it matters, but you can rename the
local clone by calling mercurial_fetch directly, for example:
mercurial_fetch http://n01se.net/agriffis/overlay overlay_agriffis
Regards,
Aron
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New darcs.eclass
Henrik Brix Andersen wrote: [Sat May 20 2006, 04:50:22AM EDT] On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote: Along these lines, I added my mercurial.eclass to the tree. I use it personally for a couple projects, and figured it might help prevent other people from needing to re-invent the wheel. Errr... you added a new eclass without posting it to this mailing list for review first? I've never posted an eclass here for review, and I don't think I've ever announced one before either, so let's call this progress. ;-) If you'd like to review it, I'd appreciate the input. Thanks, Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New darcs.eclass
Along these lines, I added my mercurial.eclass to the tree. I use it personally for a couple projects, and figured it might help prevent other people from needing to re-invent the wheel. Regards, Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Fri Apr 07 2006, 07:00:22PM EDT] On Tuesday 04 April 2006 13:54, Aron Griffis wrote: Vapier wrote: [Tue Apr 04 2006, 01:12:28AM EDT] the idea is that it's common sense and to need to vote on something like this seems asinine It might seem that way, but something that is voted on and accepted has credibility. Something that is simply posted as common sense does not. but something that is accepted by everyone rather than being handed down from a much smaller group of people has more credibility imho the point of this thread was to see what everyone thought and getting it to the point where everyone is happy, not just the people who would be voting Oh, I agree with that completely, if a few days late. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Tue Apr 04 2006, 01:27:54AM EDT] On Monday 03 April 2006 19:35, Aron Griffis wrote: I disagree with fast-tracking this to any official Gentoo documentation. i never used the word fast ... where did it come from ? Earlier you said: Vapier wrote: [Mon Apr 03 2006, 05:38:48PM EDT] this is on track to be integrated as-is into the dev handbook Etiquette section You're right, I introduced the word fast but it's what I thought you meant by on track to be integrated as-is. Sorry if I misunderstood. Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you make will affect users and colleagues, and we expect you to take those consequences into account when making decisions. All of this is obvious, except for who is we? the Gentoo community ? your peers and loved ones ? Ok, thanks for the clarification. IMHO we expect is patronizing, which is unfortunately the overall tone of this document. I'm not just whining here... I'm willing to offer alternative suggestions that hopefull will drop that tone. For example, how does this sound instead? Be considerate. Your work is used by other people, and you in turn depend on the work of others. Each decision you make affects users and colleagues, so consider your choices carefully in light of the consequences. Be respectful. The Gentoo community and its members treat one another with respect. Odd to make this declarative statement when it isn't true. this document now exists because this statement isnt true ... this is one part of a solution imo Personally, I think your statement in another subthread regarding two kinds of respect was more valuable than this questionable declaration. You were wrong, though, regarding respect. Respect is always earned. The term we need here is grace, which refers to giving something that isn't necessarily deserved. Here is my attempt at rewriting that entire paragraph: Be gracious. When a disagreement arises, the possibility exists that you are wrong and the other person is right. Especially when a situation is frustrating, you give the most to the Gentoo community by responding humbly and patiently. Personally I think this covers the bases. I don't think it's necessary to detail who deserves this kind of treatment, the very definition of grace implies that it applies to everybody. I also like this because it's different from Ubuntu's document. That isn't reason in itself, but it's nice to believe that we've carefully chosen our words and eventually produced something that applies best to Gentoo. Everyone can make a valuable contribution to Gentoo. They can? Making this kind of feel-good blanket statement just detracts from the rest of this document. how so ? one of the critiques we have is that one jackass can turn off users/potential devs simply by their abrasive behavior. another critique is that some of us (i am guilty of this as well) of being too snobbish in terms of who can actually make useful contributions (generally if you have an @gentoo.org, that somehow qualifies you while those who do not are just meat). i recognize i'm a bit of a dick and i'm trying to change. I took this out in my rewrite above. I'm not trying to deny that it's a mindset that we should have, but IMHO it doesn't lend anything beyond what has already been said. If you think it really needs to be said, I can try to work it back in... We may not always agree, but disagreement is no excuse for poor behaviour and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attacks. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one. This should be shortened to say just what it means: Developers will have more fun, be more productive, and create a better distribution if we concentrate on the issues instead of resorting to personal attacks. i sort of like the longer winded version better ... really this paragraph shouldnt have to exist at all, but since it does, i like the version that spells out each detail clearly. Heh, I don't see it as details, I see it as rambling and muddiness. But you're right that my original attempt lost the concept. What do you think of my new one (Be gracious...) Be collaborative. Gentoo and Free Software are about collaboration and working together. Collaboration reduces redundancy of work done in the Free Software world, and improves the quality of the software produced. You should aim to collaborate with other Gentoo maintainers, as well as with the upstream community that is interested in the work you do. Your work should be done transparently and patches from Gentoo should be given back to the community when they are made
Re: [gentoo-dev] adding a code of conduct
Vapier wrote: [Tue Apr 04 2006, 01:12:28AM EDT] the idea is that it's common sense and to need to vote on something like this seems asinine It might seem that way, but something that is voted on and accepted has credibility. Something that is simply posted as common sense does not. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
Ned Ludd wrote: [Mon Apr 03 2006, 09:40:54PM EDT] Umm ok. I've decided that root is root no matter how you look at it and it's not worth getting into a vertical pissing contest over. Having root doesn't equal having authority. One of the issues right now is whether Infra has assumed authority on the basis of power. If they didn't have root, wouldn't their decision to grant themselves authority look rather silly? A contrast between Infra and the Council is that the former is a team that has chosen itself (like any other team in Gentoo), the latter is elected. The Council has been granted authority by the Foundation members. Infra has power by virtue of being entrusted with the keys to the Gentoo infrastructure, paradoxically it has no authority beyond the decisions that fall in its domain, those necessary to the daily running of the Gentoo infrastructure. Suspending a Ciaran's access falls on the line. IMHO it was an overstep, an abuse of power, but an understandable mistake. I disagree with Infra's refusal to restore Ciaran's access when it was first requested by Ferris. I know Devrel and Infra have now reached an agreement, but frankly I think the situation still stinks, because it's skirting the agreed-upon Devrel process by suspending Ciaran before the conclusion of the trial. Your statement essentially says that power and authority are the same thing, and there's no point quibbling over it. I don't buy it. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
Solar points out that I'm relaying details from -core to -dev in this post. My apologies for that, I'll try to be more careful. :-( Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
I disagree with fast-tracking this to any official Gentoo documentation. Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you make will affect users and colleagues, and we expect you to take those consequences into account when making decisions. All of this is obvious, except for who is we? Be respectful. The Gentoo community and its members treat one another with respect. Odd to make this declarative statement when it isn't true. Everyone can make a valuable contribution to Gentoo. They can? Making this kind of feel-good blanket statement just detracts from the rest of this document. We may not always agree, but disagreement is no excuse for poor behaviour and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attacks. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one. This should be shortened to say just what it means: Developers will have more fun, be more productive, and create a better distribution if we concentrate on the issues instead of resorting to personal attacks. We expect members of the Gentoo community to be respectful when dealing with other contributors as well as with people outside the Gentoo project, and with users of Gentoo. Again, who is we? Be collaborative. Gentoo and Free Software are about collaboration and working together. Collaboration reduces redundancy of work done in the Free Software world, and improves the quality of the software produced. You should aim to collaborate with other Gentoo maintainers, as well as with the upstream community that is interested in the work you do. Your work should be done transparently and patches from Gentoo should be given back to the community when they are made, not just when the distribution releases. If you wish to work on new code for existing upstream projects, at least keep those projects informed of your ideas and progress. It may not be possible to get consensus from upstream or even from your colleagues about the correct implementation of an idea, so don't feel obliged to have that agreement before you begin, but at least keep the outside world informed of your work, and publish your work in a way that allows outsiders to test, discuss and contribute to your efforts. This part makes sense, I think... though I don't see the point of codifying it except to throw the book at the next Paludis. Frankly I think Ciaran did nothing wrong to restrict distribution on a project he didn't feel was ready for public consumption. It has always seemed to me like the overreactions were the problem. When you disagree, consult others. Disagreements, both political and technical, happen all the time and the Gentoo community is no exception. The important goal is not to avoid disagreements or differing views but to resolve them constructively. You should turn to the community and to the community process to seek advice and to resolve disagreements. We have the Council, Infra, Devrel and Team Leaders all of which help you decide the right course for Gentoo. What do you mean by turn to the community and to the community process? I'm not sure what that entails. And I'm really not sure I understand what the last sentence means. Repeated disruptive behaviors will be viewed as a security and stability threat to Gentoo. Classic switching to the passive voice when the actor wishes to be distanced from the action. WHO will view these behaviors as a security and stability threat to Gentoo? Is this a statement the existing developers are making? The foundation? Infra? Your access to Gentoo infrastructure may be suspended without notice if it is deemed that you fall into this category. Again passive voice. WHO will suspect access without notice? WHO will make the decision? (Clearly infra will implement it.) And doesn't without notice somehow void the consult others bit earlier? If your account is suspended, you will still retain full developer status -- you will simply not have access to Gentoo infrastructure. You may continue to do development work during your suspension. This is bogus. If a person's account is suspended, they don't have commit access, they're temporarily not a developer. Mincing words doesn't change things. You may elect to save up your changes until such a point where your access has been reinstated, or you may work with another developer to have them commit changes on your behalf. If you choose the latter option, please ensure members of the Infrastructure project have reviewed and approved the proxy relationship to avoid having access cut off for both developers. Anybody can submit work to a developer who can proxy that work into Gentoo. What is this new proxy approval process that Infra has decided to enforce? If your account is
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
Stephen P. Becker wrote: [Mon Apr 03 2006, 07:11:12PM EDT] Whether it is meant to be flamebait or not is irrelevant. This list isn't for whining about (the lack of) stable keywords for any particular ebuild or set of ebuilds. Making this kind of statement without pointing the poster to the appropriate place (and I'm curious too) surely isn't helping anybody. Where do you suggest procedural questions be asked? Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
Dan Armak wrote: [Mon Mar 27 2006, 03:25:04PM EST]
Option 1: KDE only displays KDE apps, Gnome only Gnome apps. How do we decide
what is displayed in both ('neutral' apps)? Can the user edit the menu, and
include some things we don't include by default, in a WM-neutral way? What
should WMs other than KDE and Gnome display by default?
Option 2: always display everything. Problems: huge menu. KDE and Gnome and
others use different categorization. A change of the status quo, so user
community should get a chance to veto. And when using descriptions as primary
menu text (e.g. 'Text editor' instead of 'kwrite'/'gedit') some KDE and Gnome
programs have similar or identical descriptions, which looks bad to new
users.
Instead of choosing one or the other option, how about simply choosing
a default (and I'd suggest #2 personally, but that's just my opinion).
Then use an eselect module to allow system-level and user-level
customization regarding which classes to display in which places.
For example, there are Gnome, KDE and X progs, three classes at least.
(I know there are others; hopefully the design could handle an
arbitrary number.) So it would be nice to be able to say:
- In Gnome I want to see everything
- In KDE I want to only see KDE stuff
- but user george chooses to see everything in KDE
It sounds complex but maybe it could be made to work?
Aron
pgprRKXlxDAGn.pgp
Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST] It sounds to me like the overlays would benefit of using git/cogito. The Linux Kernel uses this DVCS to full affect. Pulling changes from other repositories, and even receiving email patches pushed from people not having their own official repository (or repository http or ssh accessible). Any git checkout is a branch, so its easy to stay up to date with the mainline tree and still work on personal branches. Most of the other DVCSs are easier to use than git, and just as powerful or more. IMHO git is used for Linux mostly because Linus wrote it, rather than it being the best tool for the job. I think any of mercurial, darcs or bazaar-ng is a better choice than git. Regarding cogito, I haven't looked at it in a while, but the last time I did, it was underpowered and buggy. AFAIK none of the kernel developers use it, 'cause it doesn't hold up under serious use. We need to pick one VCS and only one. Having multiple systems requires users to install multiple applications and learn each one. Not all of them are easy to pick up. Plus, it would be nice to be able to merge from the overlays to the Portage trunk. This would be pretty neat eventually, to switch portage itself over to a DVCS so that all the overlays would simply be branches that could be merged, etc. At this point it would be biting off more than we can chew, though... Perhaps using various DVCS solutions for the overlays might actually be a good testing ground for determining the successor to cvs for the actual portage tree. At any rate, I don't think it's necessary to limit ourselves to one. You're right, developers will have to install multiple applications and learn each one for the overlays they work on. Probably it won't be that many, though (overlays or applications) and r/o users will likely just get an rsync'd copy instead of using the DVCS to access the overlay (at least that's how I imagine it working...) I think git/cogito might be the solution. It works for a highly distributed kernel development, which would be similar to the way the overlays would work. Gentoo User A would checkout the kde overlay, make some changes, cg-commit them to their own overlay, and submit the patches upstream via an email requesting a pull, or emailing them patches directly with a git-mkmail command. *shrug* All possible with the other DVCSs, generally easier to use, and harder to screw up your repo. An alternative to git would be using subversion. *** The main portage tree should be switched away from CVS. *** There are much better alternatives (svn or git) to use. Have you followed the threads in the past regarding using other version control systems for portage? Some devs have done benchmarks and found that there are blocking issues with subversion, particularly because of its repo-wide revisions that prevent multiple commits from happening simultaneously. CVS is our bottleneck when it comes to development and our users too. What I see is that the overlays are trying to create branches, when they should not need to. Making a PHP or Gnome v2000 overlay is ridiculous, since a branch is almost free using subversion. There are more advantages, like making sure the rest of the tree doesn't break, and when the branch is stable for package.mask or arch masking then merge the branch to trunk. The main tree could live within subversion (or whatever VCS we choose) as a branch. It would be easy to keep the branch up to date with trunk, and then merge the changes to the live branch. Major changes to the tree need to be done in a branch where it should be done. Overlays should be used only for small additions/changes/or tests. It feels like the overlays are already trying to create branches, when in fact, they would not have to if the main tree was _not_ in CVS. I agree this sounds really nice and makes a lot of sense. I think that the overlay project is a step toward this, though, not a step away. The time isn't yet ripe for switching the portage tree to different VCS. Comments? I guess you asked... :-) Aron pgps6qV9xEJa9.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
Luca Barbato wrote: [Sat Mar 25 2006, 05:16:57AM EST] Please consider git and mercurial proxies, maybe nobody proposed it yet but is relatively easy to provide it and it would be great since gives you most of the goods from darks w/out the pain related of building it. Could you point to some references? Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
Aron Griffis wrote: [Sat Mar 25 2006, 06:00:49PM EST] Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST] It sounds to me like the overlays would benefit of using git/cogito. The Linux Kernel uses this DVCS to full affect. Pulling changes from other repositories, and even receiving email patches pushed from people not having their own official repository (or repository http or ssh accessible). Any git checkout is a branch, so its easy to stay up to date with the mainline tree and still work on personal branches. Most of the other DVCSs are easier to use than git, and just as powerful or more. IMHO git is used for Linux mostly because Linus wrote it, rather than it being the best tool for the job. I should backpedal on that statement a bit... While I think it's true historically, git is doing a great job for kernel development, and it can't be criticized lightly. Nonetheless, similar power is available in other DVCSs that are easier to use and less likely to cause headaches. Aron pgpR0WCI5WyNQ.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
Fernando J. Pereda wrote: [Sat Mar 25 2006, 06:18:52PM EST] Well, I find it easier to understand than many other DVCSs out there... In fact I don't think it is difficult to use in any way. Maybe pre-1.1 versions had some syntax weirdnesses, but the 1.2 series are really easy to use and understand... That is good to hear. It's possible that my comments were misplaced, and it would be worth my while to reinvestigate git. Personally I use mercurial daily (xen) and I've been very happy with it. I'm under the impression that mercurial is easier to use than git, mostly because of git's philosophy of providing the low-level infrastructure and expecting other projects to build user-friendly interfaces. While that split sounds good in theory, it seems to result in one interface that's powerful+complex, and other interfaces that are weak+easy. Again, that's an impression, not recent personal experience. *shrug* All possible with the other DVCSs, generally easier to use, and harder to screw up your repo. How would you screw your repo using normal Git commands ? I shouldn't have made that statement since I haven't done it personally, only heard of it happening to other people, and not recently. Aron pgpdf0m3m57vO.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Chris Gianelloni wrote: [Fri Mar 24 2006, 08:55:30AM EST] As I've said, my only request is a single policy that before an overlay can become publicly readable on overlays.gentoo.org (which is Gentoo infrastructure) that it does not break packages in the main tree that are not in the overlay. This makes sense, but what's the content of such a policy? Take your gcc-5.1.99 example: say it breaks lots of packages in portage. Is it not allowed to be in a publicly accessible overlay in that case? If that's not the policy, then what policy allows gcc-5.1.99 but still covers the ground you want covered? Aron pgpWrcVTWdrd5.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Stuart, I like the idea of overlays but your email here is completely bogus. Ciaran just explained why overlays are a Gentoo problem, rebutting Jakub's assertion that there's no need for policies. I don't see any agenda here, so either you're pulling in external context, or you're reading into it. Aron Stuart Herbert wrote: [Fri Mar 24 2006, 03:59:54AM EST] It is a Gentoo problem, because Gentoo gets innundated with bogus bug reports when users screw up their systems in weird ways and don't realise the cause. Convince me that this is something more than just a power play, and I'll work with you. But that's the hurdle you'll need to overcome first. Second hurdle is that you need to convince me that you get what the overlays are there for. If you can't, then I can have no confidence that any policies you bring forward are appropriate for the work we're trying to enable. Thrid hurdle is that you need to convince me that you're capable of treating the overlays differently to how the main tree is treated. If you can't, then I'll feel that you hoodwinked me at the second hurdle. I'm sure you've got a lot to offer, to help make the overlays a success. But your agenda has to be appropriate - otherwise you'll just do more damage that good. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
Grant Goodyear wrote: [Fri Mar 24 2006, 02:35:34PM EST] After reading through that fairly lengthy thread, I'm afraid that I can no longer tell exactly what is being proposed. Who has read access? Who has write access? Bugs are handled where, and by whom? Are we considering a fairly tightly controlled system, or a wild free-for-all? Exactly which problem are we proposing to solve here? If someone could succinctly summarize the current schools of thought, I'd be quite indebted. I'll chime in, but with an additional request rather than a response. Stuart said something about this not needing a GLEP, and maybe it doesn't, but personally I'd rather see it go that route. Writing a GLEP formalizes the answers to these questions and helps to put us all on the same page. Aron pgpkqUtbuEFHe.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Ciaran McCreesh wrote: [Wed Mar 22 2006, 12:33:10PM EST] On Wed, 22 Mar 2006 09:03:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | This definitely sounds like a fun idea. It would be even cooler if we | were using a distributed SCM on both ends that allowed for easy | merging. Word of warning to anyone planning to implement one of these that includes rsync with cache as a frontend: you will be giving root access to your box to any user with commit access. Could you give some explanation or reference for this? Thanks, Aron pgpgv5X6M9Xir.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Chris Gianelloni wrote: [Thu Mar 23 2006, 09:41:25AM EST] On Thu, 2006-03-23 at 10:09 +, Chris Bainbridge wrote: Reduced responsibility for package QA (I expect we don't care about overlays to become a standard response on bugs.g.o) You will *definitely* get this from developers that won't be using the overlays. Let's just say you decide to use a toolchain overlay and it exposes some problem in random app foo because you're using gcc 5.1.99 and we only have 4.0 in the tree. You file a bug against package foo without a patch. I'm the maintainer. You've now made me spend my time supporting something that isn't even in the tree, and could be an artifact of the overlay itself and something that will *never* end up in the tree. Why should I do this? What we have done here is actually *reduced* the amount of productive work that I can do by forcing me to deal with these overlays, even if I choose not to participate. Some of this could be mitigated with some additional or modified tools. For example, emerge --info could be augmented to take a package argument and list the installed dependency tree for that package. The list could also include *where* the package and deps came from, PORTDIR or an overlay. The result would be required information in a bug report, similar to the existing emerge --info requirement. So if I were submitting a report about keychain, I would be required to include the result of emerge --info keychain It becomes a lot easier for devs to determine that a problem might be due to an overlay, then take whatever action they prefer based on that information. For some devs, the fact that gcc-5.1.99 breaks their package might be a welcome early warning. Another possible enhancement would be to include a checkbox in the bug report to indicate whether overlays are in use. Hopefully checked by the reporter, but alternatively auto-detected by emerge --info in comment #1, or checked by our ever-vigilant wranglers. This would make winnowing of overlay-caused bugs easier. Just some thoughts... Aron pgpwrrFEvKPXO.pgp Description: PGP signature
Re: [gentoo-dev] svk maintainer needed
kang wrote: [Thu Nov 03 2005, 02:29:11PM EST] I can maintain it if no one else can. Feel free. I've bumped the version once and added a patch, but I would rather not be the primary maintainer. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2uMipSEbc5.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
Jakub Moc wrote: [Thu Feb 16 2006 - 06:34:32PM EST] 17.2.2006, 0:23:49, Ciaran McCreesh wrote: On Fri, 17 Feb 2006 00:14:42 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | What are you talking about? commonbox is listed as maintainer of that | stuff, it's been broken for years, you neither fixed it or bothered | to remove it from portage, nor did you at least re-assign that to | maintainer-needed and remove yourself from metadata.xml. You should probably go and read herds.xml sometime. Or maybe you should, rather... I believe Ciaran is referring to his stated role in commonbox: maintainer email[EMAIL PROTECTED]/email nameCiaran McCreesh/name roleFluxBox only/role /maintainer Ciaran, if this isn't what you mean, could you clear up the confusion? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpjxRiSW3cBl.pgp Description: PGP signature
[gentoo-dev] Gentoo Council Meeting Summary (20060209)
Present: azarah (Martin Schlemmer) Koon (Thierry Carrez) Swift (Sven Vermeulen) agriffis (Aron Griffis) seemant (Seemant Kulleen) solar (Ned Ludd) vapier (Mike Frysinger) Agenda: * GLEP 44 - Manifest2 format Outcome: * Council members were generally in agreement that GLEP 44 is a good idea, but without genone present to answer questions, the council was unwilling to approve or deny it. Postponed to next meeting, with the expectation that genone or a proxy will attend then. -- Aron Griffis Gentoo Linux Developer pgpi2aHA1FWSf.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Grant Goodyear wrote: [Tue Jan 10 2006, 11:09:15AM EST] As an aside, it's ciarnanm has already put work in on developing an RST to guidexml converter, so I wouldn't worry too much about RST not scaling. Could that be used dynamically on the server? The last time I was familiar with the gentoo.org server, it was running axkit and dynamically generating HTML from the GuideXML. Is it a relatively simple matter to support .rst files in the same manner? A related question: How hard would it be to enable the dynamic generation for dev.gentoo.org/~users? That would make development of RST or GuideXML documents *much* simpler, since we could just work on the file in our public_html and test render it by accessing through a web browser. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpF7KHOmWDtC.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Brian Harring wrote:[Sun Jan 08 2006, 09:16:36PM EST] Regardless, (imo) it's already been laid out why guideXML'ifying everything doesn't totally work. Three reasons... A) bit of work required just to jot down a quick list of this is broke, fix it that's going to be thrown out 2 weeks down the line. I noticed Ciaran has been using RST for GLEP 42. I wonder if it would be a good alternative to guideXML in general. http://docutils.sourceforge.net/rst.html I realize this doesn't address the *rest* of what you said, though... Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpz1VyIiCw8i.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Split ebuilds for GCC
Duncan wrote: [Wed Jan 04 2006, 02:49:39PM EST] Forget formal logic, it still begs the question, in that it begs that the question be asked. No, the reason you used the expression begs the question is because it sounds familiar to you. Otherwise you would have said something like brings up the question. The fact is that begs the question is an expression with a particular meaning, and it shouldn't be confused with the sum of its parts. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpQZl3QOtvu1.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Hi Lance, You started this thread by proposing that: (1) Gentoo is lacking a direction/goal, (2) this is supported by the lack of ground breaking enhancements in the past couple of years. Later in the thread you proposed that (3) the solution may be to appoint a single person to provide a global goal/direction for the project. Looking first at 1 and 2, I think your assumption that ground-breaking enhancements are dependent on direction/goal is false. IMHO any single project within Gentoo can bring ground-breaking enhancements to the distribution without being given prior direction from a higher authority. The places where Gentoo needs improvement are generally well-known, and any developer has the power to bring a design and implementation to the table. The problem here isn't a lack of direction, it's a lack of action, particularly in the areas that *you* consider ground-breaking. What in particular would you like to see? So, keeping in mind that any developer can bring a plan to the table, my understanding of the council is this: In cases where a plan requires broader changes, the role of the council is to make sure that the plan makes sense in the context of Gentoo, where context is defined as history, philosophy, and the collection of goals defined by the other projects. It is not the role of the council to cook up the plan, that can be done by any developer(s), including council members if they have any brilliant ideas. ;-) Finally, looking at 3, that statement depends on the relationship between direction/goal and ground-breaking enhancements. If that relationship does not exist, then 3 is moot: Appointing a single individual to lead the project will not have an effect of generating ground-breaking enhancements. Personally, I agree with Grant's and Chris's comments in this thread. There have been some positive changes in the past couple years, and there are people working hard to bring more about. Hopefully we're cultivating an environment where the next major enhancement is just around the corner. What will it be? I'm in favor of leaving that to the individual projects to determine. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpvoPZyPCxiA.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Hi Kurt, Kurt Lieber wrote: [Wed Jan 04 2006, 11:31:30PM EST] Ok, then what should Gentoo do to fix this percieved decline? Exactly what a lot of folks will have kittens about; appoint a CEO, leader, boss, manager, etc. (you know, all those corporate-type words that raise the hackles of nearly everyone on this list.) I think there is a Post Hoc fallacy happening here: A happened before B, therefore A must be causing B. In the case at hand: A = loss of leader, B = lack of progress. While A might be the cause of B, it is dangerous to jump to that conclusion without more than the sequence as support. I don't think I can solidly refute the possibility of a relationship, but here is some food for thought: First, Gentoo's developers are not going to follow a leader's direction unless they sincerely agree with it. Since we're all volunteers, the only cooperative work we're going to see is when people agree with a goal. Therefore it doesn't matter whether you name somebody our leader or if they're just another developer, either way they're going to have to convince people to play along. Our current model already allows for centralized leadership via meritocracy: any developer can step up to the plate and be king for the day, they just have to have a good idea and convince others to go along with it. Second, I think the factualness of B is in question. A few people have brought up examples of progress being made within Gentoo. The problem here appears to be that the progress being made is not in the same areas where some people are looking. Which brings up the question: How is Gentoo falling short in your eyes? Are you certain that those specific areas are related to the non-existence of a boss? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp1SClWDTdd2.pgp Description: PGP signature
Re: [gentoo-dev] browserplugin vs. nsplugin
Thomas Matthijs wrote: [Tue Oct 18 2005, 10:46:15AM EDT] We had discussed it prior and then nobody seemed to object to browserplugin, only after we changed it. Actually that's not true. http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02898.html You see that karltk said he would be making the change to browserplugin over the course of the next few days. Diego responded in the same day regarding nsplugins. I sent a message that day and the following day, but there was no response from karltk or the java team. http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02896.html http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02911.html http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02925.html You have the java herd's blessing to go ahead and change it. Please announce it to gentoo-java@ aswell when you make the change. Will do, thanks. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpiVF2ibVwS6.pgp Description: PGP signature
Re: [gentoo-dev] browserplugin vs. nsplugin
Thomas Matthijs wrote: [Tue Oct 18 2005, 10:46:15AM EDT] You have the java herd's blessing to go ahead and change it. Please announce it to gentoo-java@ aswell when you make the change. All set. The only place browserplugin is mentioned is in the ChangeLogs. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpnZDTJLMbUn.pgp Description: PGP signature
Re: [gentoo-dev] browserplugin vs. nsplugin
Petteri Räty wrote: [Tue Oct 18 2005, 03:39:04PM EDT] Maybe there should also be a mention in gwn next week and the change would then be committed on for example next tuesday. It's already done. The ebuilds still honor USE=browserplugin but they give a warning. Also the flag is marked as deprecated in use.local.desc Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpupH3V2Ck53.pgp Description: PGP signature
[gentoo-dev] browserplugin vs. nsplugin
Back in July the Java team proposed fixing its ebuilds to respect the USE=browserplugin instead of USE=mozilla, a worthwhile change. During the course of the discussion, it became clear that the existing USE=nsplugin was more appropriate. http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02898.html Unfortunately the discussion stagnated and the Java team went ahead with their original suggestion. At this point I think it would still be worthwhile to repair these ebuilds to respect USE=nsplugin and drop the browserplugin from use.local.desc. Comments? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpMChTCnkgcz.pgp Description: PGP signature
Re: [gentoo-dev] browserplugin vs. nsplugin
Chris Gianelloni wrote:[Mon Oct 17 2005, 03:21:35PM EDT] Agreed 100%. USE=mozilla shouldn't be used for plugins when we already have a perfectly good USE flag for it. Thanks, but that's not the point. The point is to switch them from using the local USE=browserplugin to using the existing global USE=nsplugin Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpf0XOVG3cTU.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-portage-dev] allow extra info to be echod on die
Brian Harring wrote:[Wed Oct 05 2005, 02:47:09PM EDT]
diefunc() {
local funcname=$1 lineno=$2 exitcode=$3
shift 3
@@ -289,6 +291,7 @@
echo !!! ${*:-(no error message)} 2
echo !!! If you need support, post the topmost build error, NOT this status
message. 2
echo 2
+ for x in $EBUILD_DEATH_HOOKS; do
+ ${x} $1 $2 $3
+ done
exit 1
}
Is this exactly what went in? It looks like you're trying to use
positional params that were shifted earlier.
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpUEDxFafRfx.pgp
Description: PGP signature
Re: [gentoo-dev] first council meeting
Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT] not really ... sometimes you want to keep a package in unstable forever (like the cvs snapshots i make of e17), or until you work some quirks/features out for a new revbump which you would want stable Why wouldn't you put these in package.mask? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp4V1gCmR7oy.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT] Those should be in package.mask. ~arch is for candidates for arch that haven't yet proven themselves. It's often the case that those ebuilds in principle work, but there are other reasons for not marking stable yet. Some packages for example can have upgrade problems for stable users while being stable for testing (by benefit of allready having passed such upgrade problems). Masking the ebuild is not really an option (causing testing users to go through unnecessary hoops again), while marking stable is also no option. You're saying there's four states: package.mask ~arch ~arch candidate for arch arch Putting packages in package.mask isn't a hardship for testers. I'm not sure that's a good reason for the additional state. It's purely a matter of echo 'dev-util/mercurial' /etc/portage/package.unmask So far I find myself agreeing with Ciaran's idea in this thread. I don't see the point (yet) in more than three states. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgppgsKoBkwrJ.pgp Description: PGP signature
[gentoo-dev] first council meeting
The first council meeting happened today at 1900UTC. All council members attended. 1. Official confirmation that the council is inline with the already-defined roles of devrel and QA and its commitment to make already-approved GLEPs (including GLEP 31) respected (Clarification of position asked by many people including Ciaran McCreesh, Patrick Lauer and Lance Albertson) Confirmed with the caveat that the council is not taking on disciplinary responsibilities. The QA team should take complaints regarding unresolved technical violations to devrel to pursue displinary action. Regarding GLEP 31, the council is in favor of enforcement ASAP, provided nano is confirmed to be capable of compliance. That will set the bar to require UTF-8 capable editors for portage work. (note: agenda reordered per request) 3. glep40: Standardizing arch keywording across all archs Vote asked by Grant Goodyear Approved. 2. glep33: Eclass Restructure/Redesign Vote asked by Brian Harring Approved. 4. Discussion of the next meeting date(s) 2nd Thursday of each month, 1900UTC. Rain date of 3rd Thursday. 5. Open QA session Full meeting log available at http://gentoo.org/proj/en/council/meeting-logs/20050915.txt Please post follow-ups to gentoo-council ML (subscription required) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpFWsVRuq3Fp.pgp Description: PGP signature
Re: [gentoo-dev] ROX: maintainer-wanted and apps out of date
Alin Nastac wrote: [Sun Sep 11 2005, 05:02:27PM EDT] Gentoo history is full of such individuals who only want to be sure that they could become devs but are not willing to put any effort behind it. Gentoo's history is full of hard-working devs. The slackers are simply forgotten. ;-) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpylFV2wRbt4.pgp Description: PGP signature
Re: [gentoo-dev] New global use flag: nsplugin
Carlos Silva wrote: [Fri Aug 26 2005, 02:18:29PM EDT] Why was reading the use.local.desc file and noticed that there are 6 packages with this use flag... If nobody oposes it, I'll make it a global use flag with the Description all the nsplugin local flags have :) Please go ahead, this is the right thing to do. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp93vXsbU6LV.pgp Description: PGP signature
[gentoo-dev] lilypond maintainer needed
I have been the lilypond maintainer for x years, but lately I haven't been using it personally, and consequently I haven't been keeping up with the releases. However there are lots of users that would like to see the update go into portage. Any devs, particularly tex-savvy ones, interested in maintaining this package? See bug 97574 Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp0x1YzarDNY.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jason Stubbs wrote: [Wed Aug 17 2005, 08:09:39PM EDT] I don't quite get you here. GLEP 31 has been approved, no? That would make it seem to me that the above suggestion is just making the QA tool help enforce existing policy. If there's a flaw in that line of thinking, please point it out in case I fall into the same trap in some other instance. You might be right. I wasn't aware that GLEP 31 was approved before it was withdrawn. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2qJCbzyyD7.pgp Description: PGP signature
Re: [gentoo-dev] Proper commit messages
Markus Rothe wrote: [Tue Aug 09 2005, 07:36:18AM EDT]
Personaly I find it a little bit annoying to write changes twise.
One time in Changelog and one time in --commitmsg. How about using
the commitmsg for Changelog as default, but if a Changelog entry
already exists, then write nothing to Changelog.
A few others have posted their solutions to this problem. Perhaps
some people will find my solution useful, since it's a bit more
sophisticated. I've been using this for literally years now with no
modifications.
- handles using editor for echangelog
- fixes spacing before re-using the message for cvs commit
- post-runs eviewcvs (for the sake of pasting into bugs)
# echangelog and repoman combined
er() {
echangelog ${1:+$*} || return 1
rc
}
# repoman commit with the message from the ChangeLog
rc() {
declare msg
if [[ -n $* ]]; then
msg=$*
echo Using msg from command-line 2
else
msg=$(perl ChangeLog -0777 -pe \
's/^.*?\n \d{2} \w{3} \d{4};.*?:\n//s || exit 1; # trim top
s/\n(?:\*| \d{2} \w{3} \d{4};).*//s;# trim bottom
s/^\s*//; s/\s*$//; s/^(?: |\t)//gm;# fix spacing
#/^ /m || s/\s+/ /g; # normalize spacing unless formatted
')
if [[ $? != 0 || -z $msg ]]; then
echo couldn't parse message from ChangeLog 2
return 1
fi
echo Parsed msg from ChangeLog 2
fi
echo -- 2
echo $msg 2
echo -- 2
repoman commit -m $msg || return 1
if [[ -x /usr/bin/eviewcvs ]]; then
local f entry=$(perl -00ne '/^ \d/ and print, last' ChangeLog)
entry=${entry%%:*}
entry=${entry##*}
entry=${entry//,/ }
for f in $entry; do
[[ $f == -* ]] continue
f=${f#+}
echo $f
done | xargs -n1 eviewcvs
fi
}
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpwoTbgK9bLI.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
Catching up on your inbox, foser? ;-) foser wrote:[Mon Aug 01 2005, 01:06:10PM EDT] On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote: foser wrote:[Sat Jun 11 2005, 04:15:22AM EDT] Arch keywords are concepts and as such may not primarily be dealt as a an alphabetical list but as words in a sentence, there is no abc order in sentences. Foser, no offense intended, but you started out in this thread making a couple good points. However this is completely off the wall. The KEYWORDS list isn't a sentence. The post I replied to was full of far-fetched reasoning, I just made a similar post. Actually, later I thought maybe I understood your sentence parallel. Your point was that when the KEYWORDS list is scrambled from its original order, it loses information, similar to when the words in a sentence are scrambled. Sorry, I should have been more open-minded in my first reading. If you have to search, you'll have to scan anyway, exact position is not a guarantee for certainty because not every pack is available on every arch, it's not like you can go without scanning. Doesn't change the point that scanning in alpha order is easier than scanning append order. Last, this only holds to some extent true for people in countries with alphabetic scripts, outside that limited part of the globe people are not as proficient in ordering alphabetically. AFAIK, all Gentoo developers are fluent English speakers, even if for some it isn't their first language. Fluent, right. Try some of the cjk people. Not really. Anyway, it doesn't matter, if you didn't grown up with the alphabet, you really don't know the ordering by heart like western people do. In spoken language it doesn't matter what the order is, it is totally arbitrary. Also, realistically it's probably only 1st language for maybe half of the devs these days. IMHO (and I do mean humble, because I could be wrong) the majority of portage tree commits are coming from people who are fluent in a Western tongue. For many people the alpha ordering makes things easier, and most of the others don't care. A certain amount of uncertainty in order actually might prove to be effective in having everyone who deals with keywords actually really check all keywords and not depend on assumptions, which both 'error' cases you mention seem to be caused by. Maintaining a behavior that encourages mistakes, in hopes that the extra effort required will prevent those mistakes? This cannot possibly be a good approach... You assume here suddenly that it encourages mistakes, there is no such evidence presented here or ever was, there is however evidence to the contrary where the continues shifting of orders (within packages) caused problems (the thing I disliked about this whole situation to begin with). I actually suggest that the opposite might be true, a certain degree of uncertainty (between packages) prompts caution and might prove to be more error-free. Sure it's all a bit far fetched, but so was the post that suggested that there was some grand ergonomic idea behind this arbitrary change. You're right, I don't have evidence to present. My suspicion is that uncertainty doesn't lead to caution in this case. I didn't intend to make any more assumptions than you were making. I did not in this thread challenge the ordering (who made that up?), I challenged the way it got 'introduced'. I just got ticked off by the 'scientific basis' that suddenly was presented as the big reason behind it. To recap, it was the arbitrary /ordering change/ of a select group of individuals that created problems within packages, not the one or the other /order/. Oh, I thought for sure that you were arguing that one order was better than the other. If you weren't, why have you talked so much about it? It seems like if you don't care about the ultimate ordering, then it would be better to ignore that part of this thread, wouldn't it? Regarding the way the change was made, I apologized at the beginning of this thread and stated that I would not make a future change like that without going through a discussion first. As the maintainer of ekeyword, I made the change unilaterally without taking into account how controversial it would be. It seems like the thread could have ended there, eh? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpqkmKaXzqbk.pgp Description: PGP signature
Re: [gentoo-dev] Notice: Changing mozilla useflag to browserplugin for all Java runtimes
Karl, Diego has mentioned that the nsplugins USE-flag already exists and seems to duplicate browserplugin. Additionally it is more appropriate since it refers specifically to netscape-compatible plugins, which is definitely what these are. If there's another plugin format, it probably shouldn't be handled by the same USE-flag. I haven't seen a response from you regarding this. What are your thoughts? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp7wnuAWk49B.pgp Description: PGP signature
Re: [gentoo-dev] Notice: Changing mozilla useflag to browserplugin for all Java runtimes
Chris Gianelloni wrote:[Tue Jul 12 2005, 11:53:57AM EDT] On Tue, 2005-07-12 at 11:41 -0400, Aron Griffis wrote: Karl, ... What are your thoughts? use nsplugin? Chris, since when are you Karl? :-b Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpDg8M3IkBtQ.pgp Description: PGP signature
Re: [gentoo-dev] Notice: Changing mozilla useflag to browserplugin for all Java runtimes
KarlTK wrote: [Mon Jul 11 2005, 09:13:03AM EDT] over the course of the next few days, we will finally be replacing the 'mozilla' useflag in all the Java runtimes with a new USE flag, called 'browserplugin'. I think I can speak for the mozilla team... this change looks good. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpzzTOse0cYj.pgp Description: PGP signature
Re: [gentoo-dev] Notice: Changing mozilla useflag to browserplugin for all Java runtimes
Diego 'Flameeyes' Pettenò wrote:[Mon Jul 11 2005, 03:25:22PM EDT] profiles/use.local.desc:app-text/djvu:nsplugin - Builds plugins for Netscape compatible browsers We already have this that is the same at the end. This looks like the right thing to do instead of the browserplugin USE-flag. Karl, does this make sense from your perspective for the java stuff? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpS5vPFdFhef.pgp Description: PGP signature
Re: [gentoo-dev] Notice: Changing mozilla useflag to browserplugin for all Java runtimes
Stefan Schweizer wrote: [Mon Jul 11 2005, 12:38:46PM EDT] Are you expecting the other browser-plugin-ebuilds to follow this step? acroread makes sense here gplflash, netscape-flash, netscape-plugger, mozplugger, mplayerplug-in? These are all plugins by definition, there's nothing to do here. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpr4Wf76l8Kq.pgp Description: PGP signature
[gentoo-dev] IUSE and eclasses
Current (possibly unwritten) policy: - eclasses declare USE-flags they honor in their own IUSE - ebuilds declare USE-flags they honor in their own IUSE - ebuilds do not declare USE-flags honored by eclasses they inherit This policy has been around for a while. It assumes that all the flags honored by an eclass are likewise honored by all the ebuilds that inherit that eclass. Of course this assumption is false. An eclass might provide a function install_docs that calls, for example, use doc. The ebuild inheriting the eclass might not call install_docs. In that case, if IUSE=doc in the eclass, it will be inaccurately displayed when doing emerge -pv of the package. The other possibility is to push IUSE declarations completely into the ebuild. In that case, it becomes a maintenance headache since an update to the eclass might necessitate a cascading update to all the ebuilds. Hence the current policy, however inaccurate the results might be. So right now the policy is broken, but the apparent alternative is unmanageable. Ideas? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpkKPYjeiMnW.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and eclasses
Robin H. Johnson wrote: [Thu Jul 07 2005, 05:07:06PM EDT] On Thu, Jul 07, 2005 at 04:49:13PM -0400, Aron Griffis wrote: Current (possibly unwritten) policy: - eclasses declare USE-flags they honor in their own IUSE - ebuilds declare USE-flags they honor in their own IUSE - ebuilds do not declare USE-flags honored by eclasses they inherit The policy itself is almost fine, it's the checking we need to improve. The only policy problem case that is where an eclass has a flag declared, but the ebuild doesn't use that part of the eclass at all, on purpose. Either the ebuild/eclass should be changed, or we should have a way to take flags out of IUSE further down the line. I don't think the last suggestion makes sense. It adds complexity to IUSE declarations while increasing the linkage between eclasses and ebuilds. It's not much better to remove IUSE flags when they aren't used than to add them when they are used... So right now the policy is broken, but the apparent alternative is unmanageable. Ideas? Before changing more, it would be good to have some proper repoman checks for this stuff. Before changing more what? It should be easily doable, as there are only a few proper ways to use USE flags in your ebuild. This would also help catch ebuilds/eclasses not declaring IUSE properly, or having old stuff in IUSE that isn't actually used anymore. The only official ways to use USE flags are (at least to my knowledge): use FLAG usev FLAG useq FLAG use_enable FLAG use_with FLAG The more complex eclasses have front-ends to USE, for example php and mozconfig. I think you will quickly find that it is not that easily doable to catch this stuff in repoman, though it could certainly be improved. If you're going to teach repoman to read ebuilds and eclasses, create a call graph, trace it for USE-flags, and generate what repoman thinks IUSE should be... well, suffice it to say I don't see this happening soon. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpzFXhRg1K1o.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and eclasses
Vapier wrote: [Thu Jul 07 2005, 06:13:06PM EDT] On Thursday 07 July 2005 04:49 pm, Aron Griffis wrote: Current (possibly unwritten) policy: - eclasses declare USE-flags they honor in their own IUSE - ebuilds declare USE-flags they honor in their own IUSE - ebuilds do not declare USE-flags honored by eclasses they inherit err this third one i dont think we do ... eclasses declare their own stuff and ebuilds declare their own ... it's a black box like it should be ... Sorry, my last bullet point was unclear. I meant what you're saying. Of course this assumption is false. An eclass might provide a function install_docs that calls, for example, use doc. The ebuild inheriting the eclass might not call install_docs. In that case, if IUSE=doc in the eclass, it will be inaccurately displayed when doing emerge -pv of the package. does this really come up all that often that it needs to be handled? seems like a lot of effort for little gain ... You're right... it probably doesn't matter. It's just annoying. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpZ5ZVEsHfXh.pgp Description: PGP signature
Re: [gentoo-dev] inetd/xinetd useflags
Vapier wrote: [Tue Jul 05 2005, 07:26:26PM EDT] so what we should do? Add a global xinetd useflag and a doxinetd function to add/remove the installed config files? Yeah i know they aren't so big.. but the less, the best. personally i'd support a doxinetd func that would check to see if xinetd is installed rather than go with a USE flag ... No, the USE flag is the right way. Otherwise it's an environmental dependency, exactly the thing we try to avoid. Diego: what is the content of doxinetd? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpGMgrheSOMh.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Kathryn Kulick (GothGirl)
Aaron Walker wrote: [Wed Jul 06 2005, 08:46:23AM EDT] Allow me to introduce the newest addition to our team. Her name is Kathryn Kulick aka GothGirl. She's from New Orleans, Louisiana, but is currently living in Baton Rouge. She is a mother of 3 children. With her addition, there is now one more husband/wife developer team (the other half being Anarchy). Who is the other husband/wife developer team? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpYvio4T0o9p.pgp Description: PGP signature
Re: [gentoo-dev] inetd/xinetd useflags
Maurice van der Pot wrote: [Wed Jul 06 2005, 02:20:15PM EDT] If we do it for xinetd files, we should also do it for logrotate files. Agreed. FWIW, I'd like to see xinetd and logrotate in default USE for the profiles since otherwise it would be a pain to go through and remerge things after putting them in make.conf Aron -- Aron Griffis Gentoo Linux Developer pgpPmGMQiLPhK.pgp Description: PGP signature
Re: [gentoo-dev] use.desc and use.local.desc cleanup
Azarah wrote: [Tue Jul 05 2005, 09:39:20PM EDT] As far as I know many of these are still in use .. Aron ? Some were, some weren't. All the moz stuff is fixed up now. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpnWQYgeUOxd.pgp Description: PGP signature
Re: [gentoo-dev] Package moves as repocopies
Robin H. Johnson wrote:[Sat Jul 02 2005, 02:47:48PM EDT] After such a move of directories, CVS clients running their next update would find NO record of the old directory when they attempted to update it, and the CVS client would then NOT touch the local copy at all. So copy it instead of moving it, then do a proper cvs rm on the old one. Package moving/renaming with history following is a worthwhile feature to pursue. Nobody wants to go digging through various directories to track down package history, especially if the package has moved or been renamed more than once. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpmnbPrEMWBy.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
Dan Armak wrote:[Fri Jul 01 2005, 10:45:57AM EDT] Would work, but be against the general move to make the general ebuild section purely declarative :-( Ok, but DEPEND=$(some-function) is no more declarative. The function is evaluated at the time that the ebuild is read, not later when DEPEND is processed. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgplQXYUI4PWe.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
Caleb Tennis wrote:[Fri Jul 01 2005, 10:48:38AM EDT] On Friday 01 July 2005 08:56 am, Aron Griffis wrote: How about this? ebuild: DEPEND=some stuff qt_min_dep 3.3 How do you handle the ebuilds which use the qt use flag to determine whether or not that qt is a dependency? Bah, good point. I knew it was too easy. :-) It seems like at this point there is one good suggestion on the table for an immediate fix: DEPEND=... || die Of course we all want more flexible DEPEND processing in portage, but another avenue of research for somebody is to read the ebuilds (not necessarily execute the functions) with set -e. That doesn't solve the problem quickly enough for you, since it requires a portage change, but it would solve the general problem of calling functions from strings (so long as you only call one!) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpOnRcudN3AM.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
Dan Armak wrote:[Thu Jun 30 2005, 04:06:03PM EDT] Because the function takes a parameter - the minimal version required from which to start the list in the ||. Makes sense. Any everyone who thinks functions inside $DEPEND are iffy should look at deprange() and deprange-dual()... /me hides They're definitely iffy. Try this at a bash prompt: DEPEND=$(exit 1) See the problem? It didn't exit. That's what will happen if a function in DEPEND fails: nothing. Except that yours will currently stick this in DEPEND: !!! error: qt_min_version called with invalid parameter: \$1\, please report bug Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpExPqVfjVEn.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Diego 'Flameeyes' Pettenò wrote:[Fri Jun 17 2005, 10:05:32AM EDT] On Friday 17 June 2005 04:32, Aron Griffis wrote: Before working on a solution to the problem, could we get a more complete list of the tools in question? This has come up before but the list seems to always end with etc etc ;-) Because I don't really know how many applications are available in different flavours.. so that's why we can use eselect so that it can be adapted on the fly. I'm not against using eselect to choose between applications, if that is the right answer. I'm against getting started on these changes without having a better idea of the scope and impact of the project. In other words, I think you need to do some work in an overlay so that you can present a real list of affected ebuilds and utilites, rather than stating that you don't really know I appreciate that you brought this idea to the list early, before you had done full investigation. I do not want to discourage you. Rather I want to suggest the next step is a more complete investigation, rather than committing any changes to the portage tree. One of the problems we've had with ports in general is that changes are committed in a flurry of activity before careful consideration of the possible alternatives. Unless I misunderstand you, I don't like this at all. It means that when an ebuild calls grep it doesn't have any idea what the supported flags are. Well about grep we have no misunderstanding... grep is GNU grep also on the BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we condition this using aliases, but the long-term goal is to avoid this. Why is that a long-term goal? What are the advantages/disadvantages of the eselect method compared to the aliases? What scripts are you thinking of in this statement? Sometimes ./configure checks, not always, and AFAIK most other scripts don't check. Most of them checks for GNU tools when they need them, for example there are a few ./configure which, knowing they need GNU make, in a system where make is BSD and gmake is GNU, launching make then exec gmake to do the actual work. *nod* It's true that the autotools generally work with make programs other than GNU make. I ported Gnome (versions 1.2 and 1.4) to Tru64 once upon a time and used the system-installed make (and compiler) for most of it. I still think it would be nice to have a list of things that will need modification to work with your scheme. Again, this is something that could be culled from an overlay from which you've done a bootstrap and install of a fairly comprehensive system. See, it's this sed stuff is as compatible as possible thing I don't like. You're talking about writing to a standard instead of an implementation. That works for a couple of well-defined compiled languages, but I don't think it's going to work for shell scripting (ebuilds), especially when the reality is that we'd be writing to half a dozen different implementations instead of a standard at all... See above: when we need GNU sed, we can use gsed. As Az mentioned, this is really going to be annoying unless all the sed programs available support -i I'll re-iterate: I'm not trying to shoot down this idea completely. I just want to have a general understanding that it's the *right* option before making treewide changes. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpsy8TNSPwjF.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT] You might however say install all gnuish tools with the 'g' prefix, and then install wrapper scripts/stubs into say /usr/bin/gnu/ or /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage just adds this path as the first path to $PATH ... This should cover the fact that aliases might not work in all cases, and is bsd specific implementation. That would actually cause a lot of problems because the PATH would be inherited by configure and/or make. The result is that programs get GNU tools when they are built, but BSD tools at run-time. I can only imagine that causing a lot of confusion. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpZWKlpp3S9M.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Diego 'Flameeyes' Petten wrote:[Thu Jun 16 2005, 01:57:14AM EDT]
Let me explain: on Gentoo/Linux systems, all the base utilities
(make, tar, sed, etc etc) are GNUish
Before working on a solution to the problem, could we get a more
complete list of the tools in question? This has come up before but
the list seems to always end with etc etc ;-)
This limits a bit the user because to use other kind of utilities it
must use aliases and he can't change, for example, the tar used by
portage or by other scripts.
As eselect's work is proceeding it can be interesting having a way
to have the base utils install with a prefix (g for GNU stuff, bsd
for BSD stuff, eventually fbsd/obsd/nbsd if they are different) and
then having a link to the basename which acn be changed with
eselect.
Unless I misunderstand you, I don't like this at all. It means that
when an ebuild calls grep it doesn't have any idea what the
supported flags are. Writing shell scripts to the lowest common
denominator is incredibly painful; just ask the maintainer of
keychain. So far we've been free to exploit GNU extensions (aka
reasonable functionality) in ebuilds. I'd hate to see that go away.
Personally I'd prefer to see the selection continue to happen at the
user level (via alias or PATH) rather than happening at the system
level via eselect. I'm all for eselect, but not for programmatic
interfaces that only nominally resemble each other.
Btw, this has been solved in the commercial UNIXes for SysV versus
BSD utils for a long time. Most of the time SysV utils are installed
in /usr/bin and the BSD utils are installed in /usr/ucb. I'm not
saying we have to follow that pattern exactly, but I like the fact
that /usr/bin/grep is always the same thing (on a given UNIX)
Most of the scripts which needs a specific syntax (usually GNU
syntax) already checks for prefixed executables like gmake, gsed and
so on,
What scripts are you thinking of in this statement? Sometimes
./configure checks, not always, and AFAIK most other scripts don't
check.
but the main problem is with portage (think of all the make
DESTDIR=${D} install stuff), also if emake is fixed and sed stuff
is as compatible as possible.
See, it's this sed stuff is as compatible as possible thing I don't
like. You're talking about writing to a standard instead of an
implementation. That works for a couple of well-defined compiled
languages, but I don't think it's going to work for shell scripting
(ebuilds), especially when the reality is that we'd be writing to half
a dozen different implementations instead of a standard at all...
Having to provide compatibility with such a framework is quite
difficult at this point because many ebuilds does depend on GNU
syntax also if not clearly stated, but I hope this can be fixed
step-by-step using g-prefixed commands (after making sure that all
systems will have g-prefixed commands). It's not like something is
going to happen soon, but maybe in the future this can be a good way
to make sure we expand the abiliy of users to select what they
really want.
I don't think that switching to g-prefixed commands for GNU utilities
is a good answer. We aren't going to be able to push that upstream,
which means maintaining a lot of patches ourselves. Within our own
developer body, we're going to have an impossible task keeping things
compatible since few people have the knowledge required to write
truly cross-platform scripts.
I know this isn't offering an easy answer for the BSD folks. :-(
What you're suggesting would cause a lot of pain for the majority of
Gentoo develpers, i.e. the ones running GNU/Linux. Let's think it
through very carefully so we understand our options before setting
down this path.
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpBd6FuDmvwa.pgp
Description: PGP signature
[gentoo-dev] master-metastructure2005
Here is the master ballot for the metastructure2005 election. I will send out individual emails with confirmation numbers shortly. Regards, Aron -- Aron Griffis Gentoo Linux Developer - confirmation 28b6 - Oldschool-small Oldschool-small-with-slacker-boot Task-force Keep-current Alternative FOSDEM - confirmation 28d2 - FOSDEM Oldschool-large Oldschool-small Oldschool-small-with-slacker-boot Task-force Reopen-nominations Keep-current Alternative Oldschool-large-with-slacker-boot - confirmation 2e09 - Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Oldschool-large Oldschool-small Reopen-nominations Task-force FOSDEM Alternative Keep-current - confirmation 3010 - Alternative FOSDEM Oldschool-large Oldschool-small Keep-current Oldschool-large-with-slacker-boot Task-force Oldschool-small-with-slacker-boot Reopen-nominations - confirmation 3012 - Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Oldschool-small Oldschool-large Alternative FOSDEM Reopen-nominations Keep-current Task-force - confirmation 31f2 - Oldschool-small-with-slacker-boot Oldschool-small Keep-current Reopen-nominations Oldschool-large-with-slacker-boot Oldschool-large Task-force Alternative FOSDEM - confirmation 321e - Alternative Oldschool-small-with-slacker-boot Oldschool-small Oldschool-large-with-slacker-boot Oldschool-large FOSDEM Task-force Reopen-nominations Keep-current - confirmation 051d - Oldschool-small-with-slacker-boot Oldschool-small FOSDEM Oldschool-large-with-slacker-boot Oldschool-large Alternative Task-force Keep-current Reopen-nominations - confirmation 0522 - Oldschool-small Oldschool-large Alternative FOSDEM Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Task-force Keep-current Reopen-nominations - confirmation 33b2 - Oldschool-small-with-slacker-boot - confirmation 340e - Alternative FOSDEM Task-force - confirmation 3441 - Task-force Oldschool-small Oldschool-large Alternative FOSDEM Keep-current Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Reopen-nominations - confirmation 3dad - Oldschool-small-with-slacker-boot Oldschool-small Oldschool-large-with-slacker-boot Oldschool-large Alternative Task-force Reopen-nominations FOSDEM Keep-current - confirmation 3e94 - Task-force Oldschool-small-with-slacker-boot Oldschool-small Alternative FOSDEM Oldschool-large-with-slacker-boot Oldschool-large Reopen-nominations Keep-current - confirmation 3f23 - Keep-current FOSDEM Alternative Oldschool-small Oldschool-large Reopen-nominations Oldschool-large-with-slacker-boot Oldschool-small-with-slacker-boot Task-force - confirmation 3ff4 - Oldschool-large-with-slacker-boot Oldschool-small-with-slacker-boot Oldschool-large Oldschool-small Alternative FOSDEM Task-force Keep-current Reopen-nominations - confirmation 4038 - Oldschool-small-with-slacker-boot Oldschool-small Alternative FOSDEM Reopen-nominations Keep-current Task-force Oldschool-large-with-slacker-boot Oldschool-large - confirmation 427f - Task-force Oldschool-small Alternative Reopen-nominations Oldschool-large Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot FOSDEM Keep-current - confirmation 4a21 - FOSDEM Alternative Oldschool-small Reopen-nominations Keep-current Task-force Oldschool-small-with-slacker-boot Oldschool-large Oldschool-large-with-slacker-boot - confirmation 4bb8 - Oldschool-small Keep-current Oldschool-large Oldschool-small-with-slacker-boot Alternative FOSDEM Task-force Reopen-nominations Oldschool-large-with-slacker-boot - confirmation 4d17 - Keep-current Reopen-nominations Alternative FOSDEM Oldschool-small Task-force Oldschool-large-with-slacker-boot Oldschool-small-with-slacker-boot Oldschool-large - confirmation 4e46 - Alternative FOSDEM Oldschool-small Oldschool-large Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Keep-current Task-force Reopen-nominations - confirmation 5069 - Oldschool-small-with-slacker-boot Oldschool-small Oldschool-large-with-slacker-boot Alternative Reopen-nominations Keep-current Task-force Oldschool-large FOSDEM - confirmation 53e2 - Oldschool-small Oldschool-large Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot FOSDEM Keep-current Alternative Reopen-nominations Task-force - confirmation 5426 - Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot Oldschool-small Oldschool-large Alternative FOSDEM Task-force Reopen-nominations Keep-current - confirmation 57de - FOSDEM Alternative Oldschool-small Oldschool-large Oldschool-small-with-slacker-boot Oldschool
[gentoo-dev] Re: [gentoo-core] Metastructure vote preliminary results
Following up as an election official... The results Grant posted are the same as I got. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpJAqOi44Ac5.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
Georgi Georgiev wrote: [Fri Jun 10 2005, 08:04:25PM EDT]
maillog: 10/06/2005-13:19:30(-0400): Aron Griffis types
Btw, here's an interesting statistic which really doesn't add to (or
detract from, I hope) this discussion...
grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if @F eq
@S;
END { printf %d%% of ebuilds are sorted (%d/%d)\n, 100*$sorted/$.,
$sorted, $. }'
49% of ebuilds are sorted (9435/19174)
Your statistic seems to be flawed on a number of occasions. Assume
KEYWORDS=x86 ppc
s/[^[:lower:]\s]//;
You wrote a long email to tell me that I forgot /g, I think. ;-)
grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
s/[^[:lower:]\s]//g; @F = split; @S = sort @F; $sorted++ if @F eq @S;
END { printf %d%% of ebuilds are sorted (%d/%d)\n, 100*$sorted/$.,
$sorted, $. }'
31% of ebuilds are sorted (6028/19185)
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpZ6ZSh63rtv.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
foser wrote:[Sat Jun 11 2005, 04:15:22AM EDT] Arch keywords are concepts and as such may not primarily be dealt as a an alphabetical list but as words in a sentence, there is no abc order in sentences. Foser, no offense intended, but you started out in this thread making a couple good points. However this is completely off the wall. The KEYWORDS list isn't a sentence. If you have to search, you'll have to scan anyway, exact position is not a guarantee for certainty because not every pack is available on every arch, it's not like you can go without scanning. Doesn't change the point that scanning in alpha order is easier than scanning append order. Last, this only holds to some extent true for people in countries with alphabetic scripts, outside that limited part of the globe people are not as proficient in ordering alphabetically. AFAIK, all Gentoo developers are fluent English speakers, even if for some it isn't their first language. A certain amount of uncertainty in order actually might prove to be effective in having everyone who deals with keywords actually really check all keywords and not depend on assumptions, which both 'error' cases you mention seem to be caused by. Maintaining a behavior that encourages mistakes, in hopes that the extra effort required will prevent those mistakes? This cannot possibly be a good approach... IMHO the discussion in this thread has brought at least two things to light, though I'm still open to rebuttal of course: 1. Potentially controversial tool changes that affect a large number of developers should be discussed on -dev before deployment. This is something I intend to do in the future. 2. In the case at hand, most developers prefer alpha order, and there is not good reason for reverting the ekeyword change. I still don't have the right to make this decision unilaterally, though, so if foser or anybody else wants to take this before the managers and request a vote, that is cool. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpbgFRkLvcon.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
foser wrote:[Fri Jun 10 2005, 10:55:17AM EDT]
As the threadstarter indicated, this was done without discussing it
and in the knowledge that there was no agreement on this issue. As
said before, the fact that something gets done some way, doesn't
mean it's right to do it that way.
Not to dilute your point, which is well taken, but I'm curious how
much discretion the tool author has to make decisions independently?
See earlier replies : unneeded arbitrarily introduced inconsistency. I
don't know why people are defending that move, even vapier indicates
that there really is no reason to do it alphabetically, except maybe
that he now knows to look in the keywords string, which is of course a
bit far fetched with all arch keywords not being set for all different
packs (so he still has to look at different points in different packs)
and was not brought up as a defence of his particular move at the time
he started doing this.
If all the keywords in the tree were alphabetical, would that have any
impact on the compressibility of the tree?
Oh no doubt, I'm concerned about the inconsistency mostly. The
maintainers arch is a concept that I do not necessarily associate
with the keywords ordering anymore (although it may have been
a reasonable indicator in the past), it actually really makes this
discussion fuzzier than it has to be.
Sorry, I didn't mean to confuse the issue by bringing that up.
My point is more about how this got 'introduced' as a mindset and
that such unguided behaviour gets reinforced by this discussion, now
up to IUSE ordering changes and next we'll tackle inheritance order.
Agreed, it was a bad decision on my part to make the change without
discussing on this ML. That's something I will try to not repeat in
the future.
Btw, here's an interesting statistic which really doesn't add to (or
detract from, I hope) this discussion...
grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if @F eq @S;
END { printf %d%% of ebuilds are sorted (%d/%d)\n, 100*$sorted/$.,
$sorted, $. }'
49% of ebuilds are sorted (9435/19174)
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpj6bi999Fhg.pgp
Description: PGP signature
Re: [gentoo-dev] Announcing Gentoo Universe
Daniel Drake wrote: [Fri Jun 10 2005, 02:01:14PM EDT] If you host your weblog at http://planet.gentoo.org/developers How does one get signed up to host a weblog there? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpTvAhZdS9GJ.pgp Description: PGP signature
Re: [gentoo-dev] where goes Gentoo?
Stuart Herbert wrote: [Thu Jun 09 2005, 06:32:04PM EDT] I'd like Gentoo to be a place where neat things are developed. Aren't we really a place where neat things are packaged up? Hopefully both! :-) Regarding the rest of your email, I don't disagree. I think that if you read my follow-ups in the thread, you'll find that I addressed or responded to a number of the same ideas. I'll be the first to admit that my initial thoughts were not a complete picture of the world, just a limited perspective and some food for thought... Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp3xT1TrXfG7.pgp Description: PGP signature
Re: [gentoo-dev] where goes Gentoo?
subproject formed in Gentoo, I'd like to see their methods be similar. Develop tools that make it easier to manage and maintain an enterprise deployment, without changing how Gentoo is currently developed. Without hoisting new expectations on the Gentoo developers, release process, etc. Wow... as a sysadmin who has run Gentoo in some very high profile production systems that's a bit offensive to think I used it outside of a hobbyist platform.. IBM didn't just donate a $30k system for ppc64 development to make it better for someone's basement use, so I don't think I'm alone in thinking that Gentoo is above hobbyist. I did not intend hobbyist to be disparaging. I think that the big companies (including HP, who has also donated tens of thousands of dollars of equipment btw) see a lot of potential in Gentoo. Gentoo is already a fun distribution.. I don't think that has to change to meet enterprise goals. Great! I think we are closer in our perspectives than it seems. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpR6IML82cLS.pgp Description: PGP signature
Re: [gentoo-dev] where goes Gentoo?
Aron Griffis wrote:[Tue Jun 07 2005, 11:08:58AM EDT] I think that the big companies (including HP, who has also donated tens of thousands of dollars of equipment btw) see a lot of potential in Gentoo. Btw, as an hp employee I hope you'll forgive me for tooting the hp horn a little bit... I know there are other companies donating resources and I'm not trying to one-up them. In addition to the equipment hp has lent, part of my job description is to work on Gentoo. No strings attached, no agenda. This is viewed as positive community involvement by the hp Open Source and Linux Org. I spend *at least* 1/3 of my time working on Gentoo. Without getting into a salary discussion, that's hp donating tens of thousands of dollars per year. Now whether you all consider my involvement to be worth that much is a different matter, of course. No comments from the peanut gallery, please. ;-) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpUhSRwaG3CE.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
Michael Cummings wrote:[Tue Jun 07 2005, 12:49:21PM EDT]
HA! Oh man, I needed a good chuckle. cvs log is about the only
nearly reliable thing I have found sometimes - seems folks that
don't like to use metadata.xml when commiting a random package also
avoid using ChangeLogs. Go figure.
I guess I haven't run into as much of that as you have. I have
a couple of functions that make this easy for me. Here is the usage
if anybody is interested:
ek - short for ekeyword
er - run echangelog, then call rc automatically
rc - repoman commit with the most recent message pulled from the
ChangeLog
So in general I do something like this:
$ ek alpha ia64 blah.ebuild
$ er stable on alpha, ia64
If repoman doesn't allow me to commit for one reason or another, I'll
fix the problem, then simply run rc to retry the commit with the
same message.
Here are the function definitions:
# ek: ekeyword
alias ek=ekeyword
# echangelog and repoman combined
er() {
echangelog ${1:+$*} || return 1
rc
}
# repoman commit with the message from the ChangeLog
rc() {
declare msg out
if [[ -n $* ]]; then
msg=$*
echo Using msg from command-line 2
else
msg=$(perl ChangeLog -0777 -pe \
's/^.*?\n \d{2} \w{3} \d{4};.*?:\n//s || exit 1; # trim top
s/\n(?:\*| \d{2} \w{3} \d{4};).*//s;# trim bottom
s/^\s*//; s/\s*$//; s/^(?: |\t)//gm;# fix spacing
')
if [[ $? != 0 || -z $msg ]]; then
echo couldn't parse message from ChangeLog 2
return 1
fi
echo Parsed msg from ChangeLog 2
fi
echo -- 2
echo $msg 2
echo -- 2
repoman commit -m $msg || return 1
if [[ -x /usr/bin/eviewcvs ]]; then
local f entry=$(perl -00ne '/^ \d/ and print, last' ChangeLog)
entry=${entry%%:*}
entry=${entry##*}
entry=${entry//,/ }
for f in $entry; do
[[ $f == -* ]] continue
echo ${f#+}
done | xargs eviewcvs
fi
}
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpbPWn4KXVtk.pgp
Description: PGP signature
Re: [gentoo-dev] where goes Gentoo?
Hello, A user wrote to me personally: i thought several times if i wanted to reply at all, and after i wrote my mail if i really should send it out. I finally decided to send it off list since this might just end up in flames on the list. I hope you don't mind I'm putting this back on the list. If you are concerned, then there are probably others in the same boat. Hopefully my response below will ease their concerns as well as yours. So here it is: On Mon, Jun 06, 2005 at 07:55:50PM -0400, Aron Griffis wrote: Also I find it amusing when people say that Gentoo exists for the users. I think that is wrong. Gentoo exists for the *developers*. It's our playground, and it's the reason we use a live tree rather than switching to an actually sane approach. The users are cool because they point out bugs, help solve problems on bugzilla, suggest enhancements, provide patches, and notify us of package updates. Sometimes they become developers. But the truth is that Gentoo sees improvement and maintenance in the areas that appeal to the developers. And that is why Gentoo exists for the developers first, the users second. Sheesh, i really don't know what to say. I really don't have a problem with developers having fun by doing their work, but a linux _distribution_ is probably one things intended most directly at users. I've been a user for a long time, and i always tried to give something back by filing bug reports or helping other users. I had the feeling my contribution was welcome and i never wanted to leech the guys doing development off. As for today, i can say pretty sure i've given quite an amount of time (and even some money) to Gentoo. I've had my share of fun with it, but seeing you dividing people involved in Gentoo into developers (good, have fun, their playground) and users (bad, but we'll have to live with them) really makes me speechless. Gentoo should be there for everyone disregarding if he's developer or not. If you don't like that, turn of the rsync mirrors and let only devs check out the tree. ;-) Maybe i've just gotten your statement really wrong, but as far i understand it, i really have a bad feeling about it. I entirely see your point, and I'm sorry if I gave you the wrong impression. I really appreciate your contributions, and I take pride in helping to fix bugs that affect you and other users. I think it's great that Gentoo is a distribution that has such a welcoming reputation. My point was not that I don't care about users. It was that the developers working on Gentoo are ultimately here because it's a fun project. We decide our own priorities, and none of us is completely self-sacrificial. The areas that see real improvement are the areas that are interesting to the developers. This is a contrast from the commercial distributions, which see improvement in the areas that customers demand, or which management perceives as adding value. Let me give you an example: epm. I wrote epm, a work-alike to rpm. A lot of people use it, and I've gotten a number of feature requests in bugzilla. In response, I often request a patch, then eventually close the bug because no patch is forthcoming. If I were working for paying customers, this would not be an option (provided the feature requests were reasonable). It would be my *responsibility* to cater to the request. In Gentoo, however, developers are able to use their own discretion. This is what I am talking about. (Psst... I'll let you in on a little secret. It doesn't have to be a good patch. If a user gives me a really crappy patch, I'll usually work on an implementation just because I appreciate that they made an effort. Heck, even a detailed and thoughtful description will usually suffice... ;-) I hope that this clears up your confusion and puts us on the same team again. Best regards, Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Minimal perl install (stage1/livecd makers might be interested?)
Robin H. Johnson wrote:[Tue Jun 07 2005, 03:04:43PM EDT]
OpenSSL mainly uses perl to generate the assembly language versions
of it's commands, in an almost portable fashion. There are also
a few other scripts written in perl, but again, they don't use any
modules from my examination.
This isn't always an option... but how hard would it be to rewrite
that stuff in awk or sed?
I did something similar in mozconfig.eclass. There is a long /bin/csh
script that is part of the mozilla build process. It used to create
a dependecy from mozilla on csh... I replaced it with this:
# Simulate the silly csh makemake script
makemake() {
typeset m topdir
for m in $(find . -name Makefile.in); do
topdir=$(echo $m | sed -r 's:[^/]+:..:g')
sed -e s:@srcdir@:.:g -e s:@top_srcdir@:${topdir}:g \
${m} ${m%.in} || die sed ${m} failed
done
}
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpUDP0gzxe0t.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT] I also vote for alpha. I would like to see some indication of maintainer arch in metadata too, but in general agree with the policy of if one arch stabilises then we can assume that is the maintainer arch. Whoa, careful there. It's not a policy and it's not even a recommendation. I believe there are arch teams that will automatically stable a package after it has been ~arch for a period of time. They will break your assumption. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpZTG9cfvzFC.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
Olivier Crete wrote:[Tue Jun 07 2005, 05:56:35PM EDT] Are you sure its not a policy? Fairly certain. It's been discussed around in circles in the past. Because it should be and it has been discussed before. Arch teams should NOT get ahead of the maintainer without his permission... or if they really really know what they are doing. Maintainers normally know their package/ebuilds and often have very good reasons to keep a package ~arch for more than 30 days.. Ciaran would have something to say about this, along the lines of some packages sitting idle in ~arch state because the maintainer isn't really paying attention. In that case, who can really blame an arch team for moving ahead on their own? Your statements make a lot of sense, and yes, it's how one would assume things work. But perspective can change when you're working on an architecture and losing patience with package maintainers. In practice, arch maintainers gradually learn what packages are well-maintained and what packages they stabilize without prior maintainer approval. A good example is foser's shepherding of gnome... in general the arches wait for his lead before stabilizing. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpYXfku3HAzi.pgp Description: PGP signature
Re: [gentoo-dev] where goes Gentoo?
Chris Gianelloni wrote: [Tue Jun 07 2005, 06:38:41PM EDT] ...and you *still* haven't gotten an ia64 livecd built? For shame! SO TRUE. -- Aron Griffis Gentoo Linux Developer pgpEkE2r8zFYM.pgp Description: PGP signature
[gentoo-dev] ekeyword and ordering
Hi guys, As some of you have noticed, I made a change recently in ekeyword that causes ekeyword to alphabetize the keywords. I've realized I should have brought it up for discussion before making the change to the program. On that note, I apologize for unilaterally making that change without consulting the developer body for opinions. Here is the the fuzzy history of keywording in a nutshell. Please bear in mind that these bullet points happened over a period of years. - Daniel originally wanted them alphabetized. - A few people, myself included, pointed out that there's some valuable information available when keywords are always added to the end rather than being alphabetized. In particular, the concept of a maintainer arch is possible, in which the first arch in the list is supposed to indicate general stability of the ebuild, a leader for other arches to follow. - Some people disagreed with the maintainer arch concept. They felt that the arch teams do a better job of testing than some maintainers, and there's no point waiting for a maintainer to decide something is stable. - Some developers recently mentioned to me that alphabetizing would probably be fine. At this point I felt that the tree was diluted enough that there was no point resisting, so I went ahead and made the change silently. - My action was questioned privately on IRC, and I realized I made the decision without proper discussion. So I'm writing this email. Honestly, the arguments aren't very strong in either direction. I think everybody understands this, but nonetheless people have their preferences. Here are some of the basic arguments: alpha - - looks nicer (subjective) - easier to tell at a glance if a given keyword is in the list append - - slightly less cvs/rsync traffic - allows maintainer arch to continue until another solution is produced, for those who still depend on that method - some developers are accustomed to the append method and don't want things to change, at least not without discussion I am willing to revert the ekeyword change if that is what devs would prefer, but I won't make the change without a discussion on -dev, which was my mistake last time. Your thoughts? If the thread isn't obviously unified one direction or the other, I guess we'll eventually put this up to a developer or manager vote (I'm not sure which is appropriate) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp0nPu192mu6.pgp Description: PGP signature
[gentoo-dev] where goes Gentoo?
This is kinda bloggish, because it's basically a transcription of an IRC monologue. My apologies if it's hard to follow... Nonetheless, I'm interested in how other developers feel on the topics I bring up below. There have been some really interesting points brought up recently about where is Gentoo going? I have been wondering that myself. Some people seem to think that Gentoo has the potential to be an enterprise player. I have not responded directly to those people, but I wonder if they know what they mean. I have worked in the enterprise UNIX market for 6 years. My code is running in places like NASA mission control, 9-1-1 call centers, and most of the telephone carriers. I've produced patches on weekends to close $800m deals. I now work in hp's Open Source and Linux Organization, mostly on RHEL and SLES, so I have a good idea of what it takes to be an enterprise player. In my humble opinion, Gentoo is missing too many points to be an enterprise Linux. We commit to a live tree. We don't have true QA, testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. We don't really have product lifecycles, since we don't generally backport fixes to older versions, requiring instead for people to update to a more recent release. We don't have, and probably will never be able to offer, support contracts. We support as wide a range of hardware as the upstream kernel, plus hardware that requires external drivers; we don't have access to a great deal of the hardware for which we provide drivers. We understand when real life gets in the way of bug-fixing, because all our developers are volunteers. I think that attempting to take Gentoo in the enterprise direction is a mistake. I think that we are a hobbyist distribution. This doesn't mean that we should not strive to meet some of the enterprise goals. Those things can be important to hobbyists too. But I don't think we should be aiming for corporate America. I don't even understand why that goal appeals to people. Let other distros go there! I want Gentoo to run in people's homes, in student dorm rooms, etc. Places where people want a fun distribution that they can tailor and work on easily. I like the idea of Gentoo on alternative arches and in embedded environments. Not because I want Sony to start using Gentoo on walkmans, but purely because the idea of running Linux on a PDA is cool. I'd like Gentoo to be a place where neat things are developed. If RH or SuSE (or another for-profit Linux vendor) wants to take some of those developments and use them to make a profit, that's fine with me. We're over here having fun. Also I find it amusing when people say that Gentoo exists for the users. I think that is wrong. Gentoo exists for the *developers*. It's our playground, and it's the reason we use a live tree rather than switching to an actually sane approach. The users are cool because they point out bugs, help solve problems on bugzilla, suggest enhancements, provide patches, and notify us of package updates. Sometimes they become developers. But the truth is that Gentoo sees improvement and maintenance in the areas that appeal to the developers. And that is why Gentoo exists for the developers first, the users second. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpefQRP99Qb9.pgp Description: PGP signature
Re: [gentoo-dev] Portage, Jobs, and Niceness
Chris, This is useful information but not appropriate for gentoo-dev. Some people have suggested -user, which might be a good place. Other places I can think of are the forums or a blog. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2B3hiYwm1x.pgp Description: PGP signature
Re: [gentoo-dev] Re: baselayout-1.11.12-r2 request for testers
Konsti, See Mike's message which started this thread. He addressed lvm2 specifically: http://article.gmane.org/gmane.linux.gentoo.devel/28317 Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp9A0I1NA6JH.pgp Description: PGP signature
Re: [gentoo-dev] ARCH keywording for g-cpan?
Michael Cummings wrote: [Wed May 18 2005, 05:56:41AM EDT] Would you all prefer a bug with recommended tests for the new version? Do you all even care? :) Let me know, on list, off list, For a project like this, where you wrote the code and you know there shouldn't be cross-platform issues, I'd suggest marking stable on all platforms. That is what I do for keychain. If you choose that route, you make things easier for everybody, but you also risk the wrath of arch teams if your evaluation turns out to be wrong. For keychain it has never bitten me, but it's certainly possible that someday I'll find a snippet of shell code that works everywhere except SPARC. When that happens, I'll owe an apology (and a change of behavior) to the SPARC team for marking stable without testing on their platform. If you find other arch teams opposed to this approach, then at least I can tell you to go ahead and mark stable when you see fit for alpha and ia64. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpxwCwb3EYm3.pgp Description: PGP signature
Re: [gentoo-dev] get_number_of_jobs
Rafael Espndola wrote:[Thu May 12 2005, 02:40:46PM EDT] Why does get_number_of_jobs reduces the number of parallel jobs to to ensure successful merge? In my humble opinion if a package fails to compile with a large -j then the ebuild should know the limit and reduce it. Nope, if a package doesn't build with large -j then the ebuild should force -j1. Either a package is parallel build clean or it isn't. You can't make the problem go away by using an intermediate value for -j; it might work for you but it won't for somebody else. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpFmFgsvipWu.pgp Description: PGP signature
Re: [gentoo-dev] Re: New category proposal
Georgi Georgiev wrote: [Sun May 08 2005, 08:19:20PM EDT] Would it be inappropriate to start bitching (again) about a flat tree where each package can go in multiple categories? That's something I'd love to see eventually... I mean the flat tree, not the complaining ;-) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpCdAmHck0dN.pgp Description: PGP signature
[gentoo-dev] alpha co-lead
Hi guys, Kloeri (Bryan stergaard) has been doing the lion's share of development and maintenance for Gentoo/Alpha for at least the past year, including building our livecds. Neither of us really wants to be the sole Alpha lead, so this email is announcing that Kloeri and I are now co-leading the Alpha project. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpXbTekvjyB8.pgp Description: PGP signature
Re: [gentoo-dev] (media-video) ffmpeg and a52dec
Vibhav Garg wrote: [Wed Apr 20 2005, 05:34:11PM EDT] I am getting the following error while emerging ffmpeg-0.4.9_p20050226-r3 on amd64 Vibhav, I brought up the question originally because Chris White is no longer a developer. I think that problems merging ffmpeg should be filed as bugs at this point. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpYg4q5tSOHT.pgp Description: PGP signature
