Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow

2010-11-20 Thread Alistair Bush
 On 11/21/2010 04:57 AM, Ryan Hill wrote:
  On Sun, 21 Nov 2010 01:38:23 +0200
  Nikos  wrote:
  On 11/21/2010 12:46 AM, Ryan Hill wrote:
  I'm unmasking sys-devel/gcc-4.5.1 tomorrow.  I'd like to recommend
  everyone who has already unmasked it to rebuild it now as there has
  been some important patches added recently (see ChangeLog).
  We don't do revbumps on masked toolchain packages.
 Why not?

Yeah why not?  do you inform users of this?

Re: [gentoo-dev] News item: Dropping Java support on ia64

2010-11-14 Thread Alistair Bush
 Any improvements to the text are welcome.

I think the following could be written clearer.   Reading it made me have to 
go off and check what week 50 was.

If there is no interest the removal of Java support well be done during week
50 of year 2010.

why not say

'If there is no interest the removal of Java support well be done during the 
week starting 13th Dec 2010.

(please confirm the date on that)


Re: [gentoo-dev] .la files removal news item (GLEP 42)

2010-10-01 Thread Alistair Bush
 Hi lads,
 due to recent situation about .la files status we would like to inform
 users about this situation. See attached file that we propose to be
 included as news item.

Would it not be a better solution to have this information documented 
properly under Upgrade Guides or Gentoo System Documentation and then have 
this news item linked to it.

What i'm concerned about is that this is not really a news item.   From what I 
understand this issue could be with us for a rather long time (years even) 

How is this news item going to help ppl in a month from now (till the issue is 
solved in its entirety). 
Can we reasonably expect a new user to be aware of this.   Do we expect users 
to read old ( and this could potentially become very old) news items.

This is potentually a different situation from someone updating dbus (for 
example) from y.y.y to =y.y.y and having a once off (fire and forget) 
migration task.  It is for this reason that I think this should be documented.


 Step 2 will be finding global policy how to get rid of them as fast as
 possible  without too much more hassle for our users :)
 Tomáš Chvátal
 Gentoo Linux Developer [Clustering/Council/KDE/QA/Sci/X11]
 E-Mail  :
 GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
 GnuPG ID: 03414587

Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-25 Thread Alistair Bush
 Hi folks,
 I'm currently collecting a set of rules which upstream developers
 should follow to make distro maintainer's life easier.
 Comments welcomed :)

Is this language specific?  would you be interested in comments about java, 
ruby, python, etc, etc, etc or are you only interested in good old C/C++, etc


Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits

2010-04-25 Thread Alistair Bush
 On 04/24/2010 09:14 PM, Alexis Ballier wrote:
  On Sat, 24 Apr 2010 20:40:54 +0300
  Petteri Räty wrote:
  17:34  Betelgeuse robbat2|na: how easy to it to prevent commits to
  CVS if the commit message doesn't match a certain pattern?
  17:36 @robbat2|na go and checkout the CVSROOT and there should be an
  example there
  17:37  Betelgeuse robbat2|na: Ok so doable then. Thanks.
  What do you think about not allowing commits to eclasses without
  mentioning an another developer who has reviewed and approved the diff
  in the commit message? There's enough people on gentoo-dev for urgent
  stuff too.
  no thanks; we already have the policy to require that major changes to
  broad impact eclasses have gone through -dev, no need to add more
 But the policy is not tested by the quizzes and we have had cases lately
 where large diffs have been committed without gentoo-dev review. With
 peer review it's likely that the reviewer is familiar with what should
 be sent to gentoo-dev as hesitant/new people won't give their approval
 that easily.

1)  Why is it of any relevance whether or not the quizzes test this policy?  
2)  Where is this policy recorded, and why does devmanual.g.o seem to 
(possibly) contradict it? [1]  I'm not sure of the nature of the commits but 
were they non-general?

- Alistair

[1] It is not usually necessary to email the gentoo-dev list before making 
changes to a non-general eclass which you maintain. Use common sense here.

Description: This is a digitally signed message part.

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

2010-04-04 Thread Alistair Bush
 1 - requirements
 In order to choose the best possible wiki implementation, we need to
 know our requirements. So what features do you think are essential or
 good to have? What syntax would we prefer to use?
 I myself am a big fan of reStructuredText, which is quite simple,
 easy to pick up, highly readable, and has a good featureset. Plus, it
 is also reusable in other contexts (it is for example widely used in
 documentation of Python libraries). MediaWiki, MoinMoin and Trac have
 support for rst.

I'm not overly concerned about what wiki we use.   But may I suggest we 
approach gentoo-wiki to see whether they would like to be involved.

 Some others:
 - active upstream (bug fixes, security updates)
 - free open source software
 - ACLs
 - spam prevention measures
 - attachments (to upload screenshots for example)
 - feeds
 Other distros and open source projects surely have had the same
 considerations. Can we find out and learn from them?
 2 - maintainers
 Who is volunteering for maintaining the wiki? We need editors and
 moderators, people who look out for quality control and take care of
 spam removal. So let's get together a team. I'm sure if we ask on the
 forums we'll get some users interested as well.

I would like to help as I may.   Hopefully we can get a good body of users to 
help as well.  I'm of the firm belief that it will be users who should make 
this idea either fly or crash down hard.Dev's have official means of 
documenting stuff. 

 3 - edit access
 Do we keep to the original free for all model, with all the spam
 that includes, or do we go with registered users only? I think the
 latter is the smarter option. I also think we will want to mark
 certain pages official and lock down editing rights.

Registered users only please.

 Is there anything else we should consider before getting started?

What project should we create this under.

gdp is for official documentation so I don't think it should be under that but 
it could very well be under userrel.  Or it could be a new project.

I also have some other ideas that I would like to implement once I get around 
to brain-dumping them.   So I will simply ask this question.

Are there any complimentary services we could offer users besides a wiki?  
Maybe best to just think about this and not answer it here.



Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

2010-04-04 Thread Alistair Bush
 On 4/3/10 3:40 PM, Ben de Groot wrote:
  Are there any other ideas on how to improve our recruitment process?
 The idea appeared before, but I think it's worth noting.
 Either merge the ebuild and end quizzes, or make the split actually
 meaningful. In my case I just finished both at the same time, but was
 confused why they are separate. I think I've seen similar comments from
 other developers.
 I think I'd rather prefer merging the quizzes.

One thing i've noticed is that the ebuild quiz is far more difficult than the 
eom quiz.   We seem to have the biggest hurdle first.

What I would like to see is either the quizzes be merged or

An easier first quiz that covers the basics which after being answered the 
user can become a gentoo developer  ( ie email, ssh access to 
d.g.o, etc) but no access to push directly to the tree.  Instead all commits 
must be pushed thru their mentor,  who is responsible for qa'ing and giving 
advice.   Currently I don't think mentors really have much of a role. There is 
certainly no requirement for a mentor to qa their charges commits,  but if 
they are the ones pushing to the tree the mentor has all the responsibility. 
This might just make mentors more responsible for the quality of recruits.

Some of this could be done regardless of whether there are separate quizzes or 
not obviously.  But I think it creates a nice workflow.

- Alistair.

Re: [gentoo-dev] List of User projects

2010-03-29 Thread Alistair Bush
 diffball (the basis of y'alls delta compression for tarball
 snapshots, progenitor of tarsync used by emerge-*webrsync, etc).

Thank you Brian for that pkg, its appreciated.  My apologies if the rest is a 
little less kind.

  ps.  I would like the packages to be specifically for gentoo,  but there
  are exceptions to this.  as an example openrc (and even paludis to a
  degree).  If you think that there is a package not specifically
  targetting gentoo that deserves a mention please make it clear why.
 I'm a bit torn by this proposal; on the one hand, a shout out is nice-
 from a career angle it certainly would've been useful for getting
 some attention/exposure when I first was starting out.

Not really my aim.  Im not planning on listing ppl,  just there work.  Might 
not even put a url pointing to it.

 That said, it has some issues with it:
 * it'll wind up being a fairly subjective list leading to some
 debates nobody really wants to be involved in (nice euphemism for

Well I suppose it would be my project,  therefore I would make the call.  ppl 
can flame all they like really.  Personally I don't find them a very good way 
communicate,  would probably miss what they were flaming about anyway.

 *) the criteria seems to be external projects that are gentoo
 specific, aparently by non-devs/ex-devs.  This raises some questions
 as to what happens for when it's created by a dev externally (pkgcore
 went external a long while before I became an exdev), and what
 happens when the author becomes a dev (I'll be getting my gentoo-x86
 +w back soon enough).

Firstly that is very good news.

Currently I am taking this from Mon, 29 March 19:42 NZ DST.   So pkgcore is 
external,  and you are a community member so your in the list.   I don't want 
to bring a whole pile of history into it.   Will pkgcore have its own gentoo 
project,  or be considered as part of a gentoo project?  Im guessing not 

I'm quite happy to consider the corner cases,  and will probably include a 
vast majority of them.  Initially I don't even believe I will have a fully 
complete list of all the projects the fit nicely into my criteria.  Thats why 
you have one of those nice statements that says.

While we have attempted to list all package/projects etc we are sure we have 
missed some,  please contact ..  if you believe we have missed something 
blah de blah blah

 *) PMS was started outside of gentoo, and maintained outside gentoo
 for a long while.  Now it's a gentoo project.  A shout out there
 would've been warranted (spec work isn't exactly sexy, regardless of
 any extra baggage that came w/ PMS), but at what point does it
 suddenly fall off this list?

Isn't this a bit too bikesheddy.  If someone, from now, were to create a 
project and then have it added to the list before they become a dev then good 
on them.  The project would not be removed.  Even if it died.  In fact the 
list would never be cleaned.  It may be updated to represent the state of the 
project,  but that project would be there for as long as the page was. (and 
probably longer the way ppl index the interwebs).

 *) kind of the packagekit connundrum- at least for pkgcore/paludis,
 they were written to support multiple distros/formats internally.  Yes
 they've got traction w/in gentoo, but at what point is it no longer a
 gentoo specific thing, and more of a it gained it's first traction in
 gentoo ?  Openrc I'd argue is in the same boat- yes it can be used
 elsewhere, but right now we're the owns extracting the most benefit
 from it.

Well I would suggest that a major part of the functionality of both those 
pkg's are directed towards supporting gentoo.   Even if both supported 5-10 
completely different distro's that did not resemble gentoo in the slightest I 
would still put them on the list.  Compare this with kmyfirewall that had a 
single dialog that allowed to be set gentoo specfic executable paths which 
would not be on the list.

 *) it slights the tools that started w/in gentoo's vcs; consider
 scanelf .  Very useful tool deserving some credit, but it would be
 exempted under these rules.

Life ain't always perfect.   And that goes both ways.   This isn't a list to 
thank developers for their effort,  make another thread if you want that.

It also doesn't slight that project in the slightest.

 Instead, if the purpose is a thanks, why not every once in a while
 put up a news item discussing the tools in question?  Such an
 approach allows folk to focus in on whatever is useful/interesting
 (regardless of origination) and give the same 'thanks' angle and
 public exposure for the author in question.

