I think it was some component of KDE 4.1.x, which required a libX11 with enabled xcb use flag in Gentoo Linux. So I recompiled the library with the correct use flag. However, this in turn cause problems with Java (1.4 versions I think). I noticed it the first time, when I installed the latest Jalbum 8.1* version. When the Jalbum installer is started, it aborts with an assertion:

java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

This was on my Linux box at home. After some googleing I fixed it by updating some library and completely forgot about it.

Now, at work I wanted to install the new DB2 Express C 9.5.2beta and came across the exact same problem, now with a IBM Java version, which is included in the DB2 installation package (J2RE 5.0 IBM J9 2.3). One fix, that can be found on the Net is the following:

sed -i 's/XINERAMA/FAKEEXTN/g' */jre/bin/xawt/libmawt.so

In case for my DB2 installation, this is somewhat messy, since it would require the unpacking and repackaging of the DB2 Java archive.

The fix, that I used for my original Jalbum installation problem and which is the best solution IMHO, at least for Gentoo people, is to replace the libxcb with a newer version, which contains a workaround for the xcb_xlib_unlock assertion. This means, that first of all x11-libs/libxcb and x11-proto/xcb-proto need to be included in the /etc/portage/keywords file. Then I installed these packages:

# equery l xcb
[ Searching for package 'xcb' in all categories among: ]
* installed packages
[I--] [ ~] x11-libs/libxcb-1.1.90.1 (0)
[I--] [  ] x11-libs/xcb-util-0.2 (0)
[I--] [ ~] x11-proto/xcb-proto-1.2 (0)

You can check with this command line, if you have a libxcb with the appropiate workaround.

# strings /usr/lib/libxcb.so|grep XCB
LIBXCB_ALLOW_SLOPPY_LOCK

Now you can set the LIBXCB_ALLOW_SLOPPY_LOCK environment variable appropriately.

export LIBXCB_ALLOW_SLOPPY_LOCK=1

Now, the 1.4 Java should successfully run. You will still get an error message, but the program won’t abort. This assertion problem should be fixed at least in the current 1.6 Java versions.

In my company at the end of the day I’m putting my PC into S3 sleep state and wake it up next morning. In the past I had been using the /proc/acpci/alarm ACPI device to setup the alarm clock, so that the PC would already be ready when I return to my desk. Sometime in the past with I don’t know which new kernel version I lost the ability to use the alarm function (or due to some reconfiguration in the kernels ACPI parameters). So I manually switched the PC on (what else?).

Apparently I didn’t look hard enough for a solution, then I would have found the below earlier. I found the solution in the KnoppMyth vincinity.

Check if you have a directory rtc0 in the /sys hierachy.

ls /sys/class/rtc/rtc0/

If you don’t have this directory you might need to check, if the appropriate rtc-module is loaded. For me it is rtc-cmos. See to it, that it is correctly loaded during boot.

Apart from other files, there should be a file named wakealarm. Write 0 to file to disable the wakeup function, otherwise write the seconds since the epoch (seconds since Jan 1st 1970) to the file.

disabling
# echo 0 > /sys/class/rtc/rtc0/wakealarm 
wakeup after 5 minutes
# echo $(date '+%s' -d '+ 5 minutes') > \ 
    /sys/class/rtc/rtc0/wakealarm
or wakup tomorrow at 7:15
# echo $(date '+%s' -d 'tomorrow 7:15') > \ 
    /sys/class/rtc/rtc0/wakealarm
# cat /sys/class/rtc/rtc0/wakealarm

You might want to check the output of the file /proc/driver/rtc:

# cat /proc/driver/rtc
rtc_time        : 15:09:52
rtc_date        : 2009-01-07
alrm_time       : 07:15:00
alrm_date       : 2009-01-08
alarm_IRQ       : yes
alrm_pending    : no
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay

What I noticed however, when I write multiple times to wakealarm I’m getting an error message.

# echo 0 > /sys/class/rtc/rtc0/wakealarm
# echo $(date -u '+%s' -d 'tomorrow 7:15') > /sys/class/rtc/rtc/wakealarm
# echo $(date -u '+%s' -d 'tomorrow 7:15') > /sys/class/rtc/rtc/wakealarm
echo: write error: Device or resource busy

This error is cleared by another echo 0 > ....

Der Winter hat uns. Und das, wo es ab morgen wieder zur Arbeit gehen muss.

Managed by the beautiful Tellico program, I’ve updated my database of books I own and have read. Currently the number is at around 560 books, while the next batch is already on its way from Amazon. And this doesn’t count the books about knowledge stuff (programming, computers, etc). And I guess about 2/3 is in English, which is not my native tongue. Not so bad, I think.

I’m a big fan of the ScribeFire Blog Editor. There is one very annoying behaviour however, that each time I’m pressing the key, which generates the X11 modifier ISO_Level3_Shift (and also the key with the modifier Super_L), that a new window with the ScribeFire online help opens. Since I’m composing the articles with the Markdown WordPress plugin and a German keyboard layout, I’m frequently required to the press the ISO_Level3_Shift key. Fortunately, once the ScribeFire online help window has opened and has been placed below the main browser windows, it stays there, although the online help page is loaded each time the ISO_Level3_Shift key is pressed. Am I the only one, who sees this behaviour under Linux?

By choosing an readily available external theme, I though these IE CSS compatibilty issues would have been taken care off, but I was apparently wrong. I had omitted to look at this site with IE6, since at home I’m mostly working in a Linux environment. But today at work I took a quick look with IE6 and the result is, that I switched to the Abstractia theme, which also looks good in IE. I guess I need to check, if my minor changes caused the degradation of the Livegreen theme, but what I saw with IE6 was not very nice. And I’m really tired to relearn the IE quirks, each time I want to do a bit CSS styling after a bit of time doing no Web work.