[gentoo-dev] seeking maintainer(s) for dev-util/eclipse-sdk

2007-08-01 Thread Joshua Nichols
Hey folks,

Eclipse 3.3 has been out for a bit now, and 3.2.2 even longer, and I
haven't had the time to sit down to get either fully packaged. So, I'm
looking for someone to step up and maintain it.

So here are some details about the package:

 * It is in dual-herd: dev-tools and java
 * We work with other downstream packagers as part of the Eclipse Linux
Distrubtions project. Mostly, we share patches that make things a bit
saner in a Linux environment.
* The ebuild is pretty long, at 403 or so lines
* There's a lot of patching/tweaking going on. There's some 26 patches,
10 or so seds, and some miscellaneous changes that occur.

In addition to eclipse-sdk itself, there are a number of Eclipse plugins
in the tree. At this point, they've started to get a bit crufty. We've
generally been encouraging people to use the update manager for now.
Fortunately, some of the other downstream peeps have come up with a sane
method for maintaining plugin packages. But, we'd need to get 3.2.2 or
3.3 package before we can pursue it.

I did write up some notes awhile back on the Java wiki:

https://overlays.gentoo.org/proj/java/wiki/Eclipse_Maintenance
https://overlays.gentoo.org/proj/java/wiki/Eclipse_Plugin_Maintenance

I'm sure people are frothing at the mouth to maintain Eclipse at this
point. So, please drop an email to [EMAIL PROTECTED], and we can work out
how to hand things over.

-- 
Joshua Nichols
Gentoo/Java Developer
Gentoo/Ruby Developer
http://technicalpickles.com

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] merging man page documentation into eclasses

2007-06-11 Thread Joshua Nichols
Mike Frysinger wrote:
 keeping documentation of functions in a separate file (man pages in this 
 case) 
 has obvious bit rot problems written all over it, so i'd like to merge the 
 documentation into the respective eclasses so that the man pages can be 
 automatically generated
   

For the Java eclasses, we've been marking them up with something akin to
javadoc. We never did get around to writting something that actually
parses it though, but I wouldn't imagine it to be difficult.

 See java-utils-2.eclass for what it looks like.

-- 
Joshua Nichols
Gentoo/Java Secondary Project Lead
Gentoo/Xfce Project Lead
Gentoo/Ruby Developer

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Suggestion

2007-02-08 Thread Joshua Nichols

Christopher Covington wrote:

Apropos ebuild-aware text editor, has anyone written an eclipse plugin
yet? I find that setting up ebuild as an external tool is basically
all I need but syntax highlighting and eclass reference would make
things prettier.


I have no idea of the status, but I recently heard about:
http://sourceforge.net/projects/geclipse/

--
Joshua Nichols
Gentoo/Java Project Lead
Gentoo/Xfce Project Lead
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites: dev-java/bluej-bin

2006-10-27 Thread Joshua Nichols
Steve Dibb wrote:
 To quote jakub, It either doesn't emerge, or doesn't work, has no
 maintainer, this bug has been sitting here for ages,binary ebuilds are
 against Java policy, and nothing depends on it.
For the record, I checked, and it isn't actually open source, so you
can't really have a non-binary ebuild for it.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Is there a tool to manage USE flags? (use-config?)

2006-10-26 Thread Joshua Nichols
m h wrote:
 Other than a text editor?

 I'd like to have a tool that can add USE flags on a per package or
 global level.  (I'm doing this in some build scripts and would prefer
 just to have a tool, rather than sed or some other shell hackery).

 I couldn't find anything via a quick search on google.

 Here's my interface:

 use-config --add --component sys-devel/gcc --flag fortran

 (adds the fortran USE flag to package.use for gcc)

 A --remove would remove the fortran USE flag, and --unset would put
 -fortran instead.  A --global would update make.conf instead of
 package.use.

 Make sense?  Are there other features that people would want?

 Unless this already exists, I'll probably create a tool for this.

euse from app-portage/gentoolkit provides this functionality for global
use flags, ie

