Most of the channels are encrypted and can only be received with the original “Media Receiver”, which is a proprietary (and Microsoft) solution. But at least, I can watch the public service broadcasts using these playlists for VLC or mplayer.

Thanks to this blog post, I have this fix in my bashrc:

The Debian bug tracker also knows about this problem, which is partly fixed for the eclipse packages. Bad luck that I am using a download from eclipse.org.

BTW, I changed it locally to check only for debian folder in parent directories and create debian/patches automatically if needed:

I’d rather end up with a patches dir inside the debian folder instead of having it at a random place in the package sources when adding the first quilt patch.

I wonder if we should ship this with the quilt package!?

Update: After discussion with James Vega on IRC, the quiltrc evolved into this version:

This works with any directory depth while the original would only support 5 levels from the package base directory.

I used libtool via automake for building a python module. Quite unhelpfully, libtool happens to build only the static library. It does that even though I passed the -module option, which should make it clear that a static library does not help at all. There is also no mention why it skips the shared library.

After some research, my memory came back: libtool requires to pass the -rpath option to actually build shared libraries. I did not want to pass that options, since it is considered harmful where multiple variants of a library are available. It is even less useful in my specific case, as the module is only used inside the source tree for unit testing.

Solution: I changed the Makefile.am to use

Interestingly, the same scheme (apart from the wording) is used in libtool’s own source.

Now that most of the work is finished, I get the following error message from my python mock:

