Earlier today Calchan blogged about amending GLEP 39 here. During the council meeting I voted against council being able to change the document and on deciding a process for changing it. Why? First I think as the developer population voted the GLEP I think they should decide about the changes as well. Secondly I think we don't need to decide on a process because we already have one. Using the existing elections team and votify is enough when needed. If council members think we are wrongly skipping items in meetings, I challenge them to step up and take chair in the next meeting making sure items are properly handled.

As I am running again and finally had some free time and motivation to write some stuff up I wrote an initial manifesto for the on going council elections. It can be found here: http://dev.gentoo.org/~betelgeuse/manifesto-2009.html I will probably continue updating it during the election period if things come to mind.

I got this idea about writing a Portage metadata cache backend based on extended file attributes. We are talking about file metadata after all and the key=value format fits the cache quite fine. I have it working now. On the road I hit a couple of interesting issues. The cache can have arbitrary long lines but all file systems I tested have a limit on how long the values can be. I decided to just split the values into multiple attributes when they are too long. I also found out that ext4 and btrfs use the wrong errno to signal the value being too long. man xattr_set says it should be E2BIG but both of those file systems return ENOSPC. I opened an upstream kernel bug about this to see what they think:
http://bugzilla.kernel.org/show_bug.cgi?id=12793

This is what it looks like currently:

betelgeuse@pena /mnt/test/dev-java/java-config $ getfattr -d java-config-2.1.7.ebuild  | head
# file: java-config-2.1.7.ebuild
user.CDEPEND="1:"
user.DEFINED_PHASES="1:compile install postinst postrm unpack"
user.DEPEND="1:dev-lang/python >=sys-apps/sed-4 virtual/python"
user.DESCRIPTION="1:Java environment configuration tool"
user.EAPI="1:0"
user.HOMEPAGE="1:http://www.gentoo.org/proj/en/java/"
user.INHERITED="1:"
user.IUSE="1:"
user.KEYWORDS="1:~alpha ~amd64 ~arm ~ia64 ~ppc ~ppc64 ~x86 ~x86-fbsd"

As for performance the current implementation seems to perform about the same for emerge -uDpv world as the default cache.
These results are with a warm file system cache.

Results on btrfs/xattrs:
real 0m13.194s
user 0m10.906s
sys 0m1.811s
btrfs/default:
real 0m12.101s
user 0m10.847s
sys 0m0.980s

xfs does a little better because it has a longer limit for attribute values. I guess that most of the time is spend in doing something else than cache lookups but will try to profile later. The code isn't committed anywhere outside my portage trunk git svn checkout yet but will try to see if this is something zmedico accepts to Portage trunk. Probably not going to be a documented option any time soon though.

This year will be my third year at FOSDEM. I will be giving a short talk on recruiting in the Free Java developer room on Sunday between 15:45 and 16:10 so if you want find out what we have been doing during the last year do come and listen.

http://fosdem.org/2009/schedule/events/java_recruiting_foss
http://www.klomp.org/mark/classpath/fosdem09/poster_09.pdf

I will be around tomorrow so, if our new developers want to meet the guy who caused them grief during the long quiz reviews, try to find me. I will be posting my phone number to -core if you need help navigating in Brussels or just want to know my whereabouts.

Quite a few people have reported problems building icedtea6 or needed dependencies on our IRC channel and as the build is quite resource intensive, Caster has now made binary builds for icedtea6. The package is available via layman using:

layman -a java-overlay
emerge icedtea6-bin

The binary package should also make it easier to bootstrap the from source build. The binaries are built in stable chroots so they should run for our stable users too. Please report any problems to https://bugs.gentoo.org with [java-overlay] in the subject. For amd64 users this should be the easiest way to get a 64 bit browser plugin.

http://gentoo.petteriraty.eu/stable.rss

I updated the Stable Candidates bug feed to have open bug numbers for ${CATEGORY}/${PN} and ${PN}. It will of course be a little behind actual bugzilla data as the feed is updated daily but that's good enough in my opinion. I think the next item for the feed is to add a link you can use to file the actual bug. That should make it dead simple for you to file stable bugs on stuff you use.