Well I was considering this as well.   But first before we do this we would 
need to actually know what packages there are.  Therefore this thread.  Unless 
we do all packages from a to z.

- Alistair

ps. I must say that its a little sad that so far there has been much more 
effort put into nitpicking than 

Re: [gentoo-dev] [RFC] Reworking package stabilization policies

2010-03-28 Thread Alistair Bush
 On Saturday 27 of March 2010 21:58:41 William Hubbs wrote:
 It's really freaking silly to wait months for stabilization of some random
 php/perl library that's known to work.

Have you ever just considered closing the stabilization bug and ignoring the 
arch.  If they take so long to mark your packages as stable why do you care 
about them enough to even attempt to stabilize anything on their arch.

Re: [gentoo-dev] Re: List of User projects

2010-03-28 Thread Alistair Bush
 So you mention openrc, but don't have it on the list?

Yes because openrc isn't really gentoo-specific.   I don't want the list 
blowing out to include ever package in the entire tree.   ie. Thanking gcc for 
contributing to gentoo.

Note this doesn't mean that openrc won't be on the list.  I think that in this 
case the dev has worked closely enough with gentoo to deserve acknowledgment. 
(being a former dev might have helped that :) ) 

Maybe it will be in a Non-Gentoo specific section of the list,  or something. 
My point at the moment is to distinguish it from something like 
pkgcore/paludis which were developed with gentoo firmly as the target platform.

 FWIW, I've not looked, but I think a number of the portage helpers are
 non-gentoo-dev developed, and certainly a number previously were, that
 have ultimately been folded back into portage and/or gentoolkit in someway
 or another now.  I'm sure someone from one of those projects can list
 several of them without even looking.

Well i'm more interested in what is being developed verses what were 
developed.  But that is an interesting possibility,  not surprising but 
interesting none the less.

[gentoo-dev] List of User projects

2010-03-27 Thread Alistair Bush
I was just thinking how nice it could be if we acknowledged some of the 
projects that contribute to gentoo but are actually developed primarily 
outside of gentoo's dev community.  How about a page on

So lets me start with a couple of obvious ones.


There must be more than these or else gentoo really is dead.

- Alistair

ps.  I would like the packages to be specifically for gentoo,  but there are 
exceptions to this.  as an example openrc (and even paludis to a degree).  If 
you think that there is a package not specifically targetting gentoo that 
deserves a mention please make it clear why.

Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it

2010-03-19 Thread Alistair Bush
 Zac Medico wrote:
 I think what most people want is for portage not to pull in a package
 that nothing uses.  I'm not a dev nor a programmer but I have yet to see
 any good reason for installing something that is not being used.  It's
 not being tested to see if it is stable.  It would have to be used
 before that would happen.  Basically, it is just one more package to
 update and taking up hard drive space.  It's not doing anything else.
 As for slots, if something needs it, portage would pull in the new
 slot.  That's what portage does.  It just seems in this case it is
 pulling in a new slot that nothing uses.

Have you considered that they might possibly be hundreds of packages that you 
have installed providing functionality that you never use, but are only there 
as a fixed dependencies of something that you do. 

Hell lets take it even further than that, i'm sure there are thousands of 
lines of code in most packages that you will never hit,  so why dont we start 
masking them as well. 

I don't recall ever using grep --version,  please remove (mask) that code from 
grep.  We will obviously need someway to unmask those code masks so lets 
create a couple of files for portage.  Hows

code.mask and code.unmask with a format of

package path/to/file line1 line2 line3 line4

Or maybe we could just let users who don't want to install python-3 mask it 
_locally_.  Once they need it portage is more than capable of telling them 

 :-)  :-)

[gentoo-dev] Last rites: dev-java/kaffe

2010-03-15 Thread Alistair Bush
# Alistair Bush (15 Mar 2010)
# Mask for removal (#309459).  Does not compile
# and Dead upstream. Recommend icedtea jdk's for
# a free alternative.


Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)

2010-03-10 Thread Alistair Bush
 1) Add two new packages to the tree:
- app-admin/geolizer (/usr/bin/geolizer)
- app-admin/webalizer-xtended (/usr/bin/webalizer-xtended)
 2) Bump webalizer to 2.21 while
   - no longer applying either feature patch
   - removing use flag xtended
   - keeping now hollow use flag geoip to reduce breakage
 3) Close related bug 231859
 I volunteer to do that.
 Any objections or suggestions?

+1  we really should be attempting to keep as close to upstream as possible.

Re: [gentoo-portage-dev] a feature called stabilize wanted

2010-03-10 Thread Alistair Bush
 Hello List ans anyone!
 I'm searching for a feature or an hint how and where to implement it.

Mmmm... Im not one of the knowledgable ppl around here but

you can have version ranges within files like package.keywords eg

which would mean  ~arch  A-4.0 = arch

which is essentially what your asking for.

The biggest issue I have with a feature like this is that you seems to be 
overriding the config files all ready present.   That would only last until the 
next time you ran emerge.

I think this could be better solved with tools ( gui or cli ) that allowed a 
user to manage package.keywords, etc.   Now a tool that actually did this 
would be very interesting indeed. 


 The desired feature could be called stabilize or update to stable
 and would change the selected packages when doing an update (emerge
 -avuND world).
 Just to give you an initial idea/example, some packages:
 package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9
 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6
 package C - (the unstable) has: ~0.6 ~0.8 ~1.1
 So version numbers with the ~ are unstable/~amd64, where numbers without
 are stable/amd64.
 Case 1 (amd64): using system wide only stable/amd64
 Installing anything would result in a...@3.8 and C,B not installed
 Case 2 (~amd64): using system wide the unstable/~amd64 keyword
 Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1
 Case 3 (real world): get it managed with masks and keywords that the
 major packages are stable, while new features could arrive
 Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1
 Nothing new so far, now new package versions arrive:
 package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1
 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9
 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4
 So if we now update (emerge -avuND) right now the results are:
 Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed
 Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to 
 Case 3 (real world): depends on the new set of masks and keywords...
 much work ahead
 What I search is the stabilize feature for the update e.g. (emerge
 -avusND) should result in:
 Case 1 (amd64):
   - update a...@3.8 to a...@4.0, because a new stable version updates the old
 stable version
   - B, C not installed
 Case 2 (~amd64):
   - update a...@~3.9 to a...@4.0 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update b...@~1.6 to b...@1.8 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
 Case 3 (real world):
   - update a...@3.8 to a...@4.0 update stable package to newer stable version
 when arrived.
   - update b...@~1.6 to b...@1.8 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
   Optional: make is possible to ignore/filter/select the unstable to
 unstable updates, those might cause trouble.
 Anyone, could help me? Give me a hint if this would be possible? Any
 hints where in code this could be implemented? I'm programmer,
 professional, so if I get the right hints, will invest spare time in
 this. Also I'll ready to setup and run various tests. But I never before
 worked at portage...
 It might be a good start if the people with the Know-How, will start a
 discussing about this idea, what problems need to be solved, which code
 parts will need an update and so one. Than I could try to get it
 working, but right now, I doesn't even know the right questions.
 Best regards,
 - Johannes Kellner

Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-05 Thread Alistair Bush
 On 5 March 2010 12:24, Zac Medico wrote:
  It won't be pulled in by sys-apps/portage dependencies which look
  like this:
   || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6
 =dev-lang/python-3 )
  If you already have python:2.6 installed then it will not pull in a
  new slot.
 That means we would need to fix all packages that depend on
 python to use this style of dependency notation. Or do some
 eclass magic with NEED_PYTHON for example.
 And of course anyone with an unslotted dev-lang/python in their
 world file will still pull the useless version.

Then they shouldn't have dev-lang/python in their world file then should they.  
Or should we start putting special magic rules around everywhere.  Hell i'm 
sure I have useless crap in my world file,  you don't see be bitching about 
being forced to upgrade some package I never use.  If it is in there then it 
is my responsibility,  not yours.

Guys you should remember that we like to call gentoo a metadistribution [1].  
Our users should be taking an active role in the maintenance of the own distro  
what we should be doing is saying yes we have determined this package to be 
stable.  The news item should tell users they can safely mask python:3 if they 

The only concern I have is all the []dev-lang/python [R]DEPENDs there are in 
the tree.   They should be fixed to either be slotted or a dependency range.  
Thank god this will never happen again now that we have slot deps  right? 


[2]  and by this I mean looking to see what packages are going to be installed 
and whether they really want to install them.

Re: [gentoo-dev] Re: QA last rites for x11-wm/ion

2009-12-16 Thread Alistair Bush
 Le 15/12/2009 08:09, Ulrich Mueller a écrit :
  On Tue, 15 Dec 2009, Peter Hjalmarsson wrote:
  On the other hand this may be something for treecleaners? A package
  that has not been bumped for 7 years? With at least three releases
  since, and a bumprequest open for at least one year? A link to a
  webside that does not exist?
  And both its sucessors x11-wm/ion2 and x11-wm/ion3 already punted two
  years ago.
  Wasn't there some licence issue with this package, too?
 That was with ion3 IIRC. Something about the author changing the license
 from GPL to don't patch ion3 ever without telling me about it and
 showing me your patches so I can approve them.
 Or something similar, wikipedia/google might know more than me.
 As far as the original ion is concerned, the masking seems perfectly in
 order. If someone wants it, that person can step up and do the work
 (directly or via proxy).

What an angry angry man.

Drop it!!

Re: [gentoo-dev] Amount of useflags enabled by default

2009-10-23 Thread Alistair Bush
 i would like to start a discussion about reducing the amount of
  default-enabled USE flags in profiles, especially in inherited basic

Sounds like a reasonable idea to me, for the base profiles at least.

 In addition, i see a trend to enabled more more more USE flags (either over
  profiles or via IUSE +flag). Whats the reason for forcing a big load of
  default enabled USE flags on every user including more dependencies, more
  compile time, more wasted disk space and more possible vulnerabilities
  except some users, who complain about a missing feature and are not able
  to think and enable a USE flag for that feature?

 who complain about a enabled feature and are not able to think and 
disable a USE flag for that feature?

What a couple of changes make

It would be nice if we actually documented why they were enabled.  Does the 
use flag enable significant functionality that would otherwise make the 
less useful.

I believe we should be trying to find a nice 'middle of the road' balance.   DE 
related use flags should be enabled in profiles ( unless of coarse they 
package is already DE related e.g if a kde package has a use flag for kde's 
sound system, this could be enabled at a package level while a package with a 
kde use flag should not default enable it.).

So,  if we were looking at what use flags ppl are enabling/disabling we should 
be seeing similar numbers for the +'s and the -'s.  Not an easy thing to 
do, I admit.   Would be interesting if something like Color Graphing [1] or 
some algorithm could be used to determine whether a use flag should be enabled 
in a profile (including which profile)/package.  Maybe we should have some 
addition metadata for use flags.  Like a category/type/blah/blee. As an example 
we could have a category of DE containing kde/gnome/etc.  How do we know that 
the dirac use flag is codec related without knowing what dirac is?



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Alistair Bush
 Stabilization of Python 3.1.* will be requested at the beginning of
  november. There was a suggestion to create a news item which would inform
  users that temporarily they shouldn't switch to Python 3 as their main
  interpreter. Python ebuilds don't automatically activate Python 3, so I'm
  not sure if the news item is required. What is your opinion about it?


