[gentoo-dev] Looking for mozilla maintainers

2006-07-11 Thread Bryan Ãstergaard
Hi all.

As our old mozilla maintainer was retired a few days ago, we're urgently
looking for new maintainers to help with all the mozilla related

Stuart Longland (redhatter) kindly offered his assistance with mozilla
but to avoid quick burnout we need a couple more persons.

Depending on feedback from existing developers I'm probably also going
to recruit some new developers for this but I'd like to cover any
immediate issues asap. This means that existing ebuild developers are my
first priority.

Please poke me on irc if you're interested in this (nick is kloeri).

Bryan Østergaard
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Removing www-servers/resin-ee

2006-07-11 Thread Krzysiek Pawlik
Anatoly Shipitsin wrote:
 I've masked www-servers/resin-ee on 1 July, it will be removed from tree
  around friday (14 July) - it's old, binary and there's no version 3 of
 it. Please use www-servers/resin.
 it's not replaced by resin pro ?

It is - not yet in portage.

Krzysiek Pawlik   nelchael at gentoo.org   key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...

Description: OpenPGP digital signature

Re: [gentoo-dev] New virtuals: virtual/jre and virtual/jdk

2006-07-11 Thread Josh Saddler
Hash: SHA1

Joshua Nichols wrote:
 Krzysiek Pawlik wrote:
 Two new new-style virtuals have been added today to the tree:

  - virtual/jdk
  - virtual/jre

 This allows migration to generation 2 of Java build system to advance.
 All virtual/{jdk,jre} have been removed from profiles. The bug for this
 was #138747.

 Something worth mentioning... If you have problems where dependencies
 fail to resolve, like dev-java/blackdown-1.5, or dev-java/kaffe-1.4, it
 means you have some stale PROVIDE files kicking around. You will likely
 want to run the following to find them:
 find /var/db/pkg -name PROVIDE | xargs egrep -l 'virtual/jdk|virtual/jre'
 This should give you a list of files to you'll want to delete.
 - Josh

Might want to stick this in the java doc(s) then, if you think it's relevant for
any Troubleshooting sections.
Version: GnuPG v1.4.2.2 (GNU/Linux)

gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-11 Thread Ciaran McCreesh
On Mon, 10 Jul 2006 01:18:07 -0500 Andrew Gaffney [EMAIL PROTECTED]
| Even if you modify the profile to mask gcc-3.3.x, it won't force
| people to unmerge their existing gcc-3.3.x since it's slotted and
| they would already have gcc-3.4.x emerged, correct? And if we can't
| force them to unmerge it, we can't force them to switch which gcc
| version is active. Masking in the profile would have no effect if
| this is true.

Yeah. It's more of a tradition thing than a strict technological
enforcement. In the past we've always considered any GCC allowed by the
profile (that is to say, not masked or out of the packages range) to be
valid. Refusing to take bugs from people who're using a GCC permitted
by the profile is rather unfair...

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

gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-11 Thread Jose Luis Rivero (YosWinK)

Mike Frysinger wrote:
well it's about that time of the year ... time for nominating people 
for the next Gentoo Council

I would like to nominate kloeri (Bryan Østergaard) to the council if he 
has enough free time and if his devrel lead position (where his work is 
priceless) doesn't block the nomination.


Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New USE_EXPAND flag: FOO2ZJS_DEVICES

2006-07-11 Thread Stefan Schweizer

As proposed in http://bugs.gentoo.org/show_bug.cgi?id=139987 I would like to
add a flag to the foo2zjs printer driver ebuild to select if everything is
downloaded or only parts. This makes sense to be done in a special

I want to use FOO2ZJS_DEVICES because that seems to be common, I have not
seen _DRIVERS somewhere yet and _CARDS does not fit.

Any objections?


gentoo-dev@gentoo.org mailing list

[gentoo-dev] Last rites for net-misc/ssh

2006-07-11 Thread Gustavo Felisberto
I'm removing net-misc/ssh from the tree as Tectia no longer provides a free
version of they're ssh client and server. The last update to this package was
one year and half so I'm a bit afraid of security issues that might exist that
were not reported.

Gustavo Felisberto
Web: http://dev.gentoo.org/~humpback
Blog: http://blog.felisberto.net/

It's most certainly GNU/Linux, not Linux.
http://www.gnu.org/gnu/why-gnu-linux.html .

Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites for net-misc/ssh

2006-07-11 Thread Stuart Herbert


On 7/11/06, Gustavo Felisberto [EMAIL PROTECTED] wrote:

I'm removing net-misc/ssh from the tree as Tectia no longer provides a free
version of they're ssh client and server. The last update to this package was
one year and half so I'm a bit afraid of security issues that might exist that
were not reported.

Have you tried contacting them, and asking them for a license for
their product, so that you can provide an ebuild for the non-free

Best regards,
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new herd: vdr - Comprehension

2006-07-11 Thread Matthias Schwarzott
On Sunday 09 July 2006 19:17, Matthias Schwarzott wrote:

