I just upgraded to gentoo-sources-3.2.9 from 3.1.1 only to find out that my logitech wireless mouse stopped working. It was correctly detected as a usb device but no input device was created for it:
Bus 005 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
After some Googling and looking around kernel settings I found out that I had to enable Device Drivers -> HID Devices -> Special HID drivers -> Logitech devices -> Logitech Unifying receivers full support. Hopefully this information helps other Gentoo users who run with most things disabled. Updating the kernel with make oldconfig I did not notice this option because I have had CONFIG_HID_LOGITECH disabled and it hasn’t caused any problems.
It’s time for this blog to come out of hibernation. I will hopefully be mentoring some people this summer so I will write down here questions/things that I would like people applying to my ideas to answer in their applications. Probably doesn’t hurt people applying for other ideas either. This is in addition to the general stuff in:
Projects that I will mentor or at least be strongly involved with if they make it to our slots:
* Gentoo Council web application
* Gentoo/Java IDE integration
* java-config cleanup and redesign
Questions and commentary:
* What is your opinion/experience on TDD?
* What is your opinion/experience with agile development methods?
Basically don’t only tell us what you will deliver but also how you will do it. You don’t need to write on essay on software processes. I will work with my students during the Community Bonding to come up with something that works best for both parties.
* What tools/libraries will you use?
It’s important that you justify your choices. This shows that you are familiar with the tools related to the subject and have done some research. For example in the council web application will you use rails/django, will you use rails 2.3 / 3beta etc.
* How will you take long term maintenance into consideration?
Our hope of course is that you will stay with Gentoo for the long term and continue to improve your code after GSoC but the reality is that even then you will eventually want to find new challenges. Because of this in order for your project to be truly a success it needs to be something else than spaghetti code that only you can read.
* Your time zone?
My time zone is EEST (UTC+3) in the summer. If your time zone is wildly different from mine then please say how you will take this into consideration. This might for example mean committing having meetings very early or very late during the day. I am not going to adjust my daily rhythm to match yours but will can make time during reasonable hours in my time zone.
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.
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.
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:
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.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.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:
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.
I have been working on a ldd like program for Java. I put this program together using bcel for class file parsing, java-config to provide a list of installed packages and jars and a SQL db abstracted by sqlalchemy.
betelgeuse@pena ~/jarindex $ java -jar "/home/betelgeuse/java/JavaLDD/dist/JavaLDD.jar" -q /usr/share/ant-junit/lib/ant-junit.jar
Obviously this doesn’t catch everything as you can load classes that provide an API dynamically but neither does ldd show dlopened shared libraries.
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.
Oh goodie. I decided to try the new xcb stuff so I turned on the xcb use flag in libX11 and mesa just to find out that java from sun does not work with it. Proprietary software is so much fun. Luckily a change is happening for the better as all of Sun’s java implementation will be released under the GPL in the future.
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
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.
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
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.