Ubuntu 8.10 Fixed problem with sound

In my previous post I wrote about a strange bahavior of my freshly installed Ubuntu. One of the problems was related to sound. I managed to get it working. It came out that something had muted the PCM channel of my sound card. ( while updating from Ubuntu 8.04)

You can fix it by right clicking on the “Sound” icon next to menu bar, choosing “Open Volume Control” and moving up the slider next to PCM label.

I read on some boads that it’s quite a common issue on Ubuntu 8.10, and quite a lot of people had problems with that. I hopy that this “silly” solution might help someone.

Ubuntu 8.10 first (bad)impression

Yesterday I found out that a new version of Ubuntu was released. Unfortunatelly I’m always excited in all the latest products and want to test them as fast as possible. That’s why I started to google for the safest and quickest possible way to upgrade.
My previous version of Ubuntu was 8.04 TLS, so I had to change some option in Software Sources dialog in order to make visible the latest version of Ubuntu.
I don’t know if you knew that but by default in Ubuntu only upgrades to “Long term” releases are performed. If you want to upgrade from 8.04 TLS into 8.10 you have to switch to “Normal releases” in Software Sources dialog.

If you need more details about this topic you can find it on the following web page: http://www.ubuntu.com/getubuntu/upgrading

Ok, but what I’ve written so far is not related to my impressions, so here I start:


My Update Manager had to work really hard and upgrade more then 1300 packages. All in all it took me about 1:20 h for downloading all of the files (on 2Mb/s connection) and then additional 30-40 minutes for unpackaging and setting them up. Unfortunately I started very late in the evening because I didn’t expect that it would take such a long time. Finally I ended up at 2:30 A.M.

First reboot

Although the installation took me some time, I didn’t have much problems with that. But when I restarted the computer the series of strange things started to happen.

Long startup
First of all the system initialized for more than 5 minutes. In the beginning I thought that it just hanged. But then it came out that the problem was related to ALSA demon which did not respond for the certain amount of time. After a given timeout it was killed by the system. That caused another problem which resulted in no support for sound.

No Sound – problematic ALSA
I managed to solve the startup problem temporarily by blocking ALSA daemon. But what’s obvious it didn’t help with the sound:( I guess that the new kernel that was installed in the system might cause some conflict with the sound card or sth.

NVIdia and Compuz Fusion
Another problem, that I faced, was related to Compuz Fusion and NVidia drivers. Fortunately all these eye-catching effects work, but sometimes I observe a strange behavior of my window title which blinks and disappear without any reason. This can be seen on pictures below (look at the right top of windows):


I can easily reproduce that strange behavior when the window is deactivated (should be transparent) and then activated by moving mouse cursor over the maximize button.


Another problem was related to Firefox. My Adobe Flash plugin stopped working. Firefox claimed that it was not installed, but when I wanted to do that it complained that it’s already installed:) Strange. I had to fix it by removing the plugin manually using apt-get and then reinstalling it back using Firefox.


