Console keyboard layout and beep

Two quite annoying bits to remember so lets blog 'hem. Under a tty the keyboard may have a bad layout, I know perfectly changing it under X with setxkbmap but I usually Google for the console. The answer is loadkeys. Running loadkeys -d will print the current map file that gives an idea where to find the maps. Switching the map works like loadkeys /lib/kbd/keymaps/.../fr-latin1.map.gz, in other words just pass the map file. Now to come to the other annoying command to remember is the ability to cut off the beep. It works with setterm -blength 0.

Update: passing the locale directly to loadkeys works (thanks Boris), neither the help output nor the man page mentions this.

Fast Python debugging with Vim

So I just needed to test some lines of Gtk+ code and preferably with Python. I love the interpreter (just as well as irb) but debugging even small Gtk+ pieces is not very attractive in the end. Therefore I jumped into Vim, typed my small script, and then executed the command ":%!python -". Only problem is that after the command exits it replaces the content of the Vim buffer with the console output that contains Python debugging messages as well, a quick press on "u" reverts this but maybe there is a cleaner way.

MP3 support on Moblin (part 2)

Part 1 showed the easy way. Now the hard way to get MP3 support is to provide it yourself by building plugins for GStreamer. Having an RPM build environment is a prerequesite. The earlier blog entry shows how to set it up and also has an example to build and install libmad which will be useful in this example and I won't repeat it here.

Download the gstreamer-plugins-ugly source package. Put it inside the SRPMS directory and run the rpm -i command on it to unarchive its content.

Open a text editor and edit the spec file available under SPECS. The package names vary between Moblin, Fedora and RPM Fusion and this needs to be fixed in the header. And in this example only the plugin libmad will be build so that's why many lines will be commented. In fact the only build dependencies will be libmad, libid3tag and liboil. I have put the diff on Snipt. To apply it use the patch command like patch -p0 < gstreamer-plugins-ugly.spec.diff. Don't miss the patch(1) man page to know about the -p option.

Now build binary packages with the command rpmbuild -bb SPECS/gstreamer-plugins-ugly.spec. Wait a minute and you should have a ready to install gst-plugins-ugly package within the RPMS directory.

You can more or less repeat this task for DivX and other video codecs support. For that you'll have to build the GStreamer FFmpeg plugin (gstreamer-ffmpeg source package). Of course FFmpeg depends on many many libraries and you'll have to build them at first.

Update: Regarding FFmpeg, it can be build from the RPM source package without external requirements, in fact it doesn't have any hard dependencies. Or you can even compile the gstreamer-ffmpeg plugin only with the internal FFmpeg sources since it is optionaly linked to an external FFmpeg library. In both cases the provided SPEC files have to be modified.

RPM build environment on Moblin

I once set up an RPM build environment on my netbook to build missing packages, often small tools. There are many docs to do that, for myself I browsed the Fedora project wiki. If you are looking for RPMish stuff you are in the right place there.

Preparation

The package rpmdevtools provides scripts for the packager, one of them is rpmdev-setuptree. This tool will set up automatically the build directory for keeping source packages, spec files, etc. You can run this command now. Within your home, it will create an rpmbuild directory and a hidden .rpmmacros file. You can move the rpmbuild directory where ever you want but you will have to fix the variable %_topdir in the hidden rpmmacros file.

That's already about it.

Build example

Lets take a small example to show the use of the RPM build environment. Download the source package libmad from RPM Fusion. Copy it to the subdirectory SRPMS and then unarchive it with the command rpm -i SRPMS/libmad-[version].src.rpm. And finally you can build the binary packages with the command rpmbuild -bb SPECS/libmad.spec. The rpmbuild command is provided by the rpm-build package.

By now you can install the packages within the subdirectory RPMS, libmad-[version].rpm and the -devel package, if you wish to build the source package madplay to play MP3s from command line :-)

External sources

• Packaging guidelines
• How to create an RPM package
• Fedora Koji
• RPM Fusion
  

MP3 support on Moblin (part 1)

The easiest way to add support for MP3 is by installing a pre-build RPM package. Fluendo has one available for free. The reason Moblin isn't distributing a decoder is of legal issues, however one might get them by "legal" ways where that term will vary amongst different juridictions. It clearly is an annoying topic to raise up! If you buy a laptop you can expect to have MP3 support since the sellers have ways to collect royalties. At least that's what I learned from the Moblin mailing-list.

Installing an RPM is done by running the simple command "rpm -i [package]" with the super user.

Build a project with Vala

This post is about using Vala in a project but in the end provide the C code for the releases. I think that this is very essential and that releasing source code to be build from Vala is wrong. Vala will always rewrite the code to GObjects in C, but has already proven that compiling the same code from two different versions of Vala will fail. So when you are doing releases with Vala you will break your releases sooner or later. Another good point is when the Vala code is compiled on top of patched vapi files, doing only C compilation with the releases will drop the requirement to apply them.

I'll take as example the Autotools, if you are using a different tool-chain you can surely adapt it. The idea is simple, the Vala sources are only compiled in maintainer mode. When you compile the application from the development branch you will usually have a script called autogen.sh to build the configure script that will automatically be executed with the parameter --enable-maintainer-mode. When providing the distribution tarball that is created with make distcheck, the configure script will not be run with that parameter (except if specified by hand) and the source files to build from will be filled in with the C filenames.

The example below is very generic and can be copy/pasted but should be adapted.

Autoconf script

1. The initialization of Automake and the maintainer mode in the autoconf script. The Automake version is checked for 1.11 which is the first version that comes with Vala support. The extra dist-bzip2 argument is there to provide an extra bzipped distribution tarball as you guessed it.

AM_INIT_AUTOMAKE([1.11 dist-bzip2])
AM_MAINTAINER_MODE()

2. The check for Vala only on maintainer mode. The AM_PROG_VALAC defines the variable VALAC that can be reused inside the Makefile.am files and accepts an optional version check.

if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
  AM_PROG_VALAC([0.7.4])
  if test "x$VALAC" = "x" ; then
      AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
  fi
fi

3. It is possible to sum up the build configuration at the end of the autoconf script.

echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode:        $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo "    * Vala:               $VALAC"
echo
fi

Automake script

1. The declaration of the Vala sources and their respective compiled C sources.

product_VALASOURCES = \
  obj1.vala \
  obj2.vala \
  main.vala

product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h

2. Use the special BUILT_SOURCES variable to build given targets before running a dist with e.g. make distcheck. This usually done in maintainer mode, as in this case to be sure the releases won't have anything to do with Vala.

if MAINTAINER_MODE
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
  $(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
  touch $@
endif

3. The final sources for the product are filled in with the generated Vala sources. The Vala sources are not passed to any SOURCES which is why they are passed to the special EXTRA_DIST variable.

product_SOURCES = \
  random-source.c \
  random-header.h \
  $(product_VALABUILTSOURCES)

EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
  $(BUILT_SOURCES) \
  $(product_VALABUILTSOURCES)
endif

That's it

There are many existent Vala projects nowadays from where you can pick up new ideas, and this post is just an example amongst many others. The full example is available in the xfce4-vala bindings.

Update: I corrected some mistakes seen in green in the script portions. If VALAC is unset the configure script must quit otherwise the resulting Makefiles will have empty commands instead of /usr/bin/valac. Also the generated header file must be passed to product_VALABUILTSOURCES otherwise it would have been left out from distributions as it wans't passed to any product_SOURCES nor EXTRA_DIST variables.