» Serres de Laeken

Went to Brussels today to visit the "Serres de Laeken" (Royal Greenhouse). A very interesting and pleasent experience, especially as they're only open once every year, for 3 or 4 weeks. I shot a lot of photos, you might want to have a look at my set on Flickr.

» Infected

*hrhrhr*

» smart 0.41-16

Just released updated Smart 0.41 RPMs for SUSE Linux, namely version 0.41-16. This release includes the latest yast2 repository support fixes by Mauricio "netmask" Teixeira, most notably support for packages that share a description (which should get rid of empty package descriptions in yast2 channels). I also decided to change the preconfigured channels to use yast2 metadata instead of apt-rpm, for my own guru repository, but also for Packman and for download.opensuse.org. On SUSE Linux >= 10.0, smart-0.41-16 comes preconfigured with both the inst-source and inst-source-java channels, but for <= 9.3, it still uses the base component in the apt-rpm repositories at gwdg.de. apt-rpm channels are still used for the security and update components though. Furthermore, ksmarttray has been renamed to smart-ksmarttray and I've added a new subpackage smart-addons, that currently ships a .desktop file and a script to add local directories as smart channels (as with YaST2).

» Mapping unsupported keys with xmodmap

Nowadays, many keyboard have additional, so called "multimedia" keys (e.g. to increase/decrease volume, write an email, etc...). On notebooks, keys for volume up/down/mute are the rule rather than the exception. Those keys don't work out-of-the-box on Linux, or rather on X-Window (be it Xorg or XFree86). Let's see how to make something useful out of those keys.

The problem

Those keys are very well supported from a hardware point-of-view. Pressing them does trigger input events in the kernel, and they are even received by X-Window. But the problem is that you can only bind them to specific actions if they are mapped to a "keysym" (key symbol). Examples of key symbols: a, 8, EuroSign, Return, Escape, Home or F10. Key events are received as keycodes (numeric values) by X-Window, mapped internally to keysyms and then X-Window (or KDE, or GNOME, or whatever) reacts to those X events (KeyPress and KeyRelease + the keysym) accordingly. Those special keys on your keyboard don't work because although they send keycodes, they are not mapped to any keysym.

The solution

Here is the plan:

• bind the currently unassigned keycodes to unused keysyms (e.g. F13, F14, ...)
• use xbindkeys or khotkeys (KDE) to execute commands (scripts, DCOP, ...) when those keys are pressed

To bind keycodes to keysyms, we are going to use xmodmap.

xmodmap

xmodmap comes with X-Window, e.g. on SUSE Linux it's in the package xorg-x11. We're going to add keycode-to-keysym mappings in ~/.Xmodmap, which will be read by xmodmap on X server startup (actually, /etc/X11/xdm/Xsession and /etc/X11/xinit/xinitrc run xmodmap $HOME/.Xmodmap when that file exists). Note that you don't have a .Xmodmap file under your home directory by default (the system-wide /usr/X11R6/lib/X11/Xmodmap is used, that itself is a symlink to /etc/X11/Xmodmap). The syntax of ~/.Xmodmap for assigning keycodes to keysyms is as follows: keycode <keycode> = <keysym> Here, for example, the for the keysyms Return and Home: keycode 36 = Return keycode 97 = Home The format is very simple, but the most complicated part has to be done first: we have to find out the keycodes that are emitted by those special keys.

Finding the keycodes

To find out what keycodes are sent to X-Window by those special keys, we are going to use xev, that is part of the core X-Window package as well (xorg-x11 on SUSE Linux). xev is a handy little tool that opens a window and traces all the X events that are triggered when your mouse is above that window. It also tracks focus and mouse events that are of no interest to us in this case and that generate a lot of bloat. Start xev as follows to only show the KeyRelease events:

xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'

(just copy/paste that command on a shell and run it with your normal, non-root user) When the xev window appears, move your mouse above that window. Then press one of those special keys on your keyboard, and you will see the appropriate keycode in the terminal window where you typed the command above, for example:

160 NoSymbol
174 NoSymbol
176 NoSymbol