euse --enable java
euse --disable xmms

and so on.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-portage-dev] Re: [gentoo-dev] Is there a tool to manage USE flags? (use-config?)

2006-10-26 Thread Joshua Nichols
m h wrote:
 Other than a text editor?

 I'd like to have a tool that can add USE flags on a per package or
 global level.  (I'm doing this in some build scripts and would prefer
 just to have a tool, rather than sed or some other shell hackery).

 I couldn't find anything via a quick search on google.

 Here's my interface:

 use-config --add --component sys-devel/gcc --flag fortran

 (adds the fortran USE flag to package.use for gcc)

 A --remove would remove the fortran USE flag, and --unset would put
 -fortran instead.  A --global would update make.conf instead of
 package.use.

 Make sense?  Are there other features that people would want?

 Unless this already exists, I'll probably create a tool for this.

euse from app-portage/gentoolkit provides this functionality for global
use flags, ie

euse --enable java
euse --disable xmms

and so on.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

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



Re: [gentoo-dev] Troubleshooters for Gentoo

2006-10-13 Thread Joshua Nichols

Maurice van der Pot wrote:

Hi,

I've noticed in the past that a lot of people come to irc with problems
in some area (say networking) that are easy to solve just by first
asking a number of questions to identify the problem and then providing
the solution.

I've always liked the way Microsoft put these troubleshooters in their
help files. While the content of Microsoft's troubleshooters probably 
never really helped anyone, the format of a troubleshooter is in my 
opinion one of the best ways to help people solve their own problems.


Now I've hacked up a program that can create a troubleshooter from
specifications of questions and problems and their dependencies, but I'd
need to have some decent content to really make it useful for other
people.

I think having a couple of Gentoo-specific troubleshooters would be a
great resource for new users (not just new to Gentoo, but new to Linux).

I have a couple of questions:

1) Does this sound like a good idea?

2) Does anyone feel like pouring his/her troubleshooting skills into
   content for my program?

The program is still very immature (I skipped a lot of things that
weren't absolutely necessary for the program to show what it can do),
but that'll be fixed.

When given proper input, it generates HTML files that you can click 
through and that will hopefully lead you to (a solution to) your problem.

It has some sample content to show the format.

Maurice.


http://griffon26.kfk4ever.com/~griffon26/troubleshooter-0.0.2.tar.bz2
43f0042c802ad5ddcdf2a4db671c41c8 *troubleshooter-0.0.2.tar.bz2

  
If I'm not mistaken, the kbase project was established to help with this 
type of information:


http://www.gentoo.org/proj/en/kbase/

--
Joshua Nichols
Gentoo/Java Project Lead
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] new eclass: java-gnome.eclass

2006-10-03 Thread Joshua Nichols
To facilitate the maintenance of the java-gnome packages (ie 
libgtk-java, libgnome-java, and company), I've created a new eclass. 
There are currently seven packages which would be able to use this, and 
the number is expected to increase as the java-gnome project adds more 
bindings.


The initial motivation for this came when I was cleaning up and 
migrating these packages to the new Java eclasses. As I was going along, 
I kept changing my mind about how to best package them... and each time 
I did, I would have to update 7 ebuilds. It got silly after awhile, so I 
sat down to make an eclass in order to make it trivial to maintain the 
actual packages with all the heavy lifting in the eclass.


The eclass can be seen at:
https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/eclass/java-gnome.eclass

A package using it:
https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/libgtk-java/libgtk-java-2.8.7.ebuild

I would like to add this to the tree this weekend, and consequently bump 
java-gnome up to 2.14.3 which was released recently.


--
Joshua Nichols
Gentoo/Java Project Lead
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] client+server packages - build which one?

2006-08-08 Thread Joshua Nichols
Enrico Weigelt wrote:
 How can I get an patch downloaded from some location and then applied ?
 I've inspecting some ebuilds in the portage tree and learned how to 
 apply patches in the files/ subdir. Now I need to know, how to download
 the patches (simply add them to $SRC_URI ?) and then get them referenced
 for applying ?

   
