Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

2006-07-13 Thread Paul de Vrieze
On Thursday 15 June 2006 07:57, Harald van Dijk wrote:
 So herdgames/herd implies managed by the games team sometimes but
 not always? Meaning if the maintainer is games team + X, then games
 team must be explicitly listed as a maintainer in metadata.xml ?

 If so, sorry, misunderstood you, and this is far less insane than what I
 thought you were saying.

RTFM.

Metadata.xml specifies a herd for a package. That means that when there is no 
individual maintainer (or he/she fails to do his duty) that package is 
maintained by whomever maintain the herd. In this case the project members of 
the games project maintain the games herd. This means that they will maintain 
the package if there is no named maintainer or he/she leaves, is unavailable, 
etc.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp9ccLfTTvJY.pgp
Description: PGP signature


Re: herding (was: Re: [gentoo-dev] Re: A heretical thought? project sunrise as an almost-fork.)

2006-07-13 Thread Paul de Vrieze
On Wednesday 14 June 2006 23:50, Chris Gianelloni wrote:
 On Wed, 2006-06-14 at 17:04 -0400, Michael Cummings wrote:
  The gripe in this respect is that we have developers (who don't respond
  to emails, friendly or otherwise) that will dump packages into dev-perl,
  copy a metadata.xml from another pkg, and leave it as is - and since we
  (perl project folks) use a stock metadata.xml listing perl as the herd,
  and [EMAIL PROTECTED] as maintainer, that means we get stuck with the
  package. It sucks because you get bugs for badly written ebuilds and
  your only trace of how it got there is either the ChangeLog (if you're
  lucky) or the cvs log (had to resort to that once or twice too) - and in
  the end, the bugger doesn't care who's package it is, they want it
  fixed, and its not their fault for filing a bug, so you grind on and
  take care of it.

 That's the thing.  That developer is wrong, and has done something
 wrong.  I see nothing wrong with listing perl as the herd, *only* if
 they have themselves as the maintainer.