And to pacify all the cry babies out there could we update portage tools to 
call /usr/bin/python2.6 directly? (yes I realise this will break, but at least 
it is a suggestion)   Or how about we (remove python3.1 from the menu)/(stick 
a big fat warning message)/(do something else) on eselect-python.  Or create a 
system-python link that all gentoo core apps use instead of /usr/bin/python 
(longer term solution?).  [rant]Hell maybe we could even start using those 
slot dep thingy me bobbies to depend only a slot. So ppl don't have python3.1 
unless something depends on it.  Does portage have support for slots in world?

Solutions ppl.  Thats is what we need.  Not oh poor woe is me.


Re: [gentoo-dev] Re: Stabilization of Python 3.1

2009-09-19 Thread Alistair Bush
 Someone here want people install paludis? because when I've switched to
 python 3.0 just out of curiosity, it broke totally that python written
 package manager who is portage.
 So another package manager was needed to re-install a sane portage.

No it wasn't. [1]  You just didn't know that ( which is completely 
understandable ).  Just as you must not have understood the implications of 
emerge -C python:2.6.  I don't want to be mean but would you like to enlighten 
us as to how you managed to unemerge python:2.6 while using python3 when 
portage didn't work with python3.

 Still, do you really want to have it in tree as stable? Really?

Yes really.

[gentoo-dev] Patch: java-vm-2.eclass support for java build-only vm's

2009-08-24 Thread Alistair Bush
Simple patch as part of java-config's support for marking EOL and security 
vulnerable vm's to be marked as 'build only'.  Users setting these as either 
their system or user vm will be warned of the risks of doing so.

The release of java-config with this functionality, this eclass and some 
associated version bumps will all be in the tree by weeks end.

Any suggestions are welcome.

Index: java-vm-2.eclass
RCS file: /var/cvsroot/gentoo-x86/eclass/java-vm-2.eclass,v
retrieving revision 1.27
diff -u -b -B -r1.27 java-vm-2.eclass
--- java-vm-2.eclass	17 Apr 2009 22:50:41 -	1.27
+++ java-vm-2.eclass	24 Aug 2009 11:20:04 -
@@ -24,6 +24,7 @@
 EXPORT_FUNCTIONS pkg_setup pkg_postinst pkg_prerm pkg_postrm
@@ -134,7 +135,10 @@
 		 ${source_env_file} \
 		 ${env_file} || die sed failed
-	echo VMHANDLE=\${VMHANDLE}\  ${env_file}
+	(
+	)  ${env_file}
 	[[ -n ${JAVA_PROVIDE} ]]  echo PROVIDES=\${JAVA_PROVIDE}\  ${env_file}

Description: This is a digitally signed message part.

Re: [gentoo-dev] 2009 Council Elections

2009-06-26 Thread Alistair Bush

Ben de Groot wrote:
  I would think the only thing that matters is the best interest of
 Gentoo. This is after all the _Gentoo_ Council we're speaking of, not a
 body that is concerned with non-Gentoo matters.


  In my opinion it is in the best interest of Gentoo at this point to
 ignore Exherbo and to silence those people involved with Exherbo that
 have been so divisive and generated so much conflict in Gentoo channels.

Why silence what you can ignore?  Also Exherbo is the most similar
project we have to compare ourselves too.  If drobbins had ignored
freebsd where would we be now?  We shouldn't ignore anything,  debain,
suse, fedora, etc, etc, etc all have something to contribute.  Ignoring
them because we don't like their members will only make Gentoo weaker.
 We should instead be looking at what they have done that we can use to
improve gentoo.  As our closest relative ( of any distro ) having
Council members that have at least a basic understanding of what (and
how) they are attempting to achieve is a good thing.  The same goes for

 To appoint as proxy for a council meeting someone who has been booted
 from Gentoo is a clear lapse of judgement, and would in my eyes
 disqualify the involved council member from functioning in that position.

I actually look forward to seeing how he goes.

 While the other candidates certainly have great merits, they tend to only 
 one side and concentrate too much on Gentoo alone.
 I would hope so. The people we elect to the council should concentrate
 on Gentoo, otherwise they'd have a conflict of interest.

Maybe we should force Council members to disclose their involvement with
other projects?
You never know,  we might have a ubuntu dev on the council :D


Re: [gentoo-dev] 2009 Council Elections

2009-06-25 Thread Alistair Bush

Nirbheek Chauhan wrote:
 On Fri, Jun 26, 2009 at 12:30 AM, Wulf C. Krueger wrote:
 between both. This strengthening bridge of understanding can be seen in dev-
 zero's move to appoint ciaranm as his proxy for today's council meeting.

 Sorry to rain on your parade, but with ciaranm's consistent history,
 allowing him to participate in Gentoo's discussions itself is a
 privilege of patience on the part of the Gentoo community.

I would believe that recent history would show the opposite.  There seem
to be a group of developers at which the mere mention of ciaranm results
in setting them off.  Regardless of the technical merits of a solution
they seem more interested in just derailing anything that might have
anything to do with ciaramn.

I realise that ciaranm has had a nasty past.  But recently I haven't see
anything.  I for one hope that this continues and that other members of
the community take a look at themselves before spouting about the evils
of ciaramn.

 Allowing him to proxy in a council meeting is both disallowed
 (non-gentoo devs cannot be on the council), and reflects badly on the
 candidate in question (dev-zero).
Not shared by everyone.

 ~Nirbheek Chauhan

[gentoo-dev] java-utils-2.eclass patch. Support for BUILD_DEPEND being recorded within package.env.

2009-06-04 Thread Alistair Bush
Firstly, fellow developer please review this eclass patch and read on if
you are interested in what it actually does.

Java developers:

The following patch adds 3 new values to our package.env

PVR and CATEGORY being the easy ones.  These are being added because I
think they should be there and they will help with implementing a
paludis re-emerge-everything-java script.

the 3rd BUILD_DEPEND records the packages/jars that have been passed as
parameters to our java functions ( jar-from, getjars, getjar ) and also
have --build-only specified.  The format is exactly like package.env's
DEPEND variable. The main reason for this patch is to allow Serkan to
add --build-only dependencies to the classpath for java-dep-check.
java-config support is not currently planned but this may change if need be.

Here are some example package.env files.

# more
DESCRIPTION=A PSP (personal software process) time tracking utility
written in Java

 # more /var/tmp/portage/dev-java/sbaz-1.25/image/usr/share/sbaz/package.env
DESCRIPTION=A system used by Scala enthusiasts to share computer files
with each other.
--- java-utils-2.eclass.old 2009-06-04 19:46:37.711668962 +1200
+++ java-utils-2.eclass 2009-06-04 22:13:22.694684085 +1200
@@ -874,6 +874,7 @@
local destdir=.
local deep=
local virtual=
+   local record_jar=
[[ ${EBUILD_PHASE} == test ]]  build_only=build
@@ -918,7 +919,7 @@
[[ -z ${build_only} ]]  java-pkg_record-jar_ 
# setting this disables further record-jar_ calls later
-   build_only=build
+   record_jar=true
java-pkg_ensure-dep ${build_only} ${target_pkg}
@@ -928,7 +929,7 @@
if [[ -z ${build_only}  -n ${virtual} ]]; then
java-pkg_record-jar_ ${target_pkg}
# setting this disables further record-jars_ calls later
-   build_only=build
+   record_jar=true
pushd ${destdir}  /dev/null \
@@ -946,13 +947,25 @@
[[ -f ${target_jar} ]]   rm ${target_jar}
ln -snf ${jar} \
|| die Failed to make symlink from ${jar} to 
-   [[ -z ${build_only} ]]  java-pkg_record-jar_ 
${target_pkg} ${jar}
-   # otherwise, if the current jar is the target jar, link it
+   if [[ -z ${record_jar} ]]; then
+   if [[ -z ${build_only} ]]; then
+   java-pkg_record-jar_ ${target_pkg} 
+   else
+   java-pkg_record-jar_ --build-only 
${target_pkg} ${jar}
+   fi
+   fi
+   # otherwise, if the current jar is the target jar, link 
elif [[ ${jar_name} == ${target_jar} ]] ; then
[[ -f ${destjar} ]]   rm ${destjar}
ln -snf ${jar} ${destjar} \
|| die Failed to make symlink from ${jar} to 
-   [[ -z ${build_only} ]]  java-pkg_record-jar_ 
${target_pkg} ${jar}
+   if [[ -z ${record_jar} ]]; then
+   if [[ -z ${build_only} ]]; then
+   java-pkg_record-jar_ ${target_pkg} 
+   else
+   java-pkg_record-jar_ --build-only 
${target_jar} ${jar}
+   fi
+   fi
popd  /dev/null
return 0
@@ -1035,12 +1048,13 @@
java-pkg_ensure-dep ${build_only} ${pkg}
-   # Only record jars that aren't build-only
-   if [[ -z ${build_only} ]]; then
-   for pkg in ${pkgs//,/ }; do
+   for pkg in ${pkgs//,/ }; do
+   if [[ -z ${build_only} ]]; then
java-pkg_record-jar_ ${pkg}
-   done
-   fi
+   else
+   java-pkg_record-jar_ --build-only ${pkg}

[gentoo-dev] Patch to remove JAVA_PKG_VNEED support from java-utils-2.eclass

2009-05-30 Thread Alistair Bush
This patch removes the functionality within java-utils-2.eclass to
record and pass to java-config old style virtuals.
This functionality is not utilized within any repo that I know about and
is _most probably_ horribly broken anyway.

_ALL_ ebuilds that are using this functionality (aka 0) should instead
be using java-virtuals.

Java Team any issue with this patch?  The point of removing this
functionality is so I can cleanup java-config a little.


--- java-utils-2.eclass 2009-05-26 19:27:34.381359549 +1200
+++ java-utils-2.eclass 2009-05-31 16:52:09.823087313 +1200
@@ -1310,83 +1310,6 @@
-# @ebuild-function java-pkg_need
-# Adds virtual dependencies, which can optionally be controlled by a USE flag.
-# Currently supported virtuals are:
-#  javamail
-#  jdbc-stdext
-#  jaf
-#  jdbc-rowset
-#  jms
-# @param $1 - Optionally indicate that the dependencies are controlled by
-#  a use flag by specifying '--use' Requires $2.
-# @param $2 - USE flag which will enable the dependencies.
-# @param $@ - virtual packages to add depenedencies for
-# TODO rewrite to parse a line based declaration file instead -- karltk
-#java-pkg_need() {
-#  debug-print-function ${FUNCNAME} $*
-#  local useflag
-#  if [[ ${1} == --use ]]; then
-#  useflag=${2}
-#  shift 2
-#  fi
-#  if [[ -z ${1} ]]; then
-#  die Must specify at least one virtual package.
-#  fi
-#  local depstr newdepstr
-#  for virtual in $...@}; do
-#  if has ${virtual} ${JAVA_PKG_VNEED}; then
-#  debug-print Already registered virtual ${virtual}
-#  continue
-#  fi
-#  case ${virtual} in
-#  javamail)
-#  debug-print java-pkg_need: adding javamail 
-#  newdepstr=|| ( dev-java/gnu-javamail 
dev-java/sun-javamail-bin )
-#  ;;
-#  jdbc-stdext)
-#  debug-print java-pkg_need: adding jdbc-stdext 
-#  newdepstr=|| ( =virtual/jdk-1.4 
dev-java/jdbc2-stdext )
-#  ;;
-#  jaf)
-#  debug-print java-pkg_need: adding jaf 
-#  newdepstr=|| ( dev-java/gnu-jaf 
dev-java/sun-jaf-bin )
-#  ;;
-#  jdbc-rowset)
-#  debug-print java-pkg_need: adding jdbc-rowset 
-#  newdepstr=|| ( =virtual/jdk-1.5 
dev-java/sun-jdbc-rowset )
-#  ;;
-#  jms)
-#  debug-print java-pkg_need: adding jms 
-#  newdepstr=|| ( dev-java/sun-jms 
dev-java/openjms )
-#  ;;
-#  *)
-#  die Invalid virtual: ${virtual}
-#  esac
-#  export JAVA_PKG_VNEED=${JAVA_PKG_VNEED} ${virtual}
-#  if [[ -n ${useflag} ]]; then
-#  depstr=${depstr} ${useflag}? ( ${newdepstr} )
-#  else
-#  depstr=${depstr} ${newdepstr}
-#  fi
-#  done
-#  [[ -z ${JAVA_PKG_NV_RDEPEND} ]]  export 
-#  export DEPEND=${DEPEND} ${depstr}
-#  export RDEPEND=${RDEPEND} ${depstr}
 # @ebuild-function java-pkg_find-normal-jars
 # Find the files with suffix .jar file in the given directory or $WORKDIR