To sum up my first impressions with new Ubuntu 8.10.
I must admit that at a first glance it’s hard to see any outstanding and innovative modifications in GUI. In my opinion that should at least influence system stability and reliability. Unfortunately even in this matter I’m not fully satisfied. Maybe my requirements are too high?? Thanks to previous releases of Ubuntu I got used to Linux which works perfectly just out of the box. For me in 8.10 this most crucial rule was violated:(((

AutoTools, tar and paths longer than 99 characters

I tried to build a Debian package for the project I am currently working on. Unfortunately all the paths I used in the structure of my application were very long. While executing make dist command I got lots of errors similar to the one below:

wzt-poc2/media-server/src/[....]wzt-children-manager/tests/: file name is too long (max > 99); not dumped

I found out that the error is due to the tar archiver. It does not support file names (in fact “paths”) longer than 99 characters. This problem can be easily solved by forcing AutoTools to use POSIX version of tar which does not have this limitation.

It is enough to modify a configure.ac file in the following way:

AC_INIT([your-application-name], [0.1.0])
AM_INIT_AUTOMAKE([1.9 tar-ustar])

The crucial part is inside the AM_INIT_AUTOMAKE declaration which changes the default tar archiver.

Making Debian library package with dh_make

This post is a short introduction to building *.deb packages using dh_make & dpkg_buildpackage tools.

Let us assume that we want to make a Debian package for a simple library. We are going to create two *.deb files, due to the fact that in Debian-based operating systems, libraries are usually distributed in one of the two forms:

  • dev package – containing both library binaries and header files for programmers. Used mainly by the developers.
  • standard package – storing only the library binaries

Having that in mind, we should start our work from downloading necessary utilities:

apt-get install dpkg-dev dh-make debhelper devscripts pbuilder fakeroot

Next step is to set a proper name for the directory containing the source code of the library.
It should have the following pattern: <package>-<version> ( ex. mylib-0.1.0 )
Inside that directory we execute a command generating files describing the content of the package:

dh_make -l

where “l” stands for library

We can notice that a new directory “debian” was created. It contains several files, the most important are described below:

  • changelog – Changelog for the package from which a number of the latest version is taken
  • control – File containing package description and its dependencies
  • rules – Script responsible for generating package (similar to make)
  • mylib1.install – List of directories containing files which should be copied to the package (normal package)
  • mylib-dev.install – Similar as mylib1.install but related to development package

Just to make it look better, let’s rename all “mylib1*” files into “mylib*” and then delete unnecessary *.EX and *.ex files. (these files are used in more complex packages, for example involving rc.init script modifications)

Exemplary content of the mentioned files is presented below:


mylib (0.1.0-1) unstable; urgency=low

* Initial release

-- TG <myemail@x.com>  Fri, 05 Sep 2008 17:40:45


Source: mylib
Priority: extra
Maintainer: TG <myemail@x.com>
Build-Depends: debhelper (>= 5)
Standards-Version: 3.7.2
Section: libs

Package: mylib-dev
Section: libdevel
Architecture: any
Depends: mylib (= ${Source-Version})
Description:  myITcorner.com Sample Library  (dev)
Development files.

Package: mylib
Section: libs
Architecture: any
Depends: libglib2.0-0 (>= 2.6), openssl (>= 0.9)
Description:  myITcorner.com Sample Library.
Binary package

Copy all the libraries from usr/local/lib


Copy all the libraries (also dev files) and C headers


Content of debian/rules script is more complex and in most of the situations we can base our package on the file generated by dh_make utility. However, some minor modifications presented below should be introduced:

#Configure and compile library from the
#source code and install it into temporary location
install: build
	dh_clean -k 

	# Add here commands to install
        # the package into debian/tmp
	$(MAKE) DESTDIR=$(CURDIR)/debian/tmp install

# Build architecture-dependent files here.
binary-arch: build install
	dh_installchangelogs ChangeLog
	dh_install --sourcedir debian/tmp

It’s worth mentioning that a structure of the above file is similar to Makefile script. There are some tasks and their dependencies. For example in install task a library is compiled and then installed into debian/tmp directory. Later in binary-arch, a Debian package is generated from the compiled data taken from debian/tmp directory.

Building the package

Package description and configuration files are ready. So how to make a *.deb files? For that purpose we can use the following command:

dpkg-buildpackage -us -uc -rfakeroot

But let’s make it simpler. Why not to add an entry in a Makefile, just to have everything in one place?
Assuming that we are using Autotools, here is the most interesting part of Makefile.am.


pkg-deb: dist
	- rm -rf  $(TMP_DIR)
	mkdir -p $(TMP_DIR)
	mv $(PACKAGE)-$(VERSION).tar.gz $(TMP_DIR)/

	tar --directory $(TMP_DIR)/ \
         -xf $(TMP_DIR)/$(PACKAGE)-$(VERSION).tar.gz

	cd $(TMP_DIR)/$(PACKAGE)-$(VERSION)/; \
                ./configure; \
                dpkg-buildpackage -us -uc -rfakeroot; \
                mv ../*.deb $(PWD)/pkg/

	rm -rf $(TMP_DIR);

In such a way a new task pkg-deb was defined. It executes another task called dist, which makes a tarball of the library source code. Later dpkg-buildpackage is called and just to clean everything up, some files are either removed or renamed.

It is important not to forget about including debian directory in the tarball generated with dist task. It can be done by adding the following line somewhere at the top of the Makefile.am:

EXTRA_DIST = debian

By the way TMP_DIR stores a location of the directory for the library installation files. In my case I assumed that

TMP_DIR = tmp

Now it’s enough to invoke:

make pkg-deb

Debian packages should be created inside pkg directory.

Debian New Maintainers’ Guide
Andy Balaam’s Blog

Problem with PKG_CHECK_MODULES under Mac OS X

Yesterday I had some problem with compiling my Glib application under Mac OS X. I knew that everything worked before on Debian and the problem had to be one of this darwin-specific.
Just to make myself clear. Here is the error I got after executing: ./configure

checking for pkg-config... pkg-config
./configure: line 3489: syntax error near unexpected token `GLIB,'
./configure: line 3489: `PKG_CHECK_MODULES(GLIB, glib-2.0)'

It seemed that there was some problem with PKG_CHECK_MODULES – autoconf’s macro responsible for detecting if a given library or module was installed in the system (basing on pkg-config).
In fact it came out that the macro was not defined at all. Normally after running aclocal command it should be generated in the file aclocal.m4. But in my situation there was no such entry.

Why did that occur? At that time I could not answer that question but at least I had some starting point.
You may probably know that aclocal is one of the tools of Autotools package. It creates a file named aclocal.m4 which includes a number of Autoconf macros that can be used later by configure. (one of these macros is of course PKG_CHECK_MODULES)
After reading the aclocal info page I found out that the aclocal.m4 file content was based on some external .m4 files and my configure.ac. I read that the PKG_CHECK_MODULES macro should be defined inside pkg.m4 file, and I really could find it there in my directory /opt/local/share/aclocal .

And here the answer came. I installed pkg-config and Glib using darwin ports, where the default prefix for packages was /opt/local. But on the other hand all the Autotools programs were located in /usr/bin. It was obvious that the prefix was different, so that aclocal could not detect pkg.m4 file and define PKG_CHECK_MODULES macro.

The only missing thing was to inform aclocal about the path of pkg.m4 and all other external .m4 files.
It was simple and could be done by adding extra parameter -I:

aclocal -I /opt/local/share/aclocal

Now after running my autogen.sh file which more or less looked liked that:

aclocal -I /opt/local/share/aclocal

and later


my application was compiled.
Of course this can be also achieved in many different ways. To find more solutions I recommend studying aclocalinfo page (especially secion Macro Search Path)

Glib, GObject and memory leaks

I’m working currently on a server application which uses Glib and GObject system. I wanted to test it with valgrind against memory leaks, but the results had really scared me. I got tens of memory alignment errors and hundreds of bytes that leaked somewhere. After investigating the problem I found possible reasons and a solution.
The main problem is related to Glib and the way it allocates memory. It doesn’t use a pure C-like way which is based only on malloc & free. It rather uses something called “slice allocator”.
If you don’t know what the “slice allocator” is, I will quote some useful information from the Gnome Reference Manual.

Memory slices provide a space-efficient and multi-processing scalable way to allocate equal-sized pieces of memory, just like the original GMemChunks (from GLib <= 2.8), while avoiding their excessive memory-waste, scalability and performance problems. To achieve these goals, the slice allocator uses a sophisticated, layered design that has been inspired by Bonwick's slab allocator. It uses posix_memalign() to optimize allocations of many equally-sized chunks, and has per-thread free lists (the so-called magazine layer) to quickly satisfy allocation requests of already known structure sizes. This is accompanied by extra caching logic to keep freed memory around for some time before returning it to the system. Memory that is unused due to alignment constraints is used for cache colorization (random distribution of chunk addresses) to improve CPU cache utilization. The caching layer of the slice allocator adapts itself to high lock contention to improve scalability.

If you are interested more information about “slice allocator” can be found here.

Unfortunately valgrind has some problems with the above concept and cannot detect if given blocks of memory were actually freed or not. When I tested a simple Glib application using g_slice_alloc with valgrind I got tens of memory alignment errors.
You can imagine how hard it can be to find some other errors/leaks which are not related to “slice alloc”, but are rather the fault of the programmer.
Having tens or hundreds of messages printed by valgrind can be quite misleading and in fact can hide some real problems. So how to avoid that? The simplest solution is always the best. Why can’t we disable “slice allocator”? Of course only for testing, later on when we are sure that there are no memory leaks in our application we can turn it on again.

In order to do this we have to set an environmental variable which disables the “slice allocator” and forces Glib to use normal mallocs.


There is no need to change anything in a source code, even the program doesn’t have to be recompiled.

Unfortunately “slice allocator” is not the only problem, the other one lies on the GObject side.
I don’t know why, but somebody invented a really “nice” function called g_type_init, which is responsible for initializing GObject type system. Ok, its great but why there is no g_type_deinit? Does anyone know where the whole memory that was previously initialized is freed? Valgrind doesn’t know that and again it complaints…
I managed to get rid of some of this errors by creating suppression files that are forcing valgrind to omit some of the most common errors. Of course it is not the best solution, but at least it can help to reduce the number of errors that are not the result of our fault.

The suppression file can be found below:

One thing is certain. The list of suppression will be expanding. The more I work with Glib the more suppressions I have to add. The current version of this file includes suppressions mainly from GHashTable, g_thread_init and g_type_init. If I find more possible leaks I will update this file.

Now it’s time to start valgrind with the whole configuration which allows to get rid of this Glib and GObject errors, the command is as follows:

G_SLICE=always-malloc valgrind --suppressions=build-aux/glib.supp --leak-check=full --show-reachable=yes ./our_program