Note that after pressing the key, you will most probably have to move your mouse around above the xev window, as it seems to queue the X events and will only show the keycode after a few other X events have stacked up (MotionNotify events in this case, doesn't matter, will be enough to flush out the event queue and the keycode will show up in the terminal). Take good note of those numbers (160, 174 and 176 in our example above) and with what keys they are associated. Note that the numbers from our example correspond to the "volume mute", "volume increase" and "volume decrease" special keys on a Dell notebook. We're now finished with xev, so you can terminate by typing Control+C in the terminal where you entered the xev | ... command above.

Back to xmodmap

Now that we have the keycodes, we can write them down in our very own xmodmap configuration, namely in the file ~/.Xmodmap. We just have to decide to which keysyms we shall map them. I would recommend to use keysyms that are usually not bound to any keys, like F13, F14, and so on. In this example, we're going to bind the keycode 160 to the keysym F13, 174 to F14 and 176 to F15. Use your favorite text editor (vim, emacs, kate, nano, whatever) and put the corresponding lines in a file named .Xmodmap (note the dot and the capital X) under your home directory, like this:

keycode 160 = F13
keycode 174 = F14
keycode 176 = F15

Applying the xmodmap configuration

The ~/.Xmodmap file will automatically be interpreted by xmodmap every time you start the X server with startx or when you log into an X session using XDM/KDM/GDM. But to avoid restarting our current X session, here is how to apply our configuration immediately:

xmodmap ~/.Xmodmap

KHotKeys

Now the keys can effectively be used in applications like KDE's khotkeys, to be bound to commands or actions. As an example, here is how to bind our new F13 keysym to mute the sound volume, by sending a DCOP call to kmix: 1) start the KDE Control Center (kcontrol) 2) select "Regional & Accessibility" 3) select "Input Actions" 4) in the "General" tab, create a new action (using the "New Action" button), and give it a name in the "Action Name" text box (e.g. "mute volume") 5) still in the "General" tag, select "Keyboard Shortcut -> DCOP Call (simple)" for the "Action type": 6) go to the "Keyboard Shortcut" tab, click on the box that shows "None" and type the special key you want to assign to that action - as for our example, the box should then show "F13" 7) go the the last tab, "DCOP Call Settings" and enter the following data: * Remote application = kmix * Remote object = Mixer0 * Called function = toggleMute * Arguments 0 Then press the "OK" button and... we're done :) If you want something that works with any window manager, have a look at xbindkeys (SUSE Linux RPMs of the latest xbindkeys version here)

» Upgrade OpenOffice.org on SUSE Linux

OpenOffice.org upgrades are provided in the projects/OpenOffice.org subdirectory on several mirrors, as RPMs specifically tailored for SUSE Linux. To avoid the tedious procedure of downloading them yourself, one should better use some package manager frontend like YaST2, smart, apt, yum. Unfortunately, that "projects/OpenOffice.org" directory has no repository metadata as of now (hopefully been fixed soon), but Eberhard Moenke of ftp.gwdg.de kindly provides some in his apt-rpm SUSE repositories. Here is how to add that repository as a channel in smart (get my SUSE RPMs of smart here) for easy upgrading.

Prerequisite: have smart installed on your SUSE Linux

If you have my repository in your list of YaST2 installation sources, then it's as easy as running

yast2 --install smart

followed by

smart update

(both as root). The first time you run smart (as above), you will be prompted for a list of channels (= package repositories, in smart-speak) to include (or not) in order to install packages and resolve dependencies. My recommendation is to include all of them (= SUSE Linux repositories for the base system and updates, my repository and Packman). If you don't have my repository in your list of installation sources, add it like this:

installation_sources -a http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.0

(or 10.1, or 9.3, or 9.2, ...)

Add the OpenOffice.org apt-rpm repository in smart

smart channel --add openoffice type=apt-rpm baseurl=ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.0-i386 components=openoffice

Note: obviously, if you use 9.3, change the baseurl parameter above accordingly ;) Also, you might notice that there are no x86_64 RPMs for OpenOffice_org - that's fine; if you have a 64bit system (AMD64 or EMT64 and a x86_64 kernel), just install the i586 binaries, they will run just fine thanks to the biarch infrastructure and 32bit variants of required libraries. So, regardless of whether you have a 32bit (i586/i686) or 64bit (x86_64) Intel/AMD system, use the URL as above with -i386 (but make sure to use the proper distribution version in the baseurl URL).

Add one or more mirrors for that repository

ftp.gwdg.de is often under very heavy load, as it is the primary mirror for SUSE Linux. Hence, to have better download performance and to avoid putting even more load on ftp.gwdg.de, we're going to add a mirror location for that repository in smart. Here's an example with a fast mirror in Europe (Germany, actually):

smart mirror --add ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE ftp://ftp.uni-erlangen.de/pub/mirrors/suse/apt/SuSE

Synchronize/download the repository metadata