@@ -2541,16 +2464,11 @@
# if we're allowed to switch the vm...
elif [[ ${JAVA_PKG_ALLOW_VM_CHANGE} == yes ]]; then
-   debug-print depend-java-query:  NV_DEPEND: 
-   if [[ -n ${JAVA_PKG_VNEED} ]]; then
-   GENTOO_VM=$(depend-java-query --need-virtual 
-   else
-   GENTOO_VM=$(depend-java-query --get-vm 
-   fi
+   debug-print depend-java-query:  NV_DEPEND: 
+   GENTOO_VM=$(depend-java-query 

Re: [gentoo-dev] RFC: Gentoo Support Everywhere

2009-05-20 Thread Alistair Bush

Dale wrote:

 The Gentoo subforum on LQ would help to collect the posts in one place.

 That would be the point.  Gentoo has its own forum so why have two
 forums?  What would be the point in having two places to go look for
 answers?  Better yet, why would Gentoo support both forums?
 I'm a member at LQ tho I haven't been there in a long while.  I just
 don't see why there has to be two forums when the one forum we have is
 more than enough.  If someone can't find the Gentoo forums, I'm not sure
 they can find the chair and keyboard either.  lol

How about we ask for a subforum to be created with a BIG STICKY telling
it is better to ask support questions at

Could it be possible that users don't know about f.g.o?  ( find it
highly unlikely actually)


Re: [gentoo-dev] blocking mixed versions of split QT libraries

2009-05-18 Thread Alistair Bush

Alex Alexander wrote:
 QT doesn't work well when mixed versions of its core libraries are
 installed. Usually an emerge -avDu world solves the problem, but some
 users tend to avoid this.
 For example, lets say you have parts of QT 4.4.2 on your system. QT
 4.5.1 is available and a user decides to manually update qt-core, or
 to install KDE which has a QT dependency on a QT library not
 installed. In these cases, portage will update only a part of the
 installed QT libraries, leaving the system in a mixed state.
 QT based apps don't like that. Others will refuse to build, others
 will fail to run.
 We've managed to experimentally block partial QT upgrades by adding an
 RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
 understands this and throws out B blocks if you try to change versions
 only in parts of QT, but upgrades/downgrades fine if you do them all
 at once (or use -Du world).
 This fix also catches stale QT libraries that nothing depends on
 anymore because the user has removed whatever required them (and never
 ran --depclean).
 Unfortunately we've got reports from paludis users stating that they
 can't update QT from qting-edge anymore.

From what I understand you are utilizing portages ability to
automagically resolve blockers when all blockers will be resolved within
the current command.  Agree?? or is it the fact that you are doing
!x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?

I would suggest that you just tell paludis users to use --dl-blocks
discard when updating qt.  After looking at the eclass im not sure
whether it will work or not.  im assuming that discarding blocks will
just ignore everything, but I haven't tested it so can't be sure.

 What I'd like to discuss is the following:
 1) Is there a saner way to achieve our goal of doing whatever is
 possible to avoid mixed QT versions?

I don't believe so, not within current ways of declaring dependencies.

 2) Is our implementation considered correct and acceptable by the PMS guys?
 3) Whats the general Gentoo Policy on mixed versions? Do we care, or
 is our policy please -Du world?

I say we should be stopping them from happening.

 We've also managed to achieve the same thing by adding PDEPENDs to
 each QT library for any other QT libraries that depend on it:
 i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
 || ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
 the above (expanded for all libraries) has the same effect as the [1]
 RDEPEND but looks a bit more hackish.

And I would agree with the hackish comment.


Good work btw.


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-17 Thread Alistair Bush
Ben de Groot wrote:
 Patrick Lauer wrote:
 For quite some time (over a year, actually) we've been discussing the
 mysterious and often misunderstood GLEP55. 

 The proposed solution to a problem that is never refined, 
 This, in my opinion, is the crux of the matter. Most of us apparently
 are not sufficiently convinced that there actually is a problem. Until
 the problem is explained with clarity, the rest of the proposal is useless.
 Obviously you don't understand the issue, because if you did you'd support 
 I concur that speaking for myself, I don't understand the issue. And it
 looks like many others don't either. So if anyone wants to promote this
 GLEP, their job is clear: make people understand what the issue is here,
 and convince them it is actually an issue. (Examples, scenarios usually
 work well, indeed a lot better than calling people names.)

Is it really necessary to convince the entire community for every GLEP?
 I thought that the reason we have the council is so they can make
decisions. You know specialization of decision making.  If the council
is going to expect anyone else, besides themselves, to understand an
issue then why have the council.

 And maybe we can now spend the same amount of
 council-time (it has been eating time for over a year!) to get important 
 things done ...
 I want to call on the Council to reject this GLEP in its current form,
 as the problem has been insufficiently clarified. We should not waste
 more time on it.

I would like the Council to either accept, reject or send the GLEP back
to be clarified if _THEY_ believe it has been insufficiently clarified
to enable _THEM_ to understand the GLEP.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild

2009-05-11 Thread Alistair Bush

 You can't test FEATURES in an ebuild.  It's portage-specific.

To 1) try and turn this thread into something a little more constructive
and a little less childish; and 2) help improve the tree.  I present one
of the offending ebuilds  dev-java/commons-io

Without posting the whole file here it is

src_test() {
if has userpriv ${FEATURES}; then${T} -Duser.home=${T} \
ANT_TASKS=ant-junit \
eant test \
-Dgentoo.classpath=$(java-pkg_getjars junit) \
-Dlibdir=libdir \${T}
elog Tests fail unless userpriv is enabled because they
test for
elog file permissions which doesn't work when run as root.

I would assume it would be better to directly test whether the user is
root, than test that userpriv is set?


Re: [gentoo-dev] EAPI 3 PMS Draft

2009-04-11 Thread Alistair Bush
Ciaran McCreesh wrote:
 Unfortunately, it looks like this proposal's one of those things that
 some people will hate for ideological reasons no matter what. I just
 hope there're enough people on the Council for whom QA and user systems
 not breaking is sufficiently important that they'll vote in favour of

While I support enabling test by default I'm about to do a foot in
mouth moment and suggest something that is far too over complicated

This is a compromise between those that want tests by default and those
who don't and has these simple rules

1) Tests are enabled by default for ~arch ebuilds.
2) Tests are _not_ enabled by default for stable ebuilds.

~arch users will therefore have to explicitly disable tests and run the
risks associated with that.  My guess is that arch users are also the
ones more likely to have CFLAGS or LDFLAGS that are significantly
different from the defaults hopefully enabling tests will catch all the
issues we know that are going to have.

arch users will have to explicitly enable tests,  but hopefully by the
time a package has been marked stable it has had its unit tests ( oh im
pointing that foot in mouth again ) run enough times to verify its

Re: [gentoo-dev] EAPI 3 PMS Draft

2009-04-11 Thread Alistair Bush

Mart Raudsepp wrote:
 Enabling tests by default feels like driving users away, because all of
 a sudden their upgrades taken even more time (possibly unexplained to
 them, as an EAPI bump in an ebuild introducing it is not visible to
 them), and they'd just say to hell with it and go to a binary
 distribution that runs the tests for maintainers only, as we should.
 Yet we have the _choice_ to take that extra time and double-check on
 maintainers if they really did their job right.

I agree that before EAPI 3 hits the tree we need to do some extensive
pr.  There should be a howto on the changes and what they mean to users,
the benefits and costs etc.  How to enable/disable those changes etc etc.

But in reality all we need is 1 document, links and news items (yes more
than 1 preferably) posted on our homepage, forums, mailing lists.  Hell
even within ebuilds if it comes to that.  If after all that a user still
hasn't figured out that they need to go read that document are we really
in a position where we can do anything else.

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-03-12 Thread Alistair Bush

Michael Haubenwallner wrote:


Reminder (for myself):
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must be hackish. So we can try to find the least ugly
hack, or we need to change the extension.

So just another idea, based on the eapi() function one:
As inherit() is the only(?) global function provided by old PMs, the
first non-commentary/non-blank line in '*.ebuild' could read:

   inherit eapi

Compliant PMs identify 'eapi' as a special eclass name (with or without
sourcing the ebuild), to know that this ebuild specifies an EAPI.

For non-compliant PMs, we need to provide an 'eapi.eclass', which just
spits some 'your PM lacks EAPI support' message and causes the PM to
mask this ebuild 'by corruption' or the like.

Or - what are old PM's messages when an eclass is missing?

Eventually, this line also could finally specify the EAPI and read:

   inherit eapi 4

Because non-compliant PM's already quit because of (missing or dying)
eapi.eclass, there is no need to have a '4.eclass'.

How would the 4.eclass determine whether the package manager actually 
supports the eapi?

inherit is a function remember so any special parsing will not change 
the fact the the inherit function will be called.
Will then need to determine whether there is actually a PM that doesn't 
support the eclasses EAPI and then die.
What are the implications of calling inherit multiple times within an 

Im sorry,  but this just sounds like a HACK, and a hacky hack at that.


Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support