Only with perl consent. The perl herd then gets the responsibility to take 
over if the maintainer leaves, is unavailable, etc.


 Not exactly...

 Notice it says that a package is a member of a herd, not a person.  A
 herd can have one or more projects responsible for maintaining the
 packages in it.  In *most* cases, the group of developers responsible
 for a given herd either have an alias that matches the herd, or are a
 project with a similar alias.

   To make it pretty clear and explicit - bugs gets assigned to
   maintainer (if there's any in metadata.xml), and get CCed to herd
   (if there's any in metadata.xml). If there's no maintainer, whoever
   is in herd will get that bug assigned and can happily smack you 
   once they've find out you've dumped the package on them without their
   knowledge...
 
  he does appear to be correctly quoting the documentation on the site.

 That's where I disagree.  His practice is correct.  It should be
 assigned to the maintainers of the herd, if no maintainer is listed, but
 a herd is *not* a group of developers.  It is a group of packages, with
 developers that maintain that group.

Nowhere did I write (nor was it agreed then) that herd membership should be 
automatic. The bug wranglers seem to be doing the right thing. Assign to 
maintainer, CC the herd email address.


  And we can't blame the bug wranglers for following this documentation -
  we either update it or accept that that's what we have published to date.

 Except that what I am saying is what the documentation says, and also
 the intention of the documentation, as stated by some of the people who
 wrote it, back when we had the whole herds vs. teams thread.

The reason there should always be a herd is very simple. People leave, groups 
of people leave less, and can be replenished.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp33JqLRbDJT.pgp
Description: PGP signature


Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

2006-07-13 Thread Paul de Vrieze
On Thursday 15 June 2006 02:54, Dan Meltzer wrote:

 According to the devmanual [1]
 A herd is a collection of developers who maintain a collection of
 related packages

 are you sure you are using the correct term?

 [1]
 http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html

The dev manual is *wrong*.
I should know too. I wrote the bloody herds.xml and metadata.xml formats and 
the page along. Indeed it does not clearly specify what herds are, but it is 
certainly implied in the format description of for example the maintainer 
tag.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp8TaWnHwb21.pgp
Description: PGP signature


Re: [gentoo-dev] Herds suck, fix them

2006-07-13 Thread Paul de Vrieze
On Thursday 15 June 2006 08:59, Mike Frysinger wrote:
 On Thursday 15 June 2006 02:33, Kevin F. Quinn wrote:
  We could require that a herd mail alias be maintained for every herd,
  with the same name as the herd, such that the herd alias lists the
  maintainers of all packages in the herd.

 this would be useful regardless

This should be only those people mentioned (or referred to) in the herds.xml 
file. Not maintainers of individual packages. The list of these people can be 
glanced from the web version of herds.xml. The stylesheet resolves all 
indirect references.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpW4hC13baOU.pgp
Description: PGP signature


Re: [gentoo-dev] Herds suck, fix them

2006-07-13 Thread Paul de Vrieze
On Thursday 15 June 2006 12:34, Jakub Moc wrote:
 Marcus D. Hanwell wrote:
  I don't know if this is a really unpopular viewpoint, but for a lot of
  stuff I maintain I put myself as maintainer and the herd I am acting as
  part of in herd. My intention there is to say primarily I am taking care
  of this and have taken responsibility but if I disappear, am slow or
  someone else just wants to bump it etc in that herd then they are also
  free to do so.

 Well yeah, that's how I read the metadata.xml in such cases... but since
 some people are suggesting that herd is not relevant info wrt
 maintainership, this attempt for clarification has been proposed.

  May be it would be more correct for me to add the herd alias as a second
  maintainer? I think it is good for people to take responsibility for what
  they add to the tree and that is my intention there...
 
 :=) If a general consent is (games left apart ;) that herd is a backup

 for cases when maintainer is unavailable/goes MIA, and a primary
 maintainer if there's no maintainer tag in metadata.xml, let's just
 leave it at that, be done with it and save ourselves the hassle...

 If we can't agree upon this, then we probably should stick herd alias
 into maintainer tag when that herd _is_ actually willing to act as a
 maintainer.

The whole point of the herd tag is to say that the herd with that name is 
responsible when the maintainer fails. Herds are NOT maintainers, and the 
email must not be referred to in a maintainer tag.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpbap1RBELOT.pgp
Description: PGP signature


Re: [gentoo-dev] Linux World Expo

2006-07-13 Thread Chris Gianelloni
On Mon, 2006-07-10 at 23:34 -0400, Mike Frysinger wrote:
 On Monday 10 July 2006 14:38, Joshua Jackson wrote:
  So who's planning on going? Basically  I'd like to know who's planning
  on going. I'm still undecided about it honestly, and if I go it'd only
  be for a few days. Its also probably a good way to find a roomate to
  make the cost of rooms a bit less. We don't have enough dev's close
  enough to san fran to allow a whole bunch of us a floor to crash on as
  far as I know. If however you are, give us a shout with floor space ;)
 
 as far as i know, dostrow will be organizing it ... and i'll be showing up to 
 be his love slave and/or assistant

I'll be there, for sure.  I'm not sure which days, possibly all of them
or possibly only 2 days, depending on what I can get off from work.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

2006-07-13 Thread Ciaran McCreesh
On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| The dev manual is *wrong*.

No, the devmanual reflects what's actually being done, rather than an
impractical definition that was written years ago that no longer
matches the development model.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] gtk's X use flag

2006-07-13 Thread Ser Gio
Hello,Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild doesn't look like it's using it.thanks,Sérgio


Re: [gentoo-dev] gtk's X use flag

2006-07-13 Thread Jakub Moc
Ser Gio wrote:
 Hello,
 
 Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild doesn't
 look like it's using it.
 
 thanks,
 Sérgio

Because virtualx.eclass has it in IUSE and the ebuild inherits it.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] gtk's X use flag

2006-07-13 Thread Tuan Van
Jakub Moc wrote:
 Ser Gio wrote:
 Hello,

 Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild doesn't
 look like it's using it.

 thanks,
 Sérgio
 
 Because virtualx.eclass has it in IUSE and the ebuild inherits it.
 
 

