Recently, Eclipse started ignoring clicks on dialog buttons for me. This seems to be due to some changes in gtk 2.18. It does not use native windows for all widgets anymore, and SWT seems to rely on it.
Thanks to this blog post, I have this fix in my bashrc:
1 | alias eclipse="GDK_NATIVE_WINDOWS=true eclipse" |
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.
Working on another laptop, I was missing my quiltrc settings. I think, I got them from a this email by Marco d’Itri. Perhaps it is of help to somebody (for example, when I go searching for it again).
BTW, I changed it locally to check only for debian folder in parent directories and create debian/patches automatically if needed:
1 2 3 4 5 6 7 8 | for d in . .. ../.. ../../.. ../../../.. ../../../../..; do if [ -d $d/debian ]; then if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches fi export QUILT_PATCHES=debian/patches fi done |
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:
1 2 3 4 5 6 7 8 9 10 11 | d=. while [ ! -d "$d/debian" -a `readlink -e $d` != / ]; do d="$d/.." done if [ -d "$d/debian" ]; then export QUILT_PATCHES=debian/patches if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches fi fi |
This works with any directory depth while the original would only support 5 levels from the package base directory.
Ouch! This is the second time I am running into this so I’ll write it up this time.
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
1 | _helper_la_LDFLAGS = -module -rpath /freaking/libtool/requires/at/least/a/dummy/path |
Interestingly, the same scheme (apart from the wording) is used in libtool’s own source.
I was working on replacing some mockup code for testing an internal library with python. Basically, the C code is incredibly big and I would rather mock the 3rd party API we are using in python. I wrote a generator to create wrapping code that forwards the C API calls to my python module.
Now that most of the work is finished, I get the following error message from my python mock:
1 2 3 4 5 6 | Traceback (most recent call last): File "simple_mockup.py", line 2, in <module> import threading File "/usr/lib/python2.5/threading.py", line 11, in <module> from time import time as _time, sleep as _sleep ImportError: /usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError |
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):
1 2 3 4 5 6 7 | #include <Python.h> void test_python() { Py_Initialize(); PyRun_SimpleString("import threading\n"); } |
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; } |
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.
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…
I am moving from my old Debian development system to a new one, changing architectures from i386 to amd64. So I need to do a fresh install, but basically I want to keep my package selection.
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.
Great, I spent a few hours today to set up a nice OpenVPN server. Nice in that I wanted the (Windows) clients to be able to access the company network like they were connected locally.
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.
Now that there is some content here, I added myself to the Planet Debian blog aggregator. Sorry for my weird head image, the shadow looked much better in Gimp. I’ll have to correct that on another day…
Thanks to Holger Levsen for pointing me at the wiki entry which describes how a Debian developer can add himself to the Planet.
I got a new computer at home a week ago and finally got around to assemble all the parts. Which wasn’t as easy as expected, especially fitting the CPU cooler was a hard fight.
For the curious, here are the specs:
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.
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…
For the roundcube packages I wrote about before, I needed a lenny build system. I did not want to load the required packages to the production server. I used to use debootstrap for this but I wanted to keep a clean base system without copying around all the time.
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.
As mentioned in my previous post, I created packages of roundcube webmail version 0.3.1 for Debian lenny. The original purpose was to have a better webmail interface at my company.
These packages may also be of interest to other Debian users, therefore I make them available here:
Everything else you need is available at backports.org, most notably the database wrappers in php-mdb2.