In the comments of my last blog post someone asked for an automatically generated list of stable candidates. I have now created a RSS2 feed that shows ebuilds that have only ~arch keywords and have been in the tree for a month. The feed is updated daily and it keep entries for 7 days. It does not currently work in Thunderbird because Thunderbird seems to be buggy with feed items that don't link to anything. Improvement suggestions are welcome. I should at least parse the bugzilla open bugs page to show how many bugs match category/pn.

You can find the feed here:
http://gentoo.petteriraty.eu/stable.rss

Have you ever been thinking about how you could contribute to Gentoo? Here's a quick and easy way. If you are using stable, take a look at your package.keywords file and file stable request bugs for all the entries there that satisfy the requirements for being marked stable. Meaning there are no open regressions in http://bugs.gentoo.org and the ebuild has been in the tree for at least a month. Even better is if you make filing these bugs a regular habit. I would imagine that most developers are running ~arch so packages that are not that actively maintained might start to fall behind in stable.

If you see something like:

 * ebuild.sh, line 1239:  Called qa_source '/usr/portage/eclass/java-pkg-2.eclass'                    
 * ebuild.sh, line   37:  Called source '/usr/portage/eclass/java-pkg-2.eclass'                       
 * java-pkg-2.eclass, line   10:  Called inherit 'java-utils-2'                                       
 * ebuild.sh, line 1239:  Called die                                                                  
 * The specific snippet of code:                                                                      
 * qa_source "$location" || die "died sourcing $location in inherit()"                                
 * The die message:                                                                                   
 * died sourcing /usr/portage/eclass/java-utils-2.eclass in inherit() 

Then it was me. It seems emerge doesn't like if $? is set to something else than 0 after an eclass has been sourced. If you use /usr/bin/ebuild then Portage doesn't die. I filed https://bugs.gentoo.org/show_bug.cgi?id=239253 for this inconsistency. So because of this an eclass can't end with some conditional like

[[ ${FOO} ]] && FOO=laa

Just a reminder to everyone that when you migrate to EAPI 2 in order to use use dependencies remember to migrate your src_compile function too or you will be running econf twice if you have a custom src_compile function. econf will first be run by the default src_configure function and then by your custom src_compile function. Hopefully we will get a QA check for this in the near future.

Currently we have packages like sun-jaf that are reference implementations for a JSR and have since been incorporated into the JRE (>=1.6). So before introducing Java virtuals ebuild developers had to either depend on sun-jaf or a new enough JDK version. Tomcat used the java5 use flag to select between the two options. This of course is not ideal for users and as such we added support for virtuals into java-config. We are still in the early stages of converting stuff to virtuals and let's see how it takes as the work is quite boring. Any way here is a demonstration of the jaf virtual in use:

betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.5" java-config -p jaf
/usr/share/sun-jaf/lib/activation.jar
betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.6" java-config -p jaf

betelgeuse@pena ~ $

jaf was introduced in 1.6 so in the first case you need the separate package and in the second case there is no point in polluting the classpath with extra stuff as we already have it in the JDK. On the ebuild side you use the same functions as with normal packages but you have to add the --virtual parameter to java-pkg_jar-from and java-pkg_getjar calls so that they don't record individual jars.

As the Gentoo Java lead I should probably comment on a couple of recent blog entries by Andrew John Hughes.

http://blog.fuseyism.com/index.php/2008/04/18/gentoo-and-free-java/

I have been trying to recruit a maintainer for FOSS Java stack for ages but no-one has stepped up. Unfortunate state of affairs but such is life with volunteer based distributions. I guess the fact that no-one has stepped up somewhat reflects on the needs of our users too. But any way gnu-classpath-0.97 has been stable for a while for x86 and amd64 in contrast to the 0.90 version stated in his blog.

http://blog.fuseyism.com/index.php/2008/04/27/releases-releases/

"The Java Gentoo developers seem to be on a strange mission to support only the proprietary Java solutions"