I hate it when this happens.
I have an ebuild inherits perl-app. It pulls in minimal and perl
USE-flags. kinda misleading.

Tuan
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk's X use flag

2006-07-13 Thread Brian Harring
On Thu, Jul 13, 2006 at 04:31:52PM -0700, Tuan Van wrote:
 Jakub Moc wrote:
  Ser Gio wrote:
  Hello,
 
  Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild doesn't
  look like it's using it.
 
  thanks,
  Sérgio
  
  Because virtualx.eclass has it in IUSE and the ebuild inherits it.
  
  
 
 I hate it when this happens.
 I have an ebuild inherits perl-app. It pulls in minimal and perl
 USE-flags. kinda misleading.

*Cough*implementation-specific*cough* strip it from E_IUSE .
~harring


pgpnaCD0XSQqN.pgp
Description: PGP signature


[gentoo-dev]

2006-07-13 Thread Ser Gio
On Fri, 14 Jul 2006 00:19:44 +0200Jakub Moc [EMAIL PROTECTED] wrote: Ser Gio wrote:  Hello,Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild
  doesn't look like it's using it.thanks,  Sérgio  Because virtualx.eclass has it in IUSE and the ebuild inherits it.Yes, i noticed that. But, for the enduser, the X flag in gtk+ is useless right? So, is it a bug?
Regards,Sérgio Martins


Re: [gentoo-dev]

2006-07-13 Thread Jakub Moc
Ser Gio wrote:
 On Fri, 14 Jul 2006 00:19:44 +0200
 Jakub Moc [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
 
 Ser Gio wrote:
  Hello,
 
  Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild
  doesn't look like it's using it.
 
  thanks,
  Sérgio

 Because virtualx.eclass has it in IUSE and the ebuild inherits it.
 
 Yes, i noticed that. 

So, why do you ask?

 But, for the enduser, the X flag in gtk+ is useless right? So, is it a bug?

No, it's not gtk+ ebuild bug. Feel free to submit portage patch to avoid
this. ;)


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev]

2006-07-13 Thread Steev Klimaszewski
On Fri, 2006-07-14 at 01:02 +0100, Ser Gio wrote:
 On Fri, 14 Jul 2006 00:19:44 +0200
 Jakub Moc [EMAIL PROTECTED] wrote:
 
  Ser Gio wrote:
   Hello,
   
   Why does x11-libs/gtk+-2.8.19 has the X useflag? The ebuild 
   doesn't look like it's using it.
   
   thanks,
   Sérgio
  
  Because virtualx.eclass has it in IUSE and the ebuild inherits it.
 
 Yes, i noticed that. But, for the enduser, the X flag in gtk+ is
 useless right? So, is it a bug? 
 
 Regards,
 Sérgio Martins

Actually, as of 2.10, gtk+ CAN be built without X and using the
framebuffer, so you can build gtk+ apps against the framebuffer (using
them, is another story... although I hear GIMP works)  so having it
there isn't necessarily useless.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Making dobin, doexe die by default and doins, doman, dodoc warn initially

2006-07-13 Thread Mike Frysinger
On Wednesday 12 July 2006 20:26, Daniel Black wrote:
 there is always,

not for joe blow who just wants to use Gentoo, the implementation details of 
portage be damned
-mike


pgp52zW9PEvg6.pgp
Description: PGP signature


Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default

2006-07-13 Thread Mike Frysinger
On Wednesday 12 July 2006 18:12, John Myers wrote:
 On Wednesday 12 July 2006 14:36, Steve Dibb wrote:
  Well, it could happen while testing an ebuild. :)  I'd be pretty ticked
  if I were testing Qt and I didn't realize they did change the doc files
  around before doing a test run.
 
  Besides that though, imho, a simple function with a boolean return type
  shouldn't kill the script executing it.  Throw a warning, yes, but not
  stop everything.

 Then you could have a IM_TESTING_STUFF_DONT_DIE_ON_DODOC variable to
 override the die or something