2009-03-08 Thread Alistair Bush

Nirbheek Chauhan wrote:

On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller wrote:

On Fri, 06 Mar 2009, Donnie Berkholz wrote:

Any thoughts?
+ *)
+ die Unknown EAPI ${EAPI}
+ ;;

Is is safe to assume that an unknown EAPI will provide a die

If we get all Ciaran-ey about that, then we can't even assume the
existence of a case statement in some future version of bash (which is
required by some EAPI)

I think in these cases we just have to use common sense.  If a function 
is deprecated or known to be 'on the way out' then using them would 
obviously be a bad idea.  On the other hand even if they are used, 
surely someone would test an ebuild and discover this case pretty quickly.

Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )

2009-03-05 Thread Alistair Bush

Caleb Cushing wrote:

I'd like to start with, I'm not trying to stir up trouble but since
questions were asked i'll answer them.

If you think neither should exist why do you have an opinion about this at all?

I merged the java-overlay into regen2 a couple of weeks ago. as of
right now I've no plans to support java-experimental.

Please don't. Until less than a month ago, it was a qa nightmare ( even 
java-overlay was).  Im sure both overlays probably still have 
unresolvable dependencies.  And yes they are an example of piss poor qa 
standards.  Even now im sure there is stuff in java-overlay that is be 
just plain broken.  I would hate to think about what java-experimental 
is like.

Re: [gentoo-dev] QA Overlay Layout support.

2009-03-01 Thread Alistair Bush

Donnie Berkholz wrote:

On 11:59 Sun 25 Jan , Alistair Bush wrote:

Possible Solution:

Merging java-overlay and java-experimental.  From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.

Combine this with package.mask. To me, experimental means masked.

Experimental within java means a lot of things,  or at least it should. 
 Anything from user contributed and non-dev qa'd to packages with 
bundled jars to attempts to package projects like maven which are 
difficult and time consuming ( and which attempts to do so have failed 
numerous times before might I add ).

Asking non-dev contributors to handle package.mask's would be a less 
than ideal. Resulting in interesting breakages.  Currently by adding 
java-experimental ( which might I add isn't available thru layman ) you 
are accepting that risk.

At least java and kde have need of this,  and I could imagine sunrise 
could also use this ( either now or in the future ).

I have implemented a patch [1] tho support this from a repoman 
perspective but believe its benefits could go much further.
Eventually I hope that zmedico will accept it, once he has a chance to 
consider it and I have time to clean it up.

Once repository support is implemented (this is very much depending on 
the details of the implementation) I will start making a patch to will 
have portage check whether an overlays parents are before that overlay.



Re: [gentoo-dev] QA Overlay Layout support.

2009-03-01 Thread Alistair Bush

Donnie Berkholz wrote:

On 19:18 Mon 02 Mar , Alistair Bush wrote:

Donnie Berkholz wrote:

Could you explain what you see as the important difference that makes 
package.mask bad and a separate overlay good?

Contributors sometimes have difficulty following standards (hell even 
dev's do).  I have little confidence that would also be able to actually 
add packages to package.mask without breaking anything else.
As an example we had a contributor break the manifests of a dozen or so 
packages because he updated the Copyright header then couldn't get the 
ebuild to manifest.  I can imagine someone committing dev-java/ant-core 
to the file.  That and there are 325 ebuilds [1] in java-experimental. 
Masking even 1/2 of them separately would be a complete nightmare.

I also note that sunrise doesn't seem to do this either.

Also no ebuilds are ever marked stable,  so it should be easy for 
someone to just add an entry in their package.keywords file.

And what is stopping a user from wanting to have their own overlay, that 
uses java-overlay ( or java-experimental or any other overlay ) 
packages.  Are we to say that we shouldn't allow tools to have support 
for this.  I think that it is a nature progression that if we are to 
allow overlays to extend the portage tree that we should allow overlays 
to extend other overlays.

[1] java-experimental $ find . -iname '*.ebuild' | wc -l

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-24 Thread Alistair Bush

Petteri Räty wrote:
 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks. Everyone is
 only allowed to post a single reply to this thread in order to make it
 easy to read through. The existing thread should be used for actual
 discussion about the GLEP and the alternatives. This should be a useful
 experiment to see if we can control ourselves :)

Thank you Petteri. I knew there was a reason I voted for you.

 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) extension
 - ignored by current Portage

a) then c).  I personally think b) is a bad idea that will just slow the
implementation of this even more.

 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension
   b) new subdirectory like ebuilds/
   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository
   c) .ebuild in current directory
   - needs one year wait

If it really comes to it  b)?  Tho it leaves a bad taste in my mouth.


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush
Luca Barbato wrote:
 Luca Barbato wrote:
 Ciaran McCreesh wrote:
 Because your proposal addresses none of the underlying problems which
 GLEP 55 was created to solve.
 let's get some numbers to have an idea of the dimension of the problem.

I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1],  we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue does, in a way ). We are trying to solve issues that ware stopping
the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
attempting to solve.


The current way of specifying the EAPI in ebuilds is flawed. In order to
get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place. Otherwise it imposes a serious
limitation, namely every ebuild, using any of the future EAPIs, will
have to be source'able by old package managers and hence there is no way
to do any of the following:

* Change the behaviour of inherit in any way (for example, to
extend or change eclass functionality).
* Add new global scope functions in any sane way.
* Extend versioning rules in an EAPI - for example, addition of
the scm suffix - GLEP54 [1].

Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush
George Shapovalov wrote:
 (Ok this thread grew too long, so I gotta chime in :))
 We could start using extended attributes or mandate reiser4 for portage dir 
 some other special in between (the inside of file and its name) feature..

1) I wouldn't use reiser4 so that would be the end of that.
2) how well do rsync and cvs support xattr's.  How about linux support
verses bsd, or windows even.
3) It is just a bad solution

 Sorry for the noise and insane implementation suggestion :)..

At least you realise it :)

Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Alistair Bush

Luca Barbato wrote:
 Alistair Bush wrote:
 I just don't think those numbers tell us anything and that should be
 obvious from anyone who has read GLEP 55[1],  we ain't really attempting
 to solve a problem that exists within the tree currently (well the bash
 issue does, in a way ). We are trying to solve issues that ware stopping
 the tree moving forward.  Lets evaluate GLEP 55 in the problems it is
 attempting to solve.
 I'm afraid you missed the whole point...
 - what is in the proposal is a solution looking for a problem: nobody
 updated the glep with the required sections, nobody put up a list of
 bugs/rfe from bugzilla it helps to solve. Vague leading to the future
 change declaration aren't what I'd expect.

So im mean't to start committing ebuilds into the tree that expect a
certain unimplemented functionality, only to file bugs against portage
for it not supporting them?  Or can we be smart enough to realise that
there are limitation to the current standard and then attempt to fix
them before they become a problem.  Plus we already know of at least one
case where we will encounter a problem in the future,  why?  because we
have already.  Not sure if there is a open bug about it tho.

This actually eats at me,  your basically saying GLEP's should only be
reactive.  Why don't we all just roll over and die.

 - Assuming there is an actual reason to move forward (by digging
 bugzilla yourself or deciding to do so as academic exercise) you could
 think about the problem and its solutions (my the email starting this
 thread on dev)

I have already considered the problems, and believe GLEP 55 is the
**best** solution to them.  Is it perfect, no.  But I have yet to see
anything better.

 - Given all you need is just to have a way to get the information about
 EAPI before you actually parse the ebuild since the eapi defines how you
 parse it, you can come up with various solutions, the simplest being
 first extract the eapi, being it in a fixed place, and then do the parse.

Yes exactly,  you need to know the EAPI before you __parse__ the ebuild.
 At least we agree that nothing should have to read the contents of the
file to determine EAPI (doing so would be parsing now wouldn't it).  So
seeing that we agree with that,  where should we stick the EAPI.

1)  How about in a flat txt file:   That would become a developers
2)  In an xml file.  Package managers would have to support xml.  Not
the best thing in the world. also could be a nightmare,  adding an entry
for every ebuild.
3)  As an xattr.  Well this idea is novel.  I bet it would make the tree
nice and stable too.  Lets not forget how annoying it will be for devs.
4) Parsing the ebuild.  But what are we parsing?,  lets not limit
ourselves to bash,  we might want to change languages completely.  If it
is bash,  what version, what if EAPI is set multiple times,  what if its
set in an eclass.
5)  M...On the file name sounds like a good idea.  especially as an
extension.  provides information to a package manager, person,
script/program without them needing to open anything.  identifies the
contents just like .txt, .c, .o, .jpeg, etc

 - Extracting such information could have different costs depending on
 where to place it.

I believe it being on the filename would be the least costly,  in terms
of processor/io at least.

Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-23 Thread Alistair Bush

Tiziano Müller wrote:
 What is proposed in glep-55 seems to aim to solve both issues at the 
 same time (it isn't stated) by switching file extension every time the 
 eapi is changed. This is slightly against the principle of the least 
 surprise and apparently is disliked by enough people to lead the 
 situation to be discussed in the council.

 Instead of switching file extension every time the eapi is changed you
 could also increment it only when a new EAPI breaks sourcing the ebuild
 compared to the requirements of the prior EAPI.
 (This way you'd in fact split EAPI into a major- and a minor-version.)

Doesn't that just add extra complexity for no gain.

Personally I don't see what the problem is with simply implementing
GLEP-55.  It's the best solution.
It should be pretty simple to implement too.  Certainly it wouldn't be
anymore difficult to implement than your solution.

Maybe once zmedico finishes his latest development push I will attempt
to implement it.

[gentoo-portage-dev] repoman Parent repository support patch

2009-02-06 Thread Alistair Bush
it was suggested to me that I should post my patch to this ml.   So here
it is.

Located at

you will find a patch for repoman to support a hierarchy of overlays by
allowing an overlay to specify its parents.  I have recently been using
this patch over java-experimental to solve the absolute mess we have
created there.

I would like to thank zmedico for the help he has given me on this.

Thinks to note/discuss.

An overlays parents are specified as a space separated list of
pkg_names, with a key of masters, located with a file metadata/layout.conf.


masters = gentoo java-overlay

gentoo is implied and assumed so is not necessary ( and is actually
filtered out within the code as it isn't an overlay). The reason I have
this is to maintain compatibility with other package managers and
because being explicit is a good thing.  If we were to change this then
it would be sensible to also change the file name.  Other package
managers also store other variables within this file.  I propose that
they are just ignored.  I have not currently implemented the validation
classes that can be used by KeyValuePairFileLoader.

[gentoo-dev] QA Overlay Layout support.

2009-01-24 Thread Alistair Bush
Here is an issue that is currently being faced by the java project that
I would like to bring to the attention of everyone.  I have already
discussed this will devs from all pm's.


Within the java project we have 2 overlays.  java-overlay and
java-experimental.  java-overlay is mean't to be a stable overlay, is
available through layman while java-experimental is the opposite.  We
attempt to not add packages to gentoo unless they are a dependency or an
application to help with maintainability.  We allow newbies access to
java-experimental and there are a number of packages that are difficult
to support so are still very much experimental.

The way we are currently using the overlays results in a hierachy of
gentoo  java-overlay  java-experimental.  Where
packages/eclasses/profiles can be inherited from the previous repository.


Repoman currently only checks the current repository/overlay and gentoo.
 This is a problem for java-experimental.

These are the following problems:-

1)  repoman does not find eclasses used to by java-experimental ebuilds
that are located in java-overlay.  see [1] for error.  Maintaining the
eclass in multiple locations _is not a solution_.(zmedico is expecting
to add repository support at some point with support for specifying
ECLASSDIRS.  So this issue may be resolved).

2)  repoman does not find packages used to by java-experimental ebuilds
that are located in java-overlay.

Now this might be a result of the package not existing within gentoo or
as a result of a particular version/slot being available within
java-overlay.  Now zmedico suggested that the use of repository deps (
aka ::java-overlay )  could be the solution.  I would rather this not be
the solution as packages shouldn't need to be edited to more them
between overlays.  Also the dependency specified could be moved into gentoo.

Possible Solution:

Now im going to shoot myself in the foot here by mentioning the

( -- ) paludis ( -- ) currently has support for specifying an
overlays parent(s) (master_repository) within an overlays
metadata/layout.conf file.   Now i'm not suggesting that paludis's
implementation is the correct one,  but I believe the concept is solid.
 By specifying an overlays parent repositories would allow (at least):

1)  emerge to error if that repository/overlay is not configured.; and
2) repoman to locate packages by checking the current overlay, gentoo as
well as the parents specified within an overlay metadata file