You should be able to put it in SRC_URI, and it'll get downloaded. It
will then be available in ${DISTDIR} iirc... so you can just go:

epatch ${DISTDIR}/something.patch


-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Masking practics

2006-08-08 Thread Joshua Nichols
Patrick McLean wrote:
 Enrico Weigelt wrote:
 [ebuild   R   ] sys-fs/cryptsetup-luks-1.0.3-r2
 [ebuild U ] x11-terms/rxvt-unicode-7.9 [7.8-r1]
 [ebuild U ] sci-chemistry/gromacs-3.3.1 [3.3]
 [ebuild UD] app-foo/bar-1.0.2 [1.1.0]
 [ebuild U ] app-text/evince-0.5.5 [0.5.4]

 Why do you think emerge has columnar output like this, notice how the D
 is in a different column than anything else, it makes it pretty easy to
 spot, if you are too lazy to at least scan the output of emerge -p
 before actually running the emerge, don't complain when you break your
 system.
   
While it is columnar, the D is in a dark blue font. If you happen to be
using a dark background, there is extremely little contrast. Perhaps it
could be a different color that would stick out in both light and dark
backgrounds?

Also something that has always bugged me... isn't the U supposed to be
for upgrade and the D for downgrade? In this case, it would make sense
to only show the D when downgrades will occur, and not both, wouldn't it?

Not that I have ever had a problem with downgrades (that I remember),
but I think these two tidbits would probably be an overall improvement.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Masking practics

2006-08-07 Thread Joshua Nichols
Duncan wrote:
 That's precisely what emerge --pretend --verbose covers.  Or, if you want
 the display with a question to continue or not, use --ask instead of
 --verbose.
   
I'm pretty sure you mean to use --ask instead of --pretend, not --verbose.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Sowing the seeds of a warconfig tool

2006-08-05 Thread Joshua Nichols
m h wrote:
 Like I said, if you are interested in manipulating wars from ant or
 maven perhaps cargo is for you.  I'm assumming this is more of the
 programmer/qa type person who wants this sort of functionality.  My
 end user is a sys-admin.  They are usually more comfortable from the
 command line.

 I've updated my caveats section
 (http://developer.spikesource.com/wiki/index.php/Article:Warconfig )
 with Cargo information.

Disclaimer: I'm familar with cargo because we use it at work, but not
intimately so, because I haven't been involved with the implementation
and whatnot.

My impressions of cargo is that it is supposed to be pretty container
agnostic. You mostly point it at a host, with username, password, etc,
and it'll deploy the app for you. This would be pretty nice, since you
wouldn't have to worry about the implementation details of where webapps
should live. Additionally, you could use it to build wars on one
machine, and deploy them remotely without much trouble.

So if the issue that there isn't a command line interface, perhaps it is
worth writing? Also, we could probably write a generic ant script, and
provide a scripted frontend for it to make it dynamic.

-- 
Joshua Nichols
Gentoo/Java Project Lead
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] atom matching behavior

2006-08-03 Thread Joshua Nichols
Marius Mauch wrote:
 Repost from gentoo-portage-dev[1]:

 Was just brought to my attention that the =* operator doesn't work as I
 thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
 This wouldn't be a bug problem if it could be used as a general glob
 operator like with =foo-1.2.*, but it's use is strictly limited to the
 above version (can only be used when a version component separator may
 appear), so atm there is no facility to reliably lock an atom at a
 specific version component when you have to account for multi-digit
 components.
 Now the question is if we want this glob-style behavior or not. From
 the code comments it seems to be intentional, but I'd suspect that many
 people share my original assumption and expect it to only match full
 version components (as that is the much more common use case). Doesn't
 help that the atom description in ebuild(5) doesn't specify the
 behavior for this case either, 

 *  means  match  any version of the package so long as the specified
 base is matched

 can be read both ways.
   