We will use the alternative c) - as lu_zero and flameeyes suggested.

 c) Using media-tv as herd and [EMAIL PROTECTED] (project's mail-address) as


Matthias Schwarzott
Gentoo Developer

Description: PGP signature

Re: [gentoo-dev] new herd: vdr - topic reanimated

2006-07-11 Thread Matthias Schwarzott
On Monday 10 July 2006 10:08, Jakub Moc wrote:
 Robin H. Johnson wrote:
  On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? 
  On Monday 10 July 2006 02:25, Luca Barbato wrote:
  c is simpler. I like it.
  Yes, of course if _all wranglers_ respected metadata, instead of
  stopping to herd tag and assigning to that even when a particular
  maintainer is listed.
  Actually, this isn't that simple at the moment. There are packages that
  directly list me as the maintainer, but I want bugs for them assigned to
  the herd by default - so that the other folk in the herd can find them
  Perhaps this could be alleviated with an explicit assign-to field in
  package metadata? At the same time, it should have an explicit cc-to
  field, for cases where the maintainer is not in the herd.

 Well, that reminds me - just stick [EMAIL PROTECTED] (or whatever else) to
 maintainer field then and put it first, enough of a hint for me :)

Should we then use this metadata-file (maintainer before herd tag):

!DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
email[EMAIL PROTECTED]/email
nameGentoo VDR Project/name



Matthias Schwarzott
Gentoo Developer

Description: PGP signature

Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-11 Thread Wernfried Haas
On Tue, Jul 11, 2006 at 12:50:12PM +0200, Jose Luis Rivero (YosWinK) wrote:
 I would like to nominate kloeri (Bryan Østergaard) to the council if he has 
 enough free time and if his devrel lead position (where 
 his work is priceless) doesn't block the nomination.

Damn, i wanted to do that for a few days already and now you beat me
to it. ;-)


Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

Description: PGP signature

Re: [gentoo-dev] Pending Removal of $KV

2006-07-11 Thread Chris Gianelloni
On Tue, 2006-07-11 at 07:24 +0900, Georgi Georgiev wrote:
 - 23 only make .config checks (should be non-fatal anyway)

I couldn't agree more.  This bites us in the ass every single release.
People who make .config checks fatal should be forced to maintain
mozilla-* for a month... ;]

 - 4 use linux-info to modify runtime behavior

Hopefully, these will go away soon, too.  Again, this is something that
constantly bites us when it comes to releases.

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

Description: This is a digitally signed message part

[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.

2006-07-11 Thread Ryan Hill
Denis Dupeyron wrote:

 Correct me if I'm wrong, but this has nothing to do with being
 interactive or not. To me, an ebuild that dies (intentionally or due
 to a build error) isn't interactive at all.

Their phrase, not mine. ;)  I think the idea is you should be able to emerge -e
world and walk away and not have anything interrupt the process thus requiring
the user interact with the system.  I'm personally for dying as soon as
possible, like before the actual compiling starts, but I don't think that's
possible yet.

 If a package is known not to work with a certain flag, being able to
 emerge it won't change the fact that it doesn't run.

If a package is known to not work with a certain flag it should be filtered so
it does run.

 Plus, if the
 solution is considered good for python, I don't understand why it
 wouldn't be good for any other package. Are you saying that Paul's
 proposition of having the python ebuild die on use of --fast-math
 isn't good ?


 If yes, why ? And what is your better idea ?

I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;))

* The -ffast-math option is known to break this package and has been filtered
from your CFLAGS.  Link to Safe CFLAGS wiki page, blah blah blah.

I like this better because it informs me of what I did wrong, what was done to
correct it, and how I can correct it for myself in the future if I choose to.  I
don't like artificial barriers and things not working without immediate
attention.  Call me lazy but it's annoying when you know what you're doing yet
you have to jump through hoops to get it done.

 Which is exactly the reason why we could benefit of something that
 enables us to manage this in a clean and safe way. I'm not saying I
 have a candidate for that something, but I wanted to discuss if
 there was an interest in it.
 Let's take again the example of -ftracer which can be enabled by the
 -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again,
 the reason I'm being vague is that my point isn't to discuss
 implementation just yet) that adds -fno-tracer to CFLAGS. In this
 case, you're covered wether -ftracer was added directly on indirectly
 by fprofile-use, which actually simplifies the number of flags that
 you need to blacklist. Thus ebuilds don't have to take care of it,
 bugs don't pour into bugzie, and Jakub can avoid overheating.

Do you mean for ebuilds that knowingly break with -ftracer, or for everything?
There are packages that expect to be built with certain flags;  not -ftracer,
but others.  Fex, libao needs -ffast-math ;).  Also, what about ebuilds that do
use -fprofile, like gcc itself?  I know toolchain.eclass strips all flags, I'm
just using it as an example.