Possible Solution:

Merging java-overlay and java-experimental.  From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.


Do you support the overlay metadata file concept?
Are there any other possible solutions?
Is there anything stopping this from being implemented?  another EAPI?
profile EAPI?
Is there anything else that would benefit from an overlay metadata
file?  Default conf variables e.g ECLASSDIRS.
Any other comments?


Alistair Bush
Gentoo Linux Developer

* ERROR: dev-java/commons-jelly-tags-util-1.0 failed.

 * Call stack:

 *, line 1881:  Called source

 *   commons-jelly-tags-util-1.0.ebuild, line7:  Called inherit

 *, line 1238:  Called qa_source

 *, line   37:  Called source

 *  commons-jelly-tags-2.eclass, line   30:  Called inherit
'java-pkg-2' 'java-ant-2' 'java-maven-2'

 *, line 1215:  Called die

 * The specific snippet of code:

 *  [ ! -e $location ]  die ${1}.eclass could not be
found by inherit()
 *  The die message:

 *   java-maven-2.eclass could not be found by inherit()


 * If you need support, post the topmost build error, and the call stack
if relevant.
 * This ebuild used the following eclasses from overlays:




 * This ebuild is from an overlay:

~amd64(default/linux/amd64/2008.0/server) ['dev-java/swingx']

dev-java/swingx is located in java-overlay.

Re: [gentoo-dev] QEMU Sick!

2009-01-22 Thread Alistair Bush

Dale wrote:
 I don't think Gentoo is broke.  It may be a wrong setting or something
 misconfigured on your system but Gentoo works.
 I really think you need to take this to -user tho.  This thread really
 needs to be there instead of on -dev.
 :-)   :-)

This thread doesn't need to be anywhere.  Talk about the wrong approach
to solving a problem.  Just let this die.

There are much more constructive ways of improving Gentoo.  Please take
full advantage of, our forums and irc channels.
Constructive suggestions/patches/improvements can also be brought up
either within gentoo-dev ml or another project specific ml.


Re: [gentoo-dev] reorganization of /var/lib gentoo-related files

2009-01-01 Thread Alistair Bush

Maciej Mrozowski wrote:

On Wednesday 31 of December 2008 17:28:09 Ciaran McCreesh wrote:

You could use the same argument to say Gentoo must switch to RPM
because LSB says so.

No, I would be invalid argumentation - I know it - you know it, so let's not 
continue with discussion of this kind until one side will EOT seeing it's 
pointless, while the other side will secretly announce epic victory ;)

I actually agreed with Ciaran on this point. especially seeing I would 
like us to follow the parts of LSB that make sense within the Gentoo 
ecosystem.  (take Init Script Actions as an possible example

It's not the point to blindly follow freedesktop or LSB - the point is to 
consistently follow one standard across whole distribution - if it's FHS - 
fine, if not - fine as well - but *only one* at a time.

 That being said I'd rather propose to force Gentoo news to comply to 
FHS as

 FHS is the most commonly used file/directory layout in Gentoo.

This really is bikeshedding..   Isn't consistently following a 
standard also blindly following it.  So when you ask us to consistently 
follow FHS why not ask for us to blindly follow it.

Man this is getting boring.

cheers in new year

Re: [gentoo-dev] Keyword policy for non standard things

2008-10-22 Thread Alistair Bush

Dawid Węgliński wrote:
 Hello fellow developers and users.
 I'd like to know your opinion of bug #243050 [1]
 01:18:59   cla @| If user bothers to patch his kernel, he can bother 
 to add proper package.keyword line, imo.


 01:21:52   hparker @| Or maybe get the patches added to gentoo-sources

or ++

maybe we can get the pm's to implement this as EAPI=999,999,999.99
I suggest a syntax of virtual/kernel:::user_patched

On a more serious note, How can we confirm a package is stable when we
can't confirm the kernel it depends on is?

I would have no problem with gentoo-sources also including a use flag(s)
( or not ) and having it add patches to support software we have within
the tree.   I have no say in that tho.


[gentoo-dev] changing EAPI on existing ebuilds. To bump or not?

2008-09-29 Thread Alistair Bush
I was thinking about this a day or 2 ago and just noticed that a similar
situation has come up.

Please refer to but

=dev-java/ant-antlr-1.7.1 was changed from EAPI=1 to EAPI=2 to take
advantage of the use flag dep functionality.

now, I normally take the approach that if the change I am making to an
ebuild effects the installed files then I bump.

But what is the best thing to do here.

Some things to note is that this ebuild is ~arch and EAPI=2 is also
~arch.  Obviously if the ebuild was arch then changing to a ~arch EAPI
would be a no-no.  Are there any other situations which are definite

Anyway,  would be nice to get some feedback, idea's on this and
hopefully also a more detailed explaination from a pm's perspective (if
there is one).



ps. If changing EAPI is bad then maybe repoman should check for it.

Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Alistair Bush

Patrick Lauer wrote:

On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:

On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote:

At this point, we should really only discuss features that all 3 package
managers have implemented.

I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

Yes, but noone cares about Paludis.

Now could you please do the rest of us a favour and keep the discussion 
focussed on improving technical details instead of random insults at others?

Isn't that, in itself, an insult and you don't seem to have advanced the 
discussion at all.

-- mailing list

Re: [gentoo-dev] A few questions to our nominees

2008-06-08 Thread Alistair Bush

Piotr Jaroszyński wrote:


looks like every nominee wants the council to be more technical so I
have a few technical questions for you:

1. GLEP54
2. GLEP55
3. Most wanted changes in future EAPIs

4. Strategies to ensure that gentoo's package manager is able to 
quickly/smartly/sainly support future EAPI's, GLEP54, GLEP55?

[1] -
[2] -

-- mailing list

Re: [gentoo-dev] Removing .la files...

2008-04-19 Thread Alistair Bush

Wulf C. Krueger wrote:


I think flameeyes should have sent this himself in the first place, but 
since he's clearly not going to do that and prefers to just force it on 
our users I'm mailing this...

Have we not learn't!  I hardly think that revdep-rebuild is an obvious 
solution to this issue.  So now we have doomed our users ( and some of 
our dev's ) to having to search for a solution.  I note that within the 
ebuild there isn't even a elog explaining what to do.  If we are going 
to make changes like this we need to provide an effective news service.

I'm sure this was one of the issues that arose during the hot house 

I actually find this incident rather depressing. especially after we 
(seem to) have done so well with the baselayout/openrc migration. ( I do 
realise that one is significantly bigger than the other and therefore 
requires a bigger fan fair ).

flameeyes talked about .la files in his blog recently:

Im sure everyone will find that

Now he decided that simply removing them for several packages, resulting 
in and its dupes.

What a surprise.  never could have guessed.

This is annoying for quite a few users as they will have to rebuild lots 
of stuff for KDE, Gnome and other packages and I'm not sure if this is 
really the way we want to fix --as-needed failures.

++.  We sure do like to annoy our users.

Furthermore, such things should not be decided and pushed through 
unilaterally but be agreed upon here prior to doing this change. 

++.  I actually have no problem with agreeing with it,  currently my 
problem is the complete and utter lack of any _planned_ upgrade path. 
What do we think users are going to be saying at the end of the year 
when after every sync they have to revdep-rebuild.  Maybe, if we proceed 
with this, we investigate what can have its la files removed and do it 
all in one go.  therefore ppl won't have to rebuild kde/gnome ( or any 
other large and time consuming package) over and over and over and over 
and over and over ... again.  Hell it would even be better to 
batch a few conversions so that each revdep-rebuild fixes multiple 
breakages in one.

Especially since even though removing .la files might make sense (with 
exceptions, of course) we should think about either doing it 
distribution-wide or not at all.


-- mailing list