FEATURES=stricter

i find this feature useful for all the extra anal people out there
-mike


pgpR3IcG3Sw4J.pgp
Description: PGP signature


Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default

2006-07-13 Thread Mike Frysinger
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

 Also as Paul suggested something like that would be possible for a custom
 die message:
 if [[ -n ${DIE_MSG} ]] ; then
 echo !!! ${DIE_MSG}
 fi

ugh, ugly
DIE_MSG=failed to install root bins dosbin fooie

dosbin fooie || die failed to install root bins

you tell me which is already a clean/common standard in the tree

 They are imo QA problems and should be fixed.

crazy idea, grep your /var/log/portage/ logs and file bugs
-mike


pgpFbK2ZvGUPW.pgp
Description: PGP signature


[gentoo-dev] 'mad' vs 'mp3' USE flags

2006-07-13 Thread Daniel Watkins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems to me that having both of these two flags can only cause confusion.
I upgraded xine-lib yesterday and spent a very frustrating 2 hours trying
to work out what had broken my Amarok MP3 playback. It turns out that
having the 'mp3' USE flag set globally is not good enough to get MP3
playback enabled in xine-lib, you need 'mad' set.

Is there a rationale behind this decision? If not, it would seem to be quite
an important issue, as a lot of users will be looking for MP3 playback (and
expecting it to work from one version of xine-lib to the next, without
having to play with USE flags).

Cheers,
Dan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEtxeblFI7BNKVCIkRAjXeAJ4uxe0MhE58dDOKfZaSYAvBKK2QIwCfUrGX
OraQa1DQ8BPnuvcAeeEnrl4=
=0n2p
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-portage-dev] new portageq metadata function to wrap dbapi.aux_get()

2006-07-13 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

It's come to my attention that the built_with_use function in eutils.eclass 
accesses the installed package database directly.  This is a major problem 
because it prevents us from being able to have an alternative installed package 
database implementation without breaking that function.  How about if we add a 
new portageq function that simply acts as a wrapper to the dbapi.aux_get() 
function?  If we provide this function, then eutils.eclass can simply use the 
package that is returned from best_version to do another call that gets the USE 
flags.  Here's an example of the usage:

portageq metadata / installed sys-apps/portage-2.1-r1 USE

That command would print 1 line with all the USE flags.  If additional metadata 
keys are specified, it will print each value on a new line.  Does the behavior 
described above seem good or are there any suggestions to improve it?  Please 
see the attached patch.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEtxf+/ejvha5XGaMRAkaKAKCAi/WHt6GIIoW0HqyaFbTmKLHTeQCeIN/d
rJUMKUs7OK9Z3tS9Ms0f0a4=
=3+Gh
-END PGP SIGNATURE-
Index: bin/portageq
===
--- bin/portageq	(revision 3854)
+++ bin/portageq	(working copy)
@@ -80,7 +80,34 @@
 		sys.exit(1)
 mass_best_version.uses_root = True
 
+def metadata(argv):
+	root pkgtype category/package [key]+
+	Returns a metadata value for the specified package.
+	
+	if (len(argv)  4):
+		print  sys.stderr, ERROR: insufficient parameters!
+		sys.exit(2)
 
+	root, pkgtype, pkgspec = argv[0:3]
+	metakeys = argv[3:]
+	type_map = {
+		ebuild:porttree,
+		binary:bintree,
+		installed:vartree}
+	if pkgtype not in type_map:
+		print  sys.stderr, Unrecognized package type: '%s' % pkgtype
+		sys.exit(1)
+	try:
+			values = portage.db[root][type_map[pkgtype]].dbapi.aux_get(
+pkgspec, metakeys)
+			for value in values:
+print value
+	except KeyError:
+		print  sys.stderr, Package not found: '%s' % pkgspec
+		sys.exit(1)
+
+metadata.uses_root = True
+
 def best_visible(argv):
 	root [category/package]+
 	Returns category/package-version (without .ebuild).