Now let's tell smart to synchronize the metadata for that channel. In this case, as we've just added the channel, it will download (the metadata, not RPM files):

smart update openoffice

Upgrade the OpenOffice_org packages

And finally, let smart get the real job done:

smart upgrade OpenOffice_org\*

(the \* is just a shell escape, to avoid the shell completing that expression with filenames, in case you'd have files named OpenOffice_org-something in the current working directory)

» G43||3 15 +3h h4x0r

Yes, I have proof, my daughter Gaëlle will be a l33+ h4x0r355:

Damn, she's already trying to brute force my password:

» How to use smart with SUSE Linux Factory

The current interim release candidate of SUSE Linux 10.1 is RC1. As probably everyone knows, it still has a few major issues with the new package management backend in YaST2, which is quite unfortunate because apart from that, 10.1 is awesome. As an alternative, you might want to use the Smart package manager, for which I provide RPM builds for SUSE Linux (FTP / mirror). My Smart RPM packages come preconfigured with my repository as well as packman and the SUSE Linux repositories (inst-source, inst-source-java and online updates). For the 10.1RC1 RPMs of smart, the preconfigured repositories are wrong, as they point to the locations where the repositories of 10.1 final will be available. Here is how to change the channel (in smart speak) / installation source (in YaST2 speak) configuration to use the SUSE Linux Factory repository instead. (and no, you can't use an online repository of 10.1RC1, that snapshot is only provided as ISO images)

Install smart

First things first, let's install the smart RPM for 10.1RC1 (if you haven't done so already). Here is how to do it with YaST2 (from a shell, as root):

yast2 --install   http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/System/smart/smart-0.41-15.guru.suse101.i686.rpm

or with this command if you have a 64bit system (AMD64 or Intel EMT64):

yast2 --install   http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/System/smart/smart-0.41-15.guru.suse101.x86_64.rpm

In case that doesn't work (because YaST2's package management backend still has some issues as of 10.1RC1), here is how to do it with rpm directly:

rpm --install -hv   http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/System/smart/smart-0.41-15.guru.suse101.i686.rpm

or like this for a 64bit system:

rpm --install -hv   http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/System/smart/smart-0.41-15.guru.suse101.x86_64.rpm

rpm might complain that you don't have the required package rpm-python installed on your system. If that's the case, use YaST2 to install rpm-python first, and then repeat the rpm command as above. You can also use rpm directly to install rpm-python:

rpm --install -hv   ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/i586/rpm-python-4.4.2-37.i586.rpm

or like this on a 64bit system:

rpm --install -hv   ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/x86_64/rpm-python-4.4.2-37.x86_64.rpm

Note that newer versions of smart might be available in the mean time, so please check the latest smart version/release first by pointing your web browser here: http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/System/smart/ and pass the right URL to the yast2 command above.

Remove channels for SUSE Linux 10.1 final

Now that smart is installed, we have to remove the existing smart channels for 10.1:

smart channel --remove suse-apt-base-gwdg
smart channel --remove suse-apt-update-gwdg
smart channel --remove suse-apt-security-gwdg

Add the SUSE Linux Factory channel

The next step is to add a channel for the primary SUSE Linux Factory repository:

smart channel --add factory type=rpm-md    baseurl=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse

Add a mirror

And finally, let's add the ftp.heanet.ie mirror to speed up downloads and to avoid putting to much load on ftp.gwdg.de:

smart mirror --add    ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory    http://ftp.heanet.ie/mirrors/ftp.opensuse.org/opensuse/distribution/SL-OSS-factory

Perform the upgrade

To actually perform the upgrade, use the following command:

smart upgrade --update

» Dalmatia, here we come again

Booked the hotels for our holidays in July, going to Croatia again (eh... this is my 10th time over there), on the Dalmatian coast. We'll be heading off for Bled, stay there over night, then drive up to Trogir (near Split) where we'll stay for two weeks, in a nice little hotel. This time, on our way back, we'll also be staying two full days in Plitvice, a breathtaking location. Unlike two years ago we'll really try to make some small trips to a few of the many beautiful islands along the coast, I think Korcula definitely deserves a visit. And, of course, although it's a long drive, we'll just have to spend a day in Dubrovnik again.

 

I just wonder how Gaëlle will cope with the long drive, but it seems she's ready for it and looking forward to 3 weeks of sun, sea, relaxing and a lot of siteseeing. Well, obviously, I am ;) In case you've never been in Croatia, check out my photos on Flickr, I have several sets (by location) of pictures we took there 2 years ago.