Re: [gentoo-dev] Strange behavior of fonts... help :(

2008-03-03 Thread Alistair Bush
This is not a support channel and that, while an interesting picture, 
provides absolutely no information whatsoever.

Please don't post to the gentoo-dev ml.

-- mailing list

Re: [gentoo-dev] The app-misc/beagle in portage is seriously outdated!

2008-02-28 Thread Alistair Bush

Shaochun Wang wrote:

Hi all:

BTW, besides the beagle bump request in the bugzilla of Gentoo, is there
any way to let us normal users get beagle up to date?

Im sure that there are more than a few dev that would be willing to 
proxy maintain the package, if a user is prepared to standup and take 
responsibility for it.  Currently it seems that the package doesn't 
build for everyone ( by having a quick look at #201093 ) and this is 
something that any maintainer would have to rectify [1].

If your prepared to do it there are plenty of resources to help you 
along.  Checkout and jump on 
irc://freenode/#gentoo-dev-help if you have any ebuild related questions.


[1] Sometimes I get the impression that users think that as long as a 
package works for them, that it works.  This sadly isn't the case.

-- mailing list

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

2008-01-19 Thread Alistair Bush

Tiziano Müller wrote:

Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)

Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one maintainer


- Is recording an upstream-status (active/inactive) a good idea?

Maybe, leaning to No.

What about packages that have multiple slots, e.g php-4, php-5?  one 
slot could be inactive the other not, does that make upstream active?

An element: status{active/inactive}/status

	Status of what? seeing you have proposed a upstream-status and a 
maintainer status. what else is there left to status :P

An attribute: maintainer status={active/inactive}...
	No.  As i'm pretty sure that every inactive maintainer won't go around 
updating their packages metadata.xml

- Is an additional doc element needed to link to upstream docs
Interesting. what about the situation where upstream documentation sucks 
but there is a better resource provided by a third party, could we 
link to that? e.g. for bash is an excellent resource
Multiple doc links? 
docsofficial-doc/official-doc/doc/doc//docs could provide 
that.  Only concern I see is that this could relate to an endorsement of 
thirdparty websites, which may change negatively ( porn on ) or 
my just become outdated.

Actually without the multiple official/unofficial doc tags I would have 
to say No.  as 99% of the time it would just be ${HOMEPAGE}/doc or 
there would be a big fat link from the homepage and therefore would be 
of no real benefit.


-- mailing list

[gentoo-dev] New eclass osgi.eclass

2007-12-05 Thread Alistair Bush
On behalf of Elvanor ( a in the process New Developer ) I would like to
present the osgi.eclass.

What is OSGi, well

Copied directly from wikipedia [1]

The Framework implements a complete and dynamic component model,
something that is missing in standalone Java/VM environments.
Applications or components (coming in the form of bundles for
deployment) can be remotely installed, started, stopped, updated and
uninstalled without requiring a reboot; management of Java
packages/classes is specified in great detail. Life cycle management is
done via APIs which allow for remote downloading of management policies.
The service registry allows bundles to detect the addition of new
services, or the removal of services, and adapt accordingly.

Basically and for all the purposes that you will care about, the eclass
adds information to a jar's Manifest file that can then be used by the
OSGi framework ( aka currently eclipse ).  Without this functionality we
will not be able to use system jars for our eclipse package.

you may find an example ebuild that uses the osgi class at

and the eclass is attached and located at

Im sure Elvanor can't wait for you constructive feedback on his eclass
and depending on your feedback the eclass will enter the tree this weekend.


# Base eclass for Java packages that needs to be OSGi compliant
# Copyright (c) 2007, Jean-Noël Rivasseau [EMAIL PROTECTED]
# Copyright (c) 2007, Gentoo Foundation
# Licensed under the GNU General Public License, v2
# $Header: /var/cvsroot/gentoo-x86/eclass/java-utils-2.eclass,v 1.92 2007/08/05 
08:17:05 betelgeuse Exp $

# -
# @eclass-begin
# @eclass-shortdesc Java OSGi eclass
# @eclass-maintainer [EMAIL PROTECTED]
# This eclass provides functionality which is used by
# packages that need to be OSGi compliant. This means
# that the generated jars will have special headers in their manifests.
# Currently this is used only by Eclipse-3.3 - later
# we could extend this so that Gentoo Java system would be
# fully OSGi compliant.
# -

inherit java-utils-2

# We define _OSGI_T so that it does not contain a slash at the end.
# According to Paludis guys, there is currently a proposal for EAPIs that
# would require all variables to end with a slash.


# -
# @ebuild-function _java-pkg_osgi-plugin
# This is an internal function, not to be called directly.
# @example
#   _java-pkg_osgi-plugin JSch
# @param $1 - bundle name
# --

_java-pkg_osgi-plugin() {
# We hardcode Gentoo as the vendor name

cat  ${_OSGI_T}/tmp_jar/ -EOF

# -
# @ebuild-function _java-pkg_osgijar
# This is an internal function, not to be called directly.
# @example
#   _java-pkg_osgijar dist/${PN}.jar com.jcraft.jsch com.jcraft.jsch, 
com.jcraft.jsch.jce;x-internal:=true JSch
# @param $1 - name of jar to repackage with OSGi
# @param $2 - bundle symbolic name
# @param $3 - export-package-header
# @param $4 - bundle name
# --

_java-pkg_osgijar() {
debug-print-function ${FUNCNAME} $*
[[ ${#} -lt 4 ]]  die At least four arguments needed

mkdir ${_OSGI_T}/tmp_jar || die Unable to create directory 
[[ -d ${_OSGI_T}/osgi ]] || mkdir ${_OSGI_T}/osgi || die Unable to 
create directory ${_OSGI_T}/osgi

local jar_name=$(basename $1)
cp $1 ${_OSGI_T}/tmp_jar  pushd ${_OSGI_T}/tmp_jar  /dev/null
jar xf ${jar_name}  rm ${jar_name}  popd  /dev/null || die 
Unable to uncompress correctly the original jar

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %bundleName
Bundle-Vendor: %vendorName
Bundle-Localization: plugin
Bundle-SymbolicName: ${2}
Bundle-Version: ${PV}
Export-Package: ${3}

_java-pkg_osgi-plugin ${4}

jar cfm ${_OSGI_T}/osgi/${jar_name} 
-C ${_OSGI_T}/tmp_jar/ .  /dev/null || die Unable to 
recreate the OSGi compliant jar
rm -rf ${_OSGI_T}/tmp_jar

# -
# @ebuild-function java-pkg_doosgijar
# Rewrites a jar, and 

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild

2007-10-13 Thread Alistair Bush
 On 13:25 Fri 12 Oct , Remi Cardona (remi) wrote:

 file :
 pkg_postinst() {

 pkg_postrm() {

While you guys are on this subject, I thought I would put in the
experience I just had.

As you will note in the ebuild above I inherit distutils and then



and have my 2 functions as so

pkg_postrm() {

pkg_postinst() {

Firstly it is interesting to note that you must call *python_version
before distutils_pkg_postrm while distutils_pkg_postinst handles this

Is this a good solution? Would it also be a good solution in your case?

PYTHON_MODNAME from my understanding what i've investigated will accept
a list of modules if you need it to.

Anyway, hopefully this helps.


ps.  My python experience has not left the realm of java-config and I
have only done 2 releases, 1 1/2 of which I completely screwed up.  I am
no expert and have no idea whether the above is correct, valid or
otherwise safe for human consumption. Don't complain!!
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: java-utils-2.eclass java-virtuals-2.eclass

2007-10-05 Thread Alistair Bush
Yes it is cool, and the eclass will be updated.

Thank you dberkholz

Duncan wrote:
 Donnie Berkholz [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Thu, 04 Oct 2007
 19:00:02 -0700:
 You can use a neat trick with a code block here, along these lines:

  echo foo
  echo bar
  echo blah
 }  file

 It avoids the possibility of a typo when you're retyping the same
 filename multiple times, plus it's just cool.
 Wow, that /is/ cool!  Learned something new today! =8^)
 You are putting an awful lot of work into these lookovers.  Just some 
 thanks from this user, in case you haven't heard enough of it lately.  
 Gentoo's surely the better for it! =8^)
[EMAIL PROTECTED] mailing list

[gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush
I would like to commit a new java eclass within the next week.

This eclass is designed to support the functionality that Betelgeuse
outlined within a previous post.[1]

As you will be able to see, this eclass is very simple and only uses
functionality that will be provided by the java-utils-2.eclass (see the
attached patch )

Basically all the happens is that a file is created under
that contains (at present) 3 variables.  This file is then read by our
java-config-2 application.

The eclass is currently implemented within the java-virtuals overlay for
those who are interested

Any suggestions, improvements and of course approvals will be gladly

Go the All Blacks!!



On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:

 We want to implement virtuals for Java at some point and for that we
 need to know the package that provides the virtual because some virtuals
 can be provided by the JDK or normal packages and this affects the JDK
 selection at build time. One option is to call into Portage to find this
 out, but of course Paludis and Pkgcore people most likely don't like
 this approach. One thing that comes to mind is to allow for virtuals to
 install files so we can install the provider information in a format
 easy for us. We need the information in format ${PN}-${SLOT} because
 that's the way we install in /usr/share. So do you think it's ok for
 virtuals to install files (we can of course call the category
 java-virtual/ too), should we call Portage code, or do you have an
 another idea?
--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass2007-08-05 
20:17:05.0 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass2007-09-12 
22:23:53.0 +1200
@@ -2196,6 +2286,8 @@
+   JAVA_PKG_VIRTUALS_PATH=${DESTTREE}/share/java-config-2/virtuals
[[ -z ${JAVA_PKG_JARDEST} ]]  
[[ -z ${JAVA_PKG_LIBDEST} ]]  
@@ -2220,58 +2312,71 @@
 java-pkg_do_write_() {
debug-print-function ${FUNCNAME} $*
-   # Create directory for package.env
-   if [[ -n ${JAVA_PKG_CLASSPATH} || -n ${JAVA_PKG_LIBRARY} || -f \
-   ${JAVA_PKG_DEPEND_FILE} || -f \
-   # Create package.env
-   (
-   echo GENERATION=\2\
-   [[ -n ${JAVA_PKG_CLASSPATH} ]]  echo 
-   [[ -n ${JAVA_PKG_LIBRARY} ]]  echo 
-   [[ -n ${JAVA_PROVIDE} ]]  echo 
-   [[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
-echo DEPEND=\$(cat 
${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
-echo OPTIONAL_DEPEND=\$(cat 
${JAVA_PKG_OPTIONAL_DEPEND_FILE} | uniq | tr '\n' ':')\
-   echo VM=\$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ 
/\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\ # TODO cleanup !
-   )  ${JAVA_PKG_ENV}
-   # register target/source
-   local target=$(java-pkg_get-target)
-   local source=$(java-pkg_get-source)
-   [[ -n ${target} ]]  echo TARGET=\${target}\  
-   [[ -n ${source} ]]  echo SOURCE=\${source}\  
-   # register javadoc info
-   [[ -n ${JAVADOC_PATH} ]]  echo 
-   # register source archives
-   [[ -n ${JAVA_SOURCES} ]]  echo 
-   [[ -n ${GENTOO_COMPILER} ]]  echo 
-   # extra env variables
-   if [[ -n ${JAVA_PKG_EXTRA_ENV_VARS} ]]; then
-   cat ${JAVA_PKG_EXTRA_ENV}  ${JAVA_PKG_ENV} || die
-   # nested echo to remove leading/trailing spaces
-   echo ENV_VARS=\$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\ \
-${JAVA_PKG_ENV} || die

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush

Donnie Berkholz wrote:
 On 23:20 Thu 20 Sep , Alistair Bush wrote:
 -# Create package.env
 -echo GENERATION=\2\
 -[[ -n ${JAVA_PKG_CLASSPATH} ]]  echo 
 -[[ -n ${JAVA_PKG_LIBRARY} ]]  echo 
 -[[ -n ${JAVA_PROVIDE} ]]  echo 
 -[[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
 - echo DEPEND=\$(cat 
 ${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
 - echo OPTIONAL_DEPEND=\$(cat 
 ${JAVA_PKG_OPTIONAL_DEPEND_FILE} | uniq | tr '\n' ':')\
 -echo VM=\$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ 
 /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\ # TODO cleanup !
 -)  ${JAVA_PKG_ENV}
 Why not use a code block {} instead of a subshell ()?

You would have to ask the original author about that, but point taken.

 -# register target/source
 -local target=$(java-pkg_get-target)
 -local source=$(java-pkg_get-source)
 -[[ -n ${target} ]]  echo TARGET=\${target}\  
 -[[ -n ${source} ]]  echo SOURCE=\${source}\  
 -# register javadoc info
 -[[ -n ${JAVADOC_PATH} ]]  echo 
 -# register source archives
 -[[ -n ${JAVA_SOURCES} ]]  echo 
 -[[ -n ${GENTOO_COMPILER} ]]  echo 
 I don't understand why all these things are done down here instead of in the 
 same code block as $JAVA_PKG_ENV is created.

That to is also historical, and i'm less inclined to changed it. I've
already broken the tree once with a eclass change, breaking this would
completely break java support.  It could be updated as part of our
general QA, but I believe that it should be done separately, and not
bundled in with the changes i've made.

 -# Strip unnecessary leading and trailing colons
 -# TODO try to cleanup if possible
 -sed -e s/=\:/=\/ -e s/:\$/\/ -i ${JAVA_PKG_ENV} || 
 die Did you forget to call java_init ?
 +if [[ $1 != provider ]]; then
 Could you explain what the next section is supposed to do, as opposed to 
 the above section? Are they expected to be mutually exclusive? The 
 comments suggest so, since both have a 'Create package.env'. But the 
 tests suggest otherwise, since it's not an if...else pair.

normally java-pkg_do_write_ is called to write the package.env out, as
can be seen, and is the default behavior for the function.  What I am
adding is the ability to _do_write of a [virtual|provider].env file.
While at present it only contains 3 variables, I see no reason why
eventually it will not include other vars that are shared between the
package.env and virtual.env ( e.g DESCRIPTION )

Therefore this change can be summarized as

+ if [[ $1 != provider ]]; then
#Do the default package.env behaviour
+ else
+   #Create a virtual.env file. This will only be invoked by
+   #ebuilds that inherit java-virtuals.eclass
+ fi

I could very well reflactor the java-pkg_do_write_ function back to its
current state and create a new function java-pkg_do_write_virtual to be
called by java-virtuals-2.eclass.

The documentation could (and will) be updated to more correctly reflect
whats happening.

 +# Create directory for package.env
 +if [[ -n ${JAVA_PKG_CLASSPATH} || -n ${JAVA_PKG_LIBRARY} || 
 -f \
 +# Create package.env
 +echo GENERATION=\2\
 +[[ -n ${JAVA_PKG_CLASSPATH} ]]  echo 
 +[[ -n ${JAVA_PKG_LIBRARY} ]]  echo 
 +[[ -n ${JAVA_PROVIDE} ]]  echo 
 +[[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
 + echo DEPEND=\$(cat 
 ${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
 + echo OPTIONAL_DEPEND=\$(cat 

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush

Donnie Berkholz wrote:
 On 06:58 Fri 21 Sep , Alistair Bush wrote:
 normally java-pkg_do_write_ is called to write the package.env out, as
 can be seen, and is the default behavior for the function.  What I am
 adding is the ability to _do_write of a [virtual|provider].env file.
 While at present it only contains 3 variables, I see no reason why
 eventually it will not include other vars that are shared between the
 package.env and virtual.env ( e.g DESCRIPTION )

 Therefore this change can be summarized as

 + if [[ $1 != provider ]]; then
  #Do the default package.env behaviour
 + else
 +#Create a virtual.env file. This will only be invoked by
 +#ebuilds that inherit java-virtuals.eclass
 + fi

 I could very well reflactor the java-pkg_do_write_ function back to its
 current state and create a new function java-pkg_do_write_virtual to be
 called by java-virtuals-2.eclass.

 The documentation could (and will) be updated to more correctly reflect
 whats happening.
 I'm concerned about code duplication, because that's what it looks like. 
 Refactoring might be a good idea.

Ok, thanks for the input Donnie. I will refactor it before goes into the

Any more input ppl?


[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] USE flag how are they supposed to work?

2007-09-08 Thread Alistair Bush


Local and Global USE Flags

USE flags are categorised as either local or global. A global USE flag
must satisfy several criteria:

* It is used by many different packages.
* It has a general non-specific purpose.

The second point is important. If the effect of the thing USE flag upon
pkg-one is substantially different from the effect it has upon pkg-two,
then thing is not a suitable candidate for being made a global flag. In
particular, note that if client and server USE flags are ever
introduced, they can not be global USE flags for this reason.

Before introducing a new global USE flag, it must be discussed on the
gentoo-dev mailing list.

Steen Eugen Poulsen wrote:
 I'm trying to write a Replicator for /etc/portage and that leads me to
 work with USE flags, trying to design the replication of them among
 similar systems, but I can't find the golden set of rules for how best
 to apply USE flags.
 There seem to be a global/local USE flag system, but many so called
 global flags has duplicated description marking them as local flags, or
 they enable unneeded optional support.

Unneeded by whom? As for the duplicate local USE flags,  They are most
probably redundant.

 Lets take one of the big ones python. This use flag enables optional
 python support in many packages, I don't see my system ever using the
 python support in most of these. Seems like it really should be a local
 pr. packet flag for most, a pythonapi flag perhaps.

See above.  Also note that you are not enabling support for pythonapi,
you are enabling support for python.  Would you enable support for
linuxheaders when you are without a linux kernel.

 There is also a few cases where package X requires package Y to be
 compiled with an USE flag, but no testing is being done in the ebuild
 for it and the compilation fails. Example gnome-system-tools requires
 libxml2 to be compiled with python support.

If that is the case, then I would suggest you search bugzilla and then
file a bug.

 Then there is flags like alsa, it's marked as a global flag and then
 virtualbox also has it marked as a local flag. I personally think
 virtualbox is somewhat right in saying it's a local flag, but perhaps it
 would be better if the flag didn't have a double meaning.

See above.  I can only assume that virtualbox doesn't need to have a
local alsa use flag.

 As I see it, Gentoo's USE flag system is one of it's greatest strength,
 but at the moment seems like there is missing some overall design for
 how to implement USE flags, making it a lot harder to use USE flags, as
 there is no clear definition of global or local flags.
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] USE flag how are they supposed to work?

2007-09-08 Thread Alistair Bush
Ok, so I think I understand where you are coming from...

Firstly,  USE flags are not meant to have a specific purpose. Enabling
python support is non-specific as it doesn't describe how it is enabled
or what python support actually is.

Lets compare 2 packages to demonstrate...

subversion has a python use flag,  this flag will install a subversion
api for python.  so within python you an interact with subversion.

as another example.

vim also has a python use flag.  this flag enables the ability to
execute python commands from within vim.

_But_ it is important to note that nowhere does the python use flag
attempt to distinguish between the 2 types of support. This is where I
believe you are getting stuck.

The reason for having non-specific use flags is otherwise we would have
hundreds of duplicate local use flags whose descriptions differ only
slightly. We are not attempting to document all the functionality of
each package.  It is up to you to discover what packages you want to
have python support.

 The words is given different meaning depending on whatever I'm looking
 at the portage tree or working on configuring emerge. The portage trees
 global flag, is no indication whatever I should put the flag in USE=
 in make.conf, in many cases a portage tree global flag is more an
 indication that I should use it locally pr. package.

well I would only agree with that if you correlate the global status of
a USE flag to the number of packages that use it and you are wanting to
only enable the bare minimum use flags for the pacakges that you require.

But anyway, in summary

If you want to find out what a packages USE flag does,  it is better to
read the upstream documentation.
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] My turn to wear the cursed medalion of retirement

2007-03-18 Thread Alistair Bush

Hi Alexandre.

I too would like to hear what your ideas are for the metastructure of
gentoo.  Please if you dont feel up to officially submitting them then at
least submit them to this list.


On 3/19/07, Seemant Kulleen [EMAIL PROTECTED] wrote:

Hi Alexandre,

Good luck in your new life.  My only comment is that I think you copped
out by not submitting your proposals for any sort of peer review.  You
succumbed to the possibility (that you seem to think is more of a
probability -- you may be right, I don't know) that it would not be
received well.  I think it's a shame to succumb to such a fear (or any
fear), and I wish you hadn't.

I do understand where you're coming from, however, and I tend to agree
with most of your ideas on the addition of bureaucratic layers and rules
 regulations.  I struggle with whether or not that's simply a necessary
by-product of the size and scope (I use the term loosely) of the



Re: [gentoo-dev] Suggestion

2007-02-08 Thread Alistair Bush
On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
 Hi all,

 A friend of mine and myself are willing to develop some tools to help
 ebuild development.

 We have some constraints, but we are thinking on something like:
 1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
  1.1) Where are the sources?
  1.2) Decompression algorithm?
  1.3) Compile the sources?
  1.4) Install man page(s)?
  1.5) Install documentation?
  1.6) Bind actions to USE flags?
 It would probably be interesting to define a set of pre-defined categories:
 standard GNU Autotools projects, perl/CPAN modules, python, ...

I see no reason why a good template and/or eclass can't handle this

 2) A tool to deal with the unstandarized way to compile and install Java
 projects. The idea is to write a tool to try to find out:
   2.1) Where are located the main .java sources.
   2.2) Where are located the unit tests.
   2.3) Where are the jar files generated (in case of Ant-based builds) when
 the project is built.
   2.4) Where to get the dependencies.
 And once this information is available, fill the blanks of a pre-defined
 Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
 would allow compilation flags even if the original build mechanism didn't.
 We probably will ask for this specific issue to gentoo-java mailing list.
 We don't think a fully-automated tool is feasible to cope with all kind of
 projects, but we hope it could be of use for Java developers who don't use
 Gentoo but find interesting to get an ebuild with little effort.

I apologies as this will be critical.

Firstly I would be very interested in how you would handle to dependencies of 
a package within this build system.  Maven is natorious for wanting to 
download its dependencies (including plugins all its plugins) from a remote 
repository.  Something that the java team (and me personally) have been 
struggling with for sometime.

Secondly the java-*-2 eclasses are now very advanced wrt everything ant.   
They abstract a large portion of the functionality away from the ebuild 
(without lossing the flexability)

So here an anottated vim template that I currently use and that will hopefully 
( bug #164953 ) make it into the tree. 

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

JAVA_PKG_IUSE=doc source  #this appends the appropriate deps to

inherit java-pkg-2 java-ant-2





RDEPEND==virtual/jre-1.4   #this is used by eclasses to determine the target 
class version
DEPEND==virtual/jdk-1.4#and this determines the source target


src_install() {
java-pkg_dojar ${PN}.jar
use doc  java-pkg_dojavadoc build/javadoc
use source  java-pkg_dosrc src

I find this ebuild template usually provides everything a java ebuild 

I would suggest you read the dev notes on the gentoo-java project page as well 
as reading the wiki.

 However, we are just in the definition stage. We haven't decided anything
 yet, and would like to know your suggestions, even if they aren't
 encouraging :).

 Thank you very much.

Please don't let me discourage you.  I would be very interested in your 
solutions for using maven and I believe the when 2.0.5 is released some form 
of pom re-writing could be possible (similar to what happens with build.xml 
files at the moment), but I dont believe there is a need to mavenify ant 
builds.  I believe it would be over complicated and have huge problems 
handling where the src and libraries within a package reside.   When it comes 
to ant (at least) I believe the present solution is far more adaptable and 

-- mailing list