My GSOC Mentorship

I applied as a GSOC mentor for the first time. I’ll be mentoring Gentoo/Java IDE integration project. I’m personally interested in this project since I use Eclipse for Java development on my Gentoo box and I think many people like me can benefit from the outcome. Although I’m not a Netbeans user, the same applies for it as well. Yes I’m tired of defining user libraries (additionally pointing to their sources, jni libs, javadocs)

So let’s see if anyone applies for this project (A few already contacted by mail)

Intltool: A story on how a bug in one piece of software can kill all the others

0.40.6 version of intltool has a nasty bug in handling of LINGUAS variable. It causes localization (i.e .mo files) not to be built if your LINGUAS environment variable is set (I have it set to “tr”). At first, the issue popped up in GNOME packages (nautilus, seahorse and probably quite more that was fixed before I noticed) And now it started hitting other applications with tarballs generated using broken intltool. I first noticed it in Liferea, and then came Geany.

So users, upstream developers and downstream maintainers; if you notice or you’re reported of a package that appears untranslated even though the package has translations (langcode.po) please report it (for users), fix your tarball for the next release (upstream), fix your package (downstream)

StatCVS and StatSVN

Here are 2 tools for generating repository statistics for source trees controlled with CVS and SVN. Both tools can generate stats for subtrees. Here’s how to generate stats for a CVS checkout:

  • cd to module root or a subdirectory which the stats will be generated for.
  • Create the cvs log by executing
    cvs log > logfile.log
  • Execute
    statcvs logfile.log . -o -output-dir /path/to/stats

    to generate stats.

and for SVN:

  • cd to module root or a subdirectory which the stats will be generated for.
  • Create the svn log by executing
    svn log -v --xml > logfile.log
    
  • Execute
    statsvn logfile.log . -output-dir /path/to/stats

    to generate stats.

Now you can browse, upload, do whatever you want with generated stats. I generated stats for our java-config-2 project. The sample StatSVN output can be viewed at http://dev.gentoo.org/~serkan/statsvn-java-config-2/. Also Jeremy generated CVS stats for gentoo-x86/sys-apps which can be viewed at http://dev.gentoo.org/~darkside/stats/statcvs-sys-apps/.

Further Reading: You can read the following manuals for detailed information.

WARNING: Please do not run cvs log on cvs.gentoo.org. Use rsync to mirror the portage tree from AnonCVS provided by infra and run cvs log on the local mirror.

Sandbox violations due to regeneration of Python bytecode

Due to a bug in compileall.py script distributed with Python pyc/pyo files’ modification times are earlier than tat of py files. If any Python packages (such as java-config which is used for all Java packages) are used during compile phase the bytecode is regeneretad and sandbox-1.3.3 started catching that as a violation. Sandbx version 1.3.4 and above ignores this problem as a workaround. So if you hit any issues similar to bug 256953 or its duplicates, please update your sanbox. I thank Martin von Gagern for working on fixing the issue and taking it to upstream.

java-dep-check-0.3 and weird bugs it discovered

The tool Betelgeuse wrote was scanning Java packages for unneeded dependencies. It was scanning the registered jar’s for any referenced classes and generated a list of classes in dependent packages/jars to see if any of them are redundant. Back on December I came up with an idea to use that information to dig out for an opposite fact. Packages that reference classes which are not provided by it’s dependencies not itself. It was bug #252249 which inspired me. The initial ebuild was definitely missing a dev-java/sun-jai-bin .dependency which I wanted to verify. The intention was to discover missing dependencies. of binary Java packages.

After I got it working without (hopefully) false positives it was then time to see the results. I first ran it in over the packages installed on my system. Thanks to Diego who kindly ran it in his tinderbox which had most of the Java packages in portage installed and posted the output. I was surprised about the outcome. There were many source based packages that it reported to depend on missing classes. Roughly examining the list I saw that some packages installing ant tasks were missing an ant core dependency and fixed a few. Another set of packages seem to package its unit tests (see java-wakeonlan for example) Digging out others I figured out a third kind of problem. Packages missing already generated jars or classes in the final package.env entry. Those (openoffice,xulrunner,java-access-bridge) reported missing classes that was already provided by themselves. They either didn’t install the jar at all or installed but not registered them (we have java-pkg_regjar provided by java-utils-2 eclass which registers an already installed jar). But java-access-bridge had an interesting bug which was there for ages. The generated jar misses already compiled classes due to wildcards not being expanded recursively during make and reported the bug to upstream. Mindterm exibits a similar bug. Classes were missed out in jars because they weren’t in the hardcoded list of classes to package.

As a final word, I’ll be taking next days investigating output generated in Diego’s tinderbox, and fixing the packages.

Addition: Add note about net-misc/mindterm bug.

Java Plugin and Java Web Start for x86_64 users

Following up Petteri’s post about icedtea6-bin package we now have 1.6.0.12 versions of sun-jdk and sun-jre-bin in tree. This version finally adds long awaited (6 year old bug in sun bug database) 64-bit browser plugin along with 64-bit Javaws. Simply install any of the two with nsplugin USE flag and start running Java applets. Note that it only works with Firefox 3.

Applications failing with Turkish locale

Generally default uppercase/lowercase implementation in class libraries/frameworks respect active locale’s behavior. Due to difference in handling of letter I & i [1] applications may fail when locale-aware case conversion is not desired such as parsers, generators etc. The general fix for this issue is to use an English locale in case conversion. I’ll give a few example bug reports.

  • A bug in java-gnome bindings generator I reported and its fix.
  • A Turkish locale specific bug in JAXB .
  • A bug I hit in Bazaar that hinders my bundle generation, merge process which only happens in branches with signed commits.
  • A bug in Exaile media player

I guess, I can give more if I google, but I think the above examples are enough to show why applications fail with Turkish locale.

1: http://www.i18nguy.com/unicode/turkish-i18n.html

Addition: I traced Bazaar bug to be really a bug in Python itself, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489740 for how Pardus and Debian fixed Turkish locale issues. Thanks to Jesus Rivero for quick follow up after my request of applying these patches in Gentoo. Hopefully they’ll soon be incorporated in portage.
Further Addition: Fixes are committed to portage by Ali Polatel. See bug #250075.

Fixing automagic dependencies with cmake

file-browser-applet in tree introduced support for Super-H hotkey for menu activation via gtkhotkey library in 0.5.8. The dependency was optional:crazy: but automagic and the build system of the package is cmake. After examining Diego’s documentation for general information and personally getting help from him, I researched for how to fix the issue for cmake. You can see the bug report and my initial patch for the package. After releasing 2 more versions following 0.5.8 a modified version of my patch is committed. The upstream patch still prints out an ugly not found error even if file-browser-applet is compiled with -gtkhotkey. But I bumped and added the upstream patch to portage.

What I learned from this is cmake has an interesting if-then-else syntax that you need to include the control variable near each keyword. What I need to do afterwards is to extend Diego’s documentation with a paragraph about cmake.

Edit: I added prelimenary CMake section to Diego’s documentation. Please extend it with different possibilities which CMake may cause automagic dependencies.