Many Java packages use =foo-1.2*, expecting to get like foo-1.2.1,
foo-1.2.3, etc. In these cases, it is actually intending to depend on a
particular slot, ie 1.2, but without slot dependencies, this is the next
best thing that can be done

--
Joshua Nichols
Gentoo/Java Project Lead
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The gnome king is dead, long live the gnome king

2006-07-31 Thread Joshua Nichols
foser wrote:
 tonight after a some deliberation I have decided to step down as gnome
 lead in favor of AllanonJL. As far as I am concerned AllanonJL has been
 the acting lead for quite a while now, while I was too busy to devote
 much time to Gentoo and as such it was the only logical next step.
   

The Boston conspiracy continues to consolidate power... Congrats John :-D

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-30 Thread Joshua Nichols
Thierry Carrez wrote:
 Those were nominated but did not (yet) confirm their participation :

 agriffis
 AllanonJL
 azarah
 christel
 CHTEKK
 george
 jaervosz
 jakub
 johnm
 kito
 kosmikus
 `Kumba
 marienz
 Mr_Bones_
 nichoj
 plasmaroo
 pvdabeel
 Ramereth
 rl03
 seemant
 solar
 tsunam
 Uberlord
   
I'm going to decline for this year.

-- 
Joshua Nichols
Gentoo/Java - Project Lead
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo-java] Gentoo/Java staffing needs

2006-07-28 Thread Joshua Nichols
Miroslav Ć ulc wrote:
 I would also appreciate more information on Java ebuilds development. I
 don't remember I've seen somewhere slotting howto for Java ebuilds,
 but I may miss something.
   
For Java specific information, check out the developer guide:
http://www.gentoo.org/proj/en/java/java-devel.xml

For general ebuild information:
http://devmanual.gentoo.org/
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml

Hope that gives you somewhere to start.

-- 
Joshua Nichols
Gentoo/Java - Project Lead
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] architectures which support Java

2006-07-20 Thread Joshua Nichols
Attention arch team types:

Could I get notice of whether or not your architecture is supporting
Java? The question comes out occaisonally, and it's a little embarassing
for me when I don't the status for a particular arch and its Java
support. So please, help me get in the loop :) I'd like to post this
info somewhere on our project page [1]

These are the archs I specifically know about:

Supports:
amd64
ppc
x86

Doesn't support:
alpha
hppa
sparc

[1] http://www.gentoo.org/proj/en/java/

Thanks,

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



[gentoo-dev] migrating packages to the new Java system

2006-07-17 Thread Joshua Nichols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey folks,

Now that the new Java system is in the main portage tree, the Java team
has been working to port packages to use it. It is quite a daunting task
though, considering how many Java packages are in the tree.

I've written some notes about how to migrate packages on our trac:

http://overlays.gentoo.org/proj/java/wiki/Migrating_packages

nelchael has also been so kind as to write a python script which figures
out what packages remain unported. It lives in svn at:

http://overlays.gentoo.org/svn/proj/java/scripts/find-unported.py

It will be improved to give better output as we have time, so you may
want to just checkout the scripts directory, and svn up from time to time.

Note: it is kind of long running, since it goes over the whole tree.

The most recent results of the script can be found at:
http://dev.gentoo.org/~nelchael/java-generation-2/not-migrated-20060717

The progress is at:
http://dev.gentoo.org/~nelchael/java-generation-2/progress.txt

Right now, we have some 366 packages to migrate... So we are looking for
help, since there are only a few active Java members!

So, if you are a developer interested in helping with migration, stop by
#gentoo-java, and give a shout.

If you are not a developer, you can still help! My recommendation would
be to take a look at your favorite Java package, and try migrating it.
If you are able to successfully migrate them, file a bug with a patch to
the ebuild.

Regards,

- - Josh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEvBsI8ATTzZyw6sMRAlKDAJ0Ti2Xw0IGTZEL9ntWB5DlD38uGcwCfc42A
sRZnwLQGcsBBP57fuyFgV5A=
=DMjm
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

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

  - virtual/jdk
  - virtual/jre

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

   
Something worth mentioning... If you have problems where dependencies
fail to resolve, like dev-java/blackdown-1.5, or dev-java/kaffe-1.4, it
means you have some stale PROVIDE files kicking around. You will likely
want to run the following to find them:

find /var/db/pkg -name PROVIDE | xargs egrep -l 'virtual/jdk|virtual/jre'

This should give you a list of files to you'll want to delete.

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



[gentoo-dev] Updates to the way Java is handled

2006-06-25 Thread Joshua Nichols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Over this past weekend, I made the changes I proposed last week.

Everything related to it is currently sitting in package.mask:

# Joshua Nichols[EMAIL PROTECTED] (24 Jun 2006)
# Masked for testing changes to Java
=dev-java/java-config-1.3
dev-java/java-config-wrapper
dev-java/javatoolkit-0.1.0
=dev-java/ant-core-1.6.5-r13
=dev-java/ant-tasks-1.6.5-r2
=dev-java/jikes-1.22-r12
=dev-java/eclipse-ecj-3.1-r13
=dev-java/blackdown-jdk-1.3.1-r23
=dev-java/blackdown-jdk-1.4.1-r12
=dev-java/blackdown-jdk-1.4.2.03-r12
=dev-java/blackdown-jre-1.3.1-r20
=dev-java/blackdown-jre-1.4.1-r12
=dev-java/blackdown-jre-1.4.2.03-r11
=dev-java/ibm-jdk-bin-1.4.2.04-r10
=dev-java/ibm-jdk-bin-1.5.0-r11
=dev-java/ibm-jre-bin-1.4.2.05
=dev-java/jrockit-jdk-bin-1.4.2.10
=dev-java/jrockit-jdk-bin-1.5.0.06
=dev-java/kaffe-1.1.7
=dev-java/sun-jdk-1.4.2.12
=dev-java/sun-jdk-1.5.0.07
=dev-java/sun-jre-bin-1.4.2.12
=dev-java/sun-jre-bin-1.5.0.07

To try it out, add the above entry to /etc/portage/package.unmask, and
then follow the instructions at:

http://www.gentoo.org/proj/en/java/java-upgrade.xml

I would like to unmask these packages in the next few days. At that
point, I'd like to 'officially' announce it, as in put it on the front
page, send to -announce, etc.

- - Josh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnv1b8ATTzZyw6sMRAhtMAJ95IFFL2swPyP5YhkpWNTtuxg4B1wCfcz3e
4M9TcNmyPQEkdshbaU8wgN4=
=Q+1r
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]

2006-06-23 Thread Joshua Nichols
Jakub Moc wrote:
 Anders Hellgren wrote:
 On Fri, 23 Jun 2006, Stuart Herbert wrote:

 On 6/23/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
  I'm amazingly confused about why technical policy decisions (and even
  discussions about them) are being made by devrel in a devrel-specific
  channel. Could someone clear me up on this?

  Thanks,
  Donnie
 Sorry, but I must second this, especially as discussions have also
 been continuing that (unlike Mike's discussion) actually included
 council members.

 I'm all for folks trying to help resolve the Sunrise issues, but I
 feel that it's not devrel's place to be deciding this particular
 policy issue, especially when the issue has already been referred to
 the council.

 Best regards,
 Stu

 FWIW, there was almost an hour's worth of discussion before the start of
 the log KingTaco posted. As a bystander, my guess is that the discussion
 took place in the devrel channel because a complaint about the use of
 the bugzilla whiteboard by the sunrise folks was brought up in that
 channel. The compromise was made to defuse further escalation to a
 formal complaint to devrel.

 /Anders
 -- Anders Hellgren (kallamej)
 Gentoo Forums Administrator
 
 OK, so - java folks, please, take your java migration overlay bugs
 somewhere else from bugzilla. You know very well I had no problem w/
 assigning them, I just requested them to be clearly marked as such
 (which the users have been doing, thank you for that). Since some
 developers consider such use of bugzilla as misuse of Gentoo
 infrastructure and have gone so far that they involved devrel in this
 discussion, I'm not going to assign those bugs any more.
 
 Your 'thank you' goes especially to brix, your complaints go to devrel
 as a body that proclaimed themselves empowered to decide on acceptable
 bugzilla usage. There's no technical difference between using bugzilla
 for unofficial java migration overlay hosted on gentooexperimental.org
 and using it for unofficial overlay hosted on gentoo-sunrise.org (and
 even usage of keywords and status whiteboard for unofficial overlays
 counts as a misuse of bugzilla here). Devrel's current policy clearly is
 that bugzilla may only be used for official overlays hosted on
 overlays.gentoo.org,
 
 
 Sorry for the inconvenience, not my fault.
 

Umm maybe it's just to early in the morning, but I don't see
anything in the logs regarding using bugzilla for overlays not on
overlays.gentoo.org. I only see references to sunrise specifically, not
a blanket statement for all non-overlays.gentoo.org overlays

Or was this part of a discussion / decision that wasn't on this mailing
list...?

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



Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work

2006-06-23 Thread Joshua Nichols
Patrick Lauer wrote:
 No, it just shows that two different standards are applied and jakub (as
 well as some others) do not wish for any discrimination.
 If sunrise gets blocked with the argument it's an overlay then, by
 logic, the Java overlay should get the same treatment, even if this is
 stupid, unfair and stupid.

   
Unless there's more discussions going on than I'm privy too... what I
grokked out of the IRC log was that the argument was that it's an
'unofficial overlay'.

I take it that an official overlay would be one that's hosted on
overlays.g.o? If that's the case, our overlays have been around for at
least a year (that's when I started using it as a user), and probably
longer than that... which was before overlays.gentoo.org was even
around. Additionally, the overlays are managed by the our team, and have
been an integral part of our project, having been referenced for some
time from our 'official' IRC channel and our project page. In my mind,
this effectively make the overlays our 'official overlays'.
 I agree with you there. While I'd prefer to get rid of Java I don't let
 that influence my behaviour towards the project (or I'd have kicked them
 off my server a long time ago!)
   
I'm sure you'll be happy to know we'll be moving to overlays.gentoo.org
as soon as reasonably possible. Note: this was already planned, and it
isn't me trying to be grumpy about the direction this discussion seems
to be going. We would have moved sooner, but mostly we've been busy
working on the migration stuff, so likely won't happen until we've moved
that into the tree.

- Josh

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changes to the way Java packages are built

2006-06-19 Thread Joshua Nichols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joshua Nichols wrote:
 = Background =
 
 As some might have noticed, Java 1.5 has been package.masked for some
 time now. There are a number of issues introduced with 1.5 that have
 kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details.
 
 [1] http://www.gentoo.org/proj/en/java/tiger-faq.xml
 
 About a year ago, work was begun on improving our part of the build
 system (read: Java related eclasses and our java-config tool) in a way
 to make it much more flexible in general, but specifically improve it to
 get around the known issues. It took about six months to fully develop.
 Unfortunately, the new system was not quite a drop-in replacement. So,
 it took from then until now to determine how to migrate from the current
 system  to the new one in a sane way.
 
 
 = The Current System =
 
 To give some proper background, it is worth going over the current
 system briefly.
 
 == The Java Virtual Machine ==
 Each Java Virtual Machine (VM) installs an environment file into
 /etc/env.d/java. These files contain information about where JAVA_HOME
 is, the PATH to include, etc.
 
 VMs traditionally get installed at /opt/${P}
 
 We have the concept of a 'system' VM and a 'user' VM. The system VM is
 the default VM that will be used for root, and for users who haven't
 selected a user VM. The user VM is, as one might guess, selected on a
 per user basis. It is worth noting that root always uses the system VM,
 and as a result, packages use the system VM when being merged by emerge.
 
 java-config is used to set the system and user VM. When you do so, the
 appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for
 the system VM or to ~/.gentoo/java-env for the user VM.
 
 java-config's notion of the current VM is tied entirely to the
 environment, specifically to JAVA_HOME. Therefore, if you change the
 system VM, you'd need to run env-update and then resource /etc/profile.
 Likewise, changing the user VM involves sourcing ~/.gentoo/java-env.
 
 The fact that you're tied to the environment is annoying, because as
 mentioned, you need re-source the appropriate files. Now imagine you
 have a ton of terminals open... you'd have to source the environment
 files from each one.
 
 == Packages ==
 
 When a Java package is built, information about it is saved in
 /usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if
 SLOT == 0). In particular, the jars that are associated with the package
 are recorded, as well as which jars from other packages are used.
 java-config can later be used to query for this information.
 
 == Eclasses ==
 
 There are currently 3 eclasses: java, java-pkg, and java-utils.
 
 java.eclass is used for packages which provide a VM.
 java-pkg.eclass is used for most Java packages. It provides tools for
 querying installed jars, and for installing various Java related files.
 java-utils.eclass provides a few utility functions for dealing with Java
 stuff.
 
 = The New System =
 
 == The Java Virtual Machine ==
 In addition to the concept of a system and a user VM, the new system has
 a build VM. As the name implies, the build VM is used for building
 packages (instead of the system VM). Sane defaults are defined on a per
 platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3].
 The build VM can further be configured by
 /etc/java-config-2/build/jdk.conf [4] .
 
 [3]
 https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf
 [4]
 https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf
 
 For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which
 vendor and version to use at build time.
 
 In addition to being installed to /opt/${P}, VMs also now have a symlink
 in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is
 explained further down.
 
 The user and system VMs are now represented by symlinks pointing to VMs
 located in /usr/lib/jvm/. The system VM lives at
 /etc/java-config-2/current-system-vm, and the user VM at
 ~/.gentoo/java-config-2/current-user-vm . Additionally, an environment
 variable, GENTOO_VM, can be used to specify the VM used at a given
 instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm.
 So with regard to what VM is used, first GENTOO_VM is checked, then the
 user VM (for non-root users), and then lastly the system VM.
 
 
 All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get
 wrappers installed into /usr/bin. These are actually symlinks to
 /usr/bin/run-java-tool. This is a script which will figure out which
 tool was invoked, and then determine which VM to used using the method
 mentioned above.
 
 == Packages ==
 
 We now save more information about the build environment at build time
 for each package. This information is saved at
 /usr/share/${PN}-${SLOT}/package.env. This is facilitate troubleshooting
 bugs. Specially, we

[gentoo-dev] Changes to the way Java packages are built

2006-06-18 Thread Joshua Nichols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

= Background =

As some might have noticed, Java 1.5 has been package.masked for some
time now. There are a number of issues introduced with 1.5 that have
kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details.

[1] http://www.gentoo.org/proj/en/java/tiger-faq.xml

About a year ago, work was begun on improving our part of the build
system (read: Java related eclasses and our java-config tool) in a way
to make it much more flexible in general, but specifically improve it to
get around the known issues. It took about six months to fully develop.
Unfortunately, the new system was not quite a drop-in replacement. So,
it took from then until now to determine how to migrate from the current
system  to the new one in a sane way.


= The Current System =

To give some proper background, it is worth going over the current
system briefly.

== The Java Virtual Machine ==
Each Java Virtual Machine (VM) installs an environment file into
/etc/env.d/java. These files contain information about where JAVA_HOME
is, the PATH to include, etc.

VMs traditionally get installed at /opt/${P}

We have the concept of a 'system' VM and a 'user' VM. The system VM is
the default VM that will be used for root, and for users who haven't
selected a user VM. The user VM is, as one might guess, selected on a
per user basis. It is worth noting that root always uses the system VM,
and as a result, packages use the system VM when being merged by emerge.

java-config is used to set the system and user VM. When you do so, the
appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for
the system VM or to ~/.gentoo/java-env for the user VM.

java-config's notion of the current VM is tied entirely to the
environment, specifically to JAVA_HOME. Therefore, if you change the
system VM, you'd need to run env-update and then resource /etc/profile.
Likewise, changing the user VM involves sourcing ~/.gentoo/java-env.

The fact that you're tied to the environment is annoying, because as
mentioned, you need re-source the appropriate files. Now imagine you
have a ton of terminals open... you'd have to source the environment
files from each one.

== Packages ==

When a Java package is built, information about it is saved in
/usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if
SLOT == 0). In particular, the jars that are associated with the package
are recorded, as well as which jars from other packages are used.
java-config can later be used to query for this information.

== Eclasses ==

There are currently 3 eclasses: java, java-pkg, and java-utils.

java.eclass is used for packages which provide a VM.
java-pkg.eclass is used for most Java packages. It provides tools for
querying installed jars, and for installing various Java related files.
java-utils.eclass provides a few utility functions for dealing with Java
stuff.

= The New System =

== The Java Virtual Machine ==
In addition to the concept of a system and a user VM, the new system has
a build VM. As the name implies, the build VM is used for building
packages (instead of the system VM). Sane defaults are defined on a per
platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3].
The build VM can further be configured by
/etc/java-config-2/build/jdk.conf [4] .

[3]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf
[4]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf

For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which
vendor and version to use at build time.

In addition to being installed to /opt/${P}, VMs also now have a symlink
in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is
explained further down.

The user and system VMs are now represented by symlinks pointing to VMs
located in /usr/lib/jvm/. The system VM lives at
/etc/java-config-2/current-system-vm, and the user VM at
~/.gentoo/java-config-2/current-user-vm . Additionally, an environment
variable, GENTOO_VM, can be used to specify the VM used at a given
instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm.
So with regard to what VM is used, first GENTOO_VM is checked, then the
user VM (for non-root users), and then lastly the system VM.


All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get
wrappers installed into /usr/bin. These are actually symlinks to
/usr/bin/run-java-tool. This is a script which will figure out which
tool was invoked, and then determine which VM to used using the method
mentioned above.

== Packages ==

We now save more information about the build environment at build time
for each package. This information is saved at
/usr/share/${PN}-${SLOT}/package.env. This is facilitate troubleshooting
bugs. Specially, we collect the VM dependency is (ie =virtual/jdk-1.4),
what -source and -target were used , and which VM. We also keep track of
where javadocs 

Re: [gentoo-dev] automatically killing invalid CFLAGS/warning about bad CFLAGS

2006-04-14 Thread Joshua Nichols
Patrick McLean wrote:
 Harald van D?k wrote:
  The only flags that are actually removed are the flags that are invalid
  _by themselves_. There are cases where flags are valid because of other
  flags, such as anything following -X*.
 
  Two other problems I see with the code:
  CFLAGS=${CFLAGS//bad-flag} is in the ebuild quiz, if I recall
 correctly.
  It's broken because it also removes valid flags that happen to contain
  bad-flag as a substring.
  Locale isn't forced to C, which means gcc may not spit out
 'unrecognized
  option' at all even for invalid flags.

 There is a new version at
 http://dev.gentoo.org/~chutzpah/profile.bashrc that
 should fix all these possible problems. Thanks for pointing them out,
 let me
 know if you see anything else.
Around line 77, you have:
hasme ${flag} ${CFLAGS} ${CXXFLAGS}  trigger=1  \
ewarn Your C(XX)FLAGS contain(s) \${flag}\ which can break
packages.

Might I suggest you change it to something like:

if hasme ${flag} ${CFLAGS} ${CXXFLAGS}; then
   trigger=1
   ewarn Your C(XX)FLAGS contain(s) \${flag}\ which can break
packages.
fi

While there's nothing wrong with the original way, my suggestion would
make it a bit more obvious that you're setting the 'trigger' flag.

Regards,

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