If you mean just for packages that break with certain flags then absolutely.
But such a mechanism would have to be maintained for every different GCC
version, since -fprofile might not invoke -ftracer in every version, and indeed
some versions might not even recognize -fno-tracer and bail with an error.

 Users playing with CFLAGS get to keep the pieces.  Trying to
 dummy-proof the
 system doesn't help anyone but the dummies. ;)
 I'm one of those devs who care for our users. I think it's dangerous
 to try and categorize users in, for example, dummies and non-dummies,
 as you say. Who are we to judge this or that user is a dummy ? Plus,
 we all are the dummy of somebody else.

Okay, bad joke aside, there are always going to be users who tweak GCC flags.
This has to be expected, as they're mysterious, and technical, and kinda cool.
I like the tweaker crowd and I am a dummy, so no offense was intended to either
groups.  I meant that if you safety-proof a complex system, people never learn
that they're doing anything wrong in the first place.

 Anyway, I was thinking more in terms of making the job of developers,
 bug wranglers, and poor old bugzilla easier, cleaner, safer. How many
 bugs do we have that are due to dangerous flags ?

Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to
automate this in any sane way.

 How much time and
 effort could we save if we didn't have those ? Also, I was thinking
 that if a good solution was found to deal with a dangerous flag in a
 certain package, maybe it was a good idea to extend this solution to
 other packages. And finally, if said solution becomes common, maybe
 it's a good idea to make it system-wide with a possibility to override
 the setting by the user or the ebuild. It seems we already have
 per-package CFLAGS, so part of this, at least, is already implemented.

Right, but how are people supposed to learn something is dangerous if all the
sharp edges have been filed off?  And how can you decide which flags are bad
and good on a global level when for the most part compiler parameters are akin
to black magic?

I guess in the end it comes down to personal philosophies on how to handle this,
and I'm not going to try to change anyone's opinions.  I 

Re: [gentoo-dev] Modular X unported packages

2006-07-11 Thread Donnie Berkholz
Donnie Berkholz wrote:
 With the help of Brian Harring, we've now got a check for unported
 packages. It indicates 207 unported packages, of which 93 can
 potentially be fixed by stabilizing newer versions and pulling unported
 ebuilds from the tree.

Having fun again here ... I've made a list of the violators (herds or
devs) with more than 1 package. There are 62 unmaintained packages, for
which the x11 team will probably end up filing stable bugs ourselves
when it's possible to fix by stabling.

As long as your unported ebuilds are in the tree, there will be many
dependency issues because we're forced to leave virtual/x11-7 in to
provide for their broken deps. That was a hack to begin with, and it
needs to end.

 53 xfce
 11 video
 10 sound
  9 desktop-wm
  8 media-video
  7 cjk
  7 afterstep
  6 graphics
  6 desktop-misc
  5 sci
  5 taviso
  4 stuart
  4 dragonheart
  3 netmon
  3 commonbox
  3 vapier
  2 zypher
  2 usata
  2 lordvan
  2 dholm
  2 azarah
  2 X11-drivers
  2 net-p2p
  2 net-news
  2 media-tv
  2 games
  2 cluster


Description: OpenPGP digital signature

[gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)

2006-07-11 Thread Zac Medico
Hash: SHA1

Hi everyone,

The attached patch for bug #132355 [1] adds a --mindeps option for emerge that 
effectively allows build time dependencies to be excluded from dependency 
calculations involving binary and installed packages.  With this patch, it's 
possible to remove all build time dependencies from a system with the command 
`emerge --depclean --mindeps`.  When --mindeps is used to install packages, it 
causes build time dependencies to be excluded for binary packages and packages 
that are already installed.  This patch will change the previous default 
behavior for `emerge --usepkg package list`, but if desired, the user will be 
able use --mindeps together with --usepkg.  Are there any suggestions to 
improve on this idea or is it fine the way that it is?


[1] http://bugs.gentoo.org/show_bug.cgi?id=132355
Version: GnuPG v1.4.4 (GNU/Linux)

Index: bin/emerge
--- bin/emerge	(revision 3836)
+++ bin/emerge	(working copy)
@@ -190,7 +190,7 @@
 --help, --ignore-default-opts,
+--mindeps,  --noconfmem,
 --newuse,   --nocolor,
 --nodeps,   --noreplace,
@@ -352,6 +352,7 @@
 	# recurse:   go into the dependencies
 	# deep:  go into the dependencies of already merged packages
 	# empty: pretend nothing is merged
+	# minimal:   exclude dependencies that aren't strictly required.
@@ -366,6 +367,8 @@
 	if --deep in myopts:
+	if --mindeps in myopts:
+		add.append(minimal)
 	if --selective in myopts:
 	if myaction in [world,system]:
@@ -755,8 +758,14 @@
 			edepend[depkeys[i]] = depvalues[i]
 		if mytype == binary:
-			edepend[DEPEND] = 
+			if minimal in self.myparams:
+edepend[DEPEND] = 
 		elif mytype == ebuild:
+			# minimal + empty implies depclean
+			if minimal in self.myparams and \
+(empty in self.myparams or \
+mybigkey[-1] == nomerge):
+edepend[DEPEND] = 
 			if --buildpkgonly in self.myopts:
 edepend[RDEPEND] = 
 edepend[PDEPEND] =