Well geki ( https://overlays.gentoo.org/proj/java/log/java-overlay/dev-java/icedtea ) is not a Gentoo developer so I don't know who you are referring to and him being the maintainer of the GCJ overlay I don't think he fits the bill either. If someone provided an ebuild for IcedTea that passed our QA standards, it could go in today. Otherwise it will get done after I have finished other stuff on my Gentoo work queue. I just finished adding a couple new virtuals for jaf and jmx. When packages are switched to use the virtuals it will remove the need to have sun-* or gnu-* packages installed for stuff that the JRE provides when using the latest JDKs.

I will be at FOSDEM again this year. If you want to meet me in person your best bet is the Free Java devroom http://www.fosdem.org/2008/schedule/devroom/freejava. I will also give a short talk Sunday morning about Java packaging on Gentoo so if you are interested in that, come listen. I will be arriving Saturday morning so you won't find me at the beer event tomorrow.

Just a reminder to all the Gentoo users out there that you don't have to know anything about ebuild writing to become a Gentoo developer. To become Gentoo staff for things like GMN, PR and Devrel you only need to take the staff quiz and of course in general you don't even need to be developer to help out. If you feel like helping out just contact the projects/developers in question by mail for example. If you don't get any response or don't find out who to contact from our project pages, just mail recruiters (at) gentoo (dot) org and we will get you in touch with the right people.

I now have my A2DP headset working on Gentoo. You just need to emerge the latest version of bluez-utils (3.15) and follow the instructions in http://wiki.bluez.org/wiki/HOWTO/AudioDevices I put device in pairing mode for the Connect call and kbluetooth asked me the pin and then it was ready to work. Now I am using amarok to stream music to my headset. It's probably to start thinking about getting the 3.X series stable.

Now that the Javadoc bug that has been holding 1.6 up has been fixed and the ebuild has been out for a month I filed http://bugs.gentoo.org/show_bug.cgi?id=189277 At least after it's fixed I/we don't have to answer any more questions on how to unmask sun-jdk-1.6.

http://bugs.gentoo.org/show_bug.cgi?id=187681

It's already done on x86. There are still a couple of fetch restricted packages in the dependency graph but I think that will be fixed when 6.0 get released and makes it's way from the overlays to the main tree.

Here is a mail I just sent to gentoo-dev-announce and gentoo-dev

http://bugs.gentoo.org/show_bug.cgi?id=163262

Posting to announce because people might not have been able to use the
hooks in their bashrc files because of us using them in our eclasses.
Also if you see some weirdness with Java packages this might be the
cause although the patch was extensively tested.

Regards,
Petteri

For quite a while now the bluez packages on Gentoo haven't been maintained so we have been stuck in 2.25. I decided to fix this so I bumped bluez-libs and bluez-utils to 3.10. You need to run revdep-rebuild --library libbluetooth.so.1 as upstream decided to increase the .so number to 2. Also worth nothing is that they have changed the way pins are asked from the user to a DBUS based API. If you have security set to user in hcid.conf you most likely want to install an applet that asks the PIN from you. There is now net-wireless/bluez-gnome for GNOME users and >=net-wireless/kdebluetooth-1.0_beta2 for KDE users.
The bug reports this fixed are
bluez-libs and bluez-utils:
https://bugs.gentoo.org/show_bug.cgi?id=143154
bluez-gnome:
https://bugs.gentoo.org/show_bug.cgi?id=173013
A couple of new ones were opened against the new version too so there is still some work before it is ready for stable. Hopefully I just need to proxy maintain the packages for a user.

betelgeuse@pena ~ $ eselect java-vm list
Available Java Virtual Machines:
  [1]   blackdown-jdk-1.4.2
  [2]   ibm-jdk-bin-1.5
  [3]   kaffe
  [4]   openjdk-1.7  user-vm
  [5]   sun-jdk-1.4
  [6]   sun-jdk-1.5
  [7]   sun-jdk-1.6  system-vm
  [8]   sun-jdk-1.6.0.02
  [9]   sun-jdk-1.7

http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/openjdk/openjdk-1.7.0.0_alpha12.ebuild

Takes me about 45 minutes to build on:

betelgeuse@pena ~ $ uname -p
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz

Please note the word experimental in the url. Now I am off to bed for today. Have an exam in C programming coming up tomorrow.