[gentoo-dev] seeking maintainer(s) for dev-util/eclipse-sdk
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
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
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
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?)
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
Re: [gentoo-dev] Troubleshooters for Gentoo
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
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] Re: Re: Re: Masking practics
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] client+server packages - build which one?
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
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
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
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
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
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
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] Gentoo/Java staffing needs
Hey folks, As has been the case for some time, the Java team is still atrociously understaffed. Below, I'll outline a few 'positions' I'd like see filled. I'm using the term really loosely, and mean it more as in the sense of 'these are things I'd like people to be working on'. If current devs are interested, that'd be great, but we're also willing to mentor some fresh blood. * Java generalists We have tons of Java packages. It was around 400 or so last time I checked. As one can imagine, this kind of number generates a pretty constant stream of bugs and version bump requests. So, basically I'm looking for some people to help out with general maintence of our packages. I'd expect them to be familiar with Gentoo and Java (surprise!). If they are not already, they will need to become familiar with the ins and outs of how Java is handled on Gentoo. Familiarity with ant, which is used for a large majority of our packages, would be very useful. * JBoss maintainer JBoss is a pretty important app in the enterprise world of Java. It has been pretty unmaintained for some time now, and could use some love. Because of the nature of this beast, I would want someone that uses JBoss on a daily basis, preferably in an enterprise setting, to be the type of person to maintain this. * Jetty maintainer Jetty is a web container, like tomcat and resin. It also has been pretty unmaintained in recent times. Preferably, the person who picks this fella up uses jetty on a daily basis in an enterprise type setting. * Maven maintainer Currently, our package for maven is a binary package, and we don't support using maven from an ebuild. Ideally, we would be able to package it from source, and would support building packages with it. There however, are quite a few barriers to this. I outline them in detail in one of my blog posts, under 2a and 2b: http://planet.gentoo.org/developers/nichoj/2006/05/04/java_ideas_for_summer_of_code * Free Java Hackers One of illustrious users has been working on working away at getting GCJ usable as a JDK, in the sense that it can be to build our packages. We do have a handful of other free Java VMs in portage, like kaffe, sablevm, jamvm, etc. If people were interested, I think it'd be great if we could get our packages building using these other VMs. * Eclipse / Netbeans maintainers Eclipse and Netbeans are the primary IDEs for Java. Eclipse is well kept for the moment, but the plugins haven't been. Netbeans needs a bit of love though, as it hasn't been updated in awhile. So, if one or more of these sounds intersting and like something you'd want to do? For starters, you should take a gander over at our project page, and checkout various documentation we have: http://www.gentoo.org/proj/en/java/ Other things you can do: * Join our mailing list, gentoo-java. It is pretty low-traffic. Information about joining lists is at: http://www.gentoo.org/main/en/lists.xml * Lurk in our IRC channel, #gentoo-java on irc.freenode.net. It's also fairly low-traffic, so don't expect immediate responses. Hope to hear from some peeps :-D -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] architectures which support Java
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
-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
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
-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 by gentoo-java's doing migration work
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] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
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] Changes to the way Java packages are built
-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 instal
Re: [gentoo-dev] Changes to the way Java packages are built
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: > First off - good work Java Team :) > > On Sun, 18 Jun 2006 10:39:06 -0500 > Joshua Nichols <[EMAIL PROTECTED]> wrote: > >> [...] 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. > > A better name for this would be GENTOO_JVM, as the Java VM isn't the > only type of virtual machine out there. Good point. I actually had thoughts of changing it to JAVA_VM, so it'd be distro-neutral. Changing this should be pretty painless, and mostly involve doing a few in-place seds. > Any chance java-config* could be reworked as one or more eselect > modules? I forgot to mention, but there is an eseelct module, for selecting / displaying the user and system VM. Josh. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElosr8ATTzZyw6sMRAi1GAJ0YW0tH2jqpm0lqayXjUOSOcgp0sQCfe1vq VI1vPfTqQFmVNvuHfQAtqWE= =Ym0O -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changes to the way Java packages are built
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > Joshua Nichols <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Sun, 18 Jun 2006 10:39:06 -0500: > >> I have written documentation on switching to the new system, from the >> user's perspective, over at our wiki [6] >> >> [6] >> https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay > > Are there instructions somewhere for keeping to a 100% freedomware > solution? I've been wondering about installing Java, but don't consider > slaveryware a viable local option, thus the question. (FWIW, in the general > case I couldn't install whatever binary legally if I wanted to, since I > couldn't agree to the EULA, tho I've not examined the Sun/Blackdown EULAs > recently to see if this would apply there, as they still aren't > freedomware and are thus still not an option.) > > If it's not yet possible (or no documentation that will work for a non-Java > guy), is there a timetable? No rush or even pressure to do it if you > aren't, but thought I'd ask while the topic is hot. I did try the given > URL as well as the Gentoo Java Guide, but the former seemed to presuppose > someone already involved in testing (understandable at this stage), and > the latter didn't seem to mention any of the newer 100% freedomware > alternatives I keep reading about. Thus, there was no answer I could grok. This is a bit off topic for the subject at hand... That being said... one of our users has been working on using GCJ to this end: https://projects.gentooexperimental.org/expj/wiki/GCJ_as_a_JDK As for why this hasn't been done already or more work isn't being done, I believe there are two reasons: 1) We don't have the same restriction as Fedora and Debian do with regard to licensing. If we did, then we'd have a more pressing need to use 'free' Java implementations to even distribute Java stuff. 2) No one has stepped up with the desire / motivation / skills to make it happen. Not only that, but the Java team in generally has been understaffed for some time now. Josh -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElZF98ATTzZyw6sMRAmPRAJ9h/dcuRWayki0wmICgsataMdibOQCeKXMU PyYu7srJmtjejwJZxQVtFUU= =ZQQc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Changes to the way Java packages are built
-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
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