What’s going on here? This issue reminds me of a bug of my ancient Debian times which affected loading of GTK theme engines from python-gtk. The bug (#38138) is so old, it’s not even in the BTS archive anymore…

The problem is illustrated by the following example program (consisting of three files):

demo.c

1 2 3 4 5 6 7

#include <Python.h> void test_python() {     Py_Initialize();     PyRun_SimpleString("import threading\n"); }

main.c

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <stdio.h> #include <dlfcn.h> int main(void) {     const char *error;     void *handle = dlopen("./demo.so", RTLD_LAZY | EXTRA_RTLD_FLAGS);     void (*test_python)();     *(void**) &test_python = dlsym(handle, "test_python");     if ((error = dlerror())) {         fprintf(stderr, "%s\n", error);         return 1;     }     printf("Calling test_python @ %p in shared object @ %p.\n", test_python, handle);     (*test_python)();     dlclose(handle);     printf("Feels fine, finishing.\n");     return 0; }

run_it.sh

1 2 3 4 5 6 7 8 9 10 11 12 13

#! /bin/sh gcc -shared `python-config --includes` -o demo.so demo.c `python-config --ldflags` echo "Running example with default RTLD flags:" gcc -DEXTRA_RTLD_FLAGS=0 -o main main.c -ldl ./main echo echo "Passing RTLD_GLOBAL in addition:" gcc -DEXTRA_RTLD_FLAGS=RTLD_GLOBAL -o main main.c -ldl ./main echo

On my system, this results in the following output:

torsten@pulsar:~/sh_bug$ ./run_it.sh
Running example with default RTLD flags:
Calling test_python @ 0xb77084bc in shared object @ 0x96bc018.
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/threading.py", line 11, in 
    from time import time as _time, sleep as _sleep
ImportError: /usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError
Feels fine, finishing.

Passing RTLD_GLOBAL in addition:
Calling test_python @ 0xb783f4bc in shared object @ 0x95e1018.
Feels fine, finishing.

Sucky. So embedding Python into an application is easy but if you want to use the interpreter and its modules from a plugin, you are out of luck. Somebody knows a way around this problem? The only solution I can think of is to link libpython.so into each of the python plugins.

Update: Work around

Small update: For my current problem, the work around is to run the application with the python library preloaded: LD_PRELOAD=/usr/lib/libpython2.5.so.1.0 app. Back to adding functionality…

Conventional wisdom is to use dpkg --get-selections and dpkg --set-selections to preserve the package selection. However, this does not keep the information about automatically installed packages.

Instead, I used

aptitude search '?installed?not(?automatic)' -F %p > packages.txt

to dump the packages I installed manually. Installing these was a matter of running:

aptitude install `cat packages.txt`

In fact this was taking so long that I loaded the packages in batches using

cat packages.txt|xargs -n 100 aptitude install --schedule-only; aptitude

While I was at it, it ran

aptitude remove '?obsolete'

on the original system, killing of a few hundred packages that accumulated since 2003.

My idea was to use the OpenVPN tap mode and let the DHCP server at work assign IPs to the VPN clients.

This turned out to be a dumb idea. After I got everything going, I noticed the following message in syslog (which probably scrolled by previously in the debug drivel):

NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

Hmm, sure, I guess that will exclude every second incoming VPN connection.

Summary: Think about IP space clashes before setting up a VPN.

Thanks to Holger Levsen for pointing me at the wiki entry which describes how a Debian developer can add himself to the Planet.

Specs

For the curious, here are the specs:

CPU

AMD Phenom II X4 965 (4×3.4 GHz)

Mainboard

MSI 790GX-G65

Graphics

ATI Radeon HD 3300 (on-board)

RAM

8 GB, DDR3

Hard drives

2x SATA 1.5 TB (by Western Digital)

Ubuntu installation

For testing and having a first look, I installed Ubuntu karmic koala (amd64). Installation went like a breeze, everything was detected and worked out of the box. Well, kind of – graphics performance was dreadful. Which was kind of expected.

Debian installation

I originally thought about using Debian only inside virtual machines or change roots. Still, Ubuntu does not really feel like “the real thing”. So I went to install Debian, aiming at a sid/unstable installation.

The first boot using the official squeeze snapshot netinst image (Binary-1 20091128-11:21) went fine. Up to the first prompt: No input was possible. Probably a problem with the USB keyboard I had connected (Logitech wireless). Out of curiosity I tried the graphical installer, which did not even get so far. It was stuck in an endless loop trying to start an X11 server.

So I dug for a PS/2 connected keyboard and had more luck. I got to the point where the installer searches for the CD-ROM drive. As I did not want to dismantle my old system yet, I used an external USB DVD/RW drive. This was not detected by the installer so I was unable to continue installation. I guess, the NIC driver was also on the disc so no ethernet either.

Today I installed the DVD burner into the tower and had more luck. It still amazes me how easy it is to create my default storage setup using d-i (LVM on RAID). However, the installer failed to reread the partitions after I created two on each drive, interestingly telling me about /dev/sda2 being busy. Perhaps a left-over swap partition from the Ubuntu install? Anyway, after running fdisk manually and writing the same partition table again, I was able to continue.

The remaining d-i steps went fine, with just a nuisance: I was asked for the console font setting – twice. And I had no idea what it was asking of me, AFAIK UTF-8 should be fine for all possible uses. I selected # Latin1 and Latin5 – western Europe and Turkic languages. Not that I will see the console unless Xorg fails to run…

After having the base system running, I rebooted without selecting any more software, partly because I knew that the resync on md1 will need restarting after booting into the new system.

The new system booted fine and I called aptitude to install build-essential, Xorg and both KDE and Gnome desktops. This pulled in MySQL via akonadi-server (ouch!) and I was asked for a MySQL root password. Seriously, I don’t care, this is a desktop system. I tend to forget the password anyway and the last time, root was able to reset it. So I just hit Enter, leaving no password set. This lead to the installation asking me two more times for the password, which really sucks given that the server is only used by Akonadi for whatever reason and the last time I looked, it creates its own MySQL configuration.

Albeit my old system is 8 years old, the new system still seemed slower. Which of course is due to disk latencies, given that /dev/md1 was being synchronized in the background.

Anyway, I was eager to test the desktop experience and started gdm. X came up fine, but again I had no mouse and no keyboard (USB mouse, keyboard connected as well as PS/2 keyboard). I also was unable to switch to a VT, so I logged in remotely and rebooted the new system.

After the reboot, hal obviously picked up the input devices and X11 worked fine now. At this point, I stopped as the sunday almost passed already.

Summary: Debian installation still needs some improvements I think. Maybe our distribution is just too stable, after all my last install is 3 years back – due to a disk crash…

Relevant Debian bugs

• #558679: My installation report with some logs included.
• #558681: Nagging about MySQL root password.
• #558686: Failure to reload partition table.
• #545933: No USB keyboard support
• #315553: Installation from optical drive on usb fails (but this is for kernel 2.4)
• #558691: No keyboard and mouse after fresh installation of xserver-xorg.

After a bit of searching, I stumbled across schroot, which turned out to be a really useful package. The blog post “Joys of Schroot” by Enrico had me going in no time (thanks Enrico!).

Since I built a number of packages multiple times, I did not want to download the required dependencies each time. I also did not want to do any tricks with approx as suggested by Enrico. Instead, I added another bind-mount to /etc/schroot/mount-defaults:

/var/cache/apt/archives	/var/cache/apt/archives		none	rw,bind		0	0

With this simple change, the chroots now share the apt cache with my main system.