» Packman: gamin: fix ABI compatibility with fam

There seems to be a very annoying ABI incompatibility between gamin and fam, which are packages that both implement the same API (gamin uses inotify and has per-user daemons, while fam has better NFS support). That incompatibility is in the externalized FamErrlist char* array, where fam exports an useless char*[1] and gamin has more than one array element in it, as well as having typed as const char*[]. While the latter isn't causing any problems, the former does, which manifests itself through the following warning message at runtime:

Symbol `FamErrlist' has different size in shared object, consider re-linking

Apparently, it's not just a warning, but it also causes failures and crashes. In the Packman repository, we ship the gamin package, while the openSUSE distribution only includes (and prefers) fam, precisely because of its better NFS support. All openSUSE packages and all packages that are built in the openSUSE Build Service are compiled and linked against fam. But if you have the Packman repository in your preferred package manager (e.g. zypper, smart or yum), you might end up with installing gamin and removing fam (because the gamin package in the Packman repository obsoletes and provides fam). I have just committed a patch against the Packman gamin packages that changes the size of that FamErrlist array to have the same size as in fam, which effectively solves the warning messages, and should also fix the crashes. The fix is included in gamin-0.1.10-0.pm.3 and above. As an alternative, if you can't or don't want to upgrade the gamin package, do as follows to remove gamin and re-install fam instead:

rpm -e --nodeps gamin rpm -q gamin-devel && rpm -e --nodeps gamin-devel zypper install fam zypper addlock gamin zypper addlock gamin-devel

Note that all of those commands must be executed as root, and the last two commands prevent from ever installing the packages gamin and gamin-devel again (at least with zypper). UPDATE: removed the Obsoletes:fam directive in gamin-0.1.10-0.pm.4

» Find python dependencies

When building Python packages, one recurrent and very tedious task is to analyze what dependencies each upstream project has. As we can't apply ldd as with C/C++, nor something like jdepend as with Java, and because I'm lazy and don't like doing repetitive stuff, I've hacked a little script that uses some heuristics to try to find out by itself what a bunch of python sources require. It does so by grepping the import statements (in various forms) in all .py files under the current directory, and then tries to resolve them to .py files under the Python lib directory (e.g. /usr/lib64/python2.6, although it finds out what that directory is by poking Python itself, no assumptions made there) and map those files onto RPM packages (by simply using rpm -qf). Again, simple and stupid, and the ANSI colouring assumes a dark terminal background ;), but you might want to give it a try and you even might find it useful. The (Perl) script is here: fpydep Sample output (make sure to have your browser on UTF-8 encoding):

 WARN  failed to resolve json
 WARN  failed to resolve simplejson
Resolved:
Requires: python-xml

Locals:
services
surl
surl.services
surl.surl
surl.version
version

Failed to resolve python files for the following imports:
json
simplejson

If anyone is aware of a more thorough approach to doing that, please let me know :)

» osc faillog, for the lazy

As blogged about a while ago, I also wrote a very crude and simple osc plugin for the lazy people (like me!) that applies some simple heuristics to pick the most informative build failure log, to avoid having to type the target distribution and architecture as parameters to osc bl Well, it's now available as a package, namely osc-plugin-faillog To install, add the home:pbleser:osc repository (pick a subdirectory that suits your distribution), and install the package osc-plugin-faillog To use it, just type osc f while being in a package sandbox directory, exactly as with osc bl (but without having to type e.g. osc bl openSUSE_11.1 x86_64 :)). The "algorithm" is quite simple:

• if factory (SUSE_Factory or openSUSE_Factory, or anything else that has factory in its distribution name) failed, it will display the log for that
• if not, then it will pick the most recent openSUSE distribution target that failed (i.e. openSUSE_11.1 > openSUSE_11.0, etc...)

From my experience, that (almost?) always makes sense, as the more recent the build target is, the tougher GCC is, and the pickier the rpmlint rules. Yes, it's simple and stupid, but it works -- at least for me. And indeed, it doesn't work for non-openSUSE distribution targets as of now.

» osc niceresults, now with icons

I've already written about my osc-plugin-niceresults package, and now I added some nifty UTF-8 "icons" that help quickly understanding the clutter that the output of osc r can be at times, especially when you have a lot of build targets. So, what does it look like ? (make sure to have your browser on UTF-8 ;))

  Repository    │ Arch   │ Status
────────────────┼────────┼────────────────
✔ openSUSE_10.3 │ i586   │ succeeded      
✔ openSUSE_10.3 │ x86_64 │ succeeded      
✔ openSUSE_11.0 │ i586   │ succeeded      
✔ openSUSE_11.0 │ x86_64 │ succeeded      
✔ openSUSE_11.1 │ x86_64 │ succeeded      
✔ openSUSE_11.1 │ i586   │ succeeded      
⬕ SLE_10        │ i586   │ disabled       
⬕ SLE_10        │ x86_64 │ disabled       
  SUSE_Factory  │ i586   │ expansion error
  └─▶ nothing provides autoconf >= 2.62 needed by automake
  SUSE_Factory  │ x86_64 │ expansion error
  └─▶ nothing provides autoconf >= 2.62 needed by automake

In order to install that osc plugin, add the home:pbleser:osc repository (pick a subdirectory that suits your distribution), and install the package osc-plugin-niceresults To use the plugin, do as with osc results (or osc r), but instead, invoke osc niceresults (or the shorthand form osc nr).

» I'm going to the openSUSE Conference 2009

» Educating upstream: C pointers are not int

Once and for all, a pointer (in C) is NOT an int It just happens to be one on 32bit systems, but the only proper type for casting a pointer into a number (for whatever reason, such as pointer arithmetics) is

intptr_t

To have that type, also add an #include on stdint.h where appropriate. It is really annoying when, as a packager, you keep running into C sources that have only been compiled and tested on 32bit systems and where the authors have assumed that they can cast their pointers to int. On x86_64, that generates quite a lot of warnings, on purpose: on 64bit systems, a pointer is an unsigned long. But don't rely on that either, just use intptr_t Arguably, it has been added in C99, and only as optional but hey, if you're in for a big heap of assumptions by doing pointer arithmetics, you could as well assume it's a modern C compiler and libc.

» TULH: latest openJDK 6 on openSUSE

(TULH = Trivial (or pointless ?) Ubuntu-Like Howto)

Purpose

Here is how to install the latest openJDK (the GPL'd branch of Sun's Java Virtual Machine) version 6 (the currently stable branch) on openSUSE 11.0-11.1

As root

You can simply copy/paste those blocks of commands into a shell. But note that they must be executed as the root user and, hence, first open a terminal (e.g. konsole on KDE, gnome-terminal on GNOME, xterm, urxvt, putty, whatever does the job), switch to the root user using the following command:

su -

Then enter the password of the root user when prompted to do so.

Install the JRE

VERSION=$(grep ^VERSION /etc/SuSE-release|cut -f3 -d" ") zypper addrepo -r \ http://download.opensuse.org/repositories/Java:/openjdk6:/Factory/\ openSUSE_$VERSION/Java:openjdk6:Factory.repo zypper refresh Java_openjdk6_Factory zypper install java-1_6_0-openjdk

Install the Java browser plugin

If you also want to install the browser plugin (to run Java applets and Webstart):

zypper install java-1_6_0-openjdk-plugin

Install the Java Development Kit

And if you also want to install the JDK to compile Java sources:

zypper install java-1_6_0-openjdk-devel

» FOSDEM X: 6+7 Feb 2010

Unlike previous editions, this time we're able to announce the date of the upcoming FOSDEM very early: 6 and 7 February 2010. This will also be the 10th edition (if we include the first one, that still had the name "OSDEM" :)), which means we'll try to think of a few extras ;) Thanks to the collaboration of our benevolent host (the ULB), we've been able to meet and already carve dates into stone.

» LOL @ Mono outpaces Java in Linux desktop development

This piece of... "art" has to be one of the most factually wrong and ridiculous pseudo-technical articles ever. Because its utterly unqualified author has 3 or 4 desktop applications running on Mono on his desktop, he states that Mono has overtaken Java (and, unlike the title of that article, he actually writes that it's not only on the desktop). I won't even go into debunking his points, they're so blatantly wrong that it's almost funny, such as MonoDevelop being a lot better than Eclipse, Eclipse not having code completion (almost spilled my coffee on that one), a buggy 64bit JVM (huh?), and that people don't develop a lot of web applications with Java any more, favouring ASP.NET and Ruby on Rails. Err... while there has clearly been quite a lot of traction for Ruby on Rails for the last couple of years, and while it certainly has its fair share of the market, neither ASP nor RoR are anywhere near the numbers of enterprise and/or web applications that have been and are still developed with Java. Oh, and "RossB" on the "SUSE Linux Enterprise in the Americas" blog, please don't relay such rubbish.