Littletux's blog - Debian

First impression of upstart

nospam@example.com (Andreas Fester) — Wed, 24 Jan 2007 22:46:58 +0100

Yesterday, I had a closer look at upstart, a replacement for the sysv init daemon. My goal is to speed up the boot process of my Debian desktop installations, and the two systems which could help with this are upstart and initng. There are packages for upstart in Debian experimental, and installing is quite simple, but besides the upstart package itself it is almost a must to also install the package upstart-compat-sysv, otherwise commands like reboot and shutdown are not available anymore. Also, this package provides a default configuration for the upstart jobs which simply emulates the sysv-init based rc mechanism.

Upstart uses the notation of jobs to define the services to start. Unfortunately the sysv-init emulation simply defines jobs like rc1, rc2 and so on, i.e. one job per run level; then, the old sysv-init scripts are still used to launch the services one after the other. The result is that the boot process still took 31 seconds, exactly the same time it took with the sysv-init system.

I then started to write some jobs to launch services like apache2 and sshd independently from the rc scripts, using upstart event definitions. Creating the scripts themselves is quite easy, but I did not manage to stop the services again through upstart's initctl command line interface: it seems that, since the processes fork, upstart assumes that they are stoped again after they have been launched.

Investigation is ongoing ...

Debian work done lately

nospam@example.com (Andreas Fester) — Sat, 14 Oct 2006 15:31:59 +0200

Last week, I fixed my first RC bug: it was caused by the removal of libapr0, which rendered my subcommander package uninstallable. Since there was also a new upstream version available, I combined this with the upload.

Since some weeks, my debian package overview looks messed up. All entries appear twice, and most of my (not yet so many ) packages are missing. It seems that this happened after the upload of libtest-unit-perl, the first package I co-maintain within a group. So, I spent some time today setting up a local qa.debian.org environment and tracking down what goes wrong. I have created a bug report with an attached patch which should fix the issue; I hope that it will be committed sometime soon so that the complete package overview is working again.

AMD64 burning issue (solved)

nospam@example.com (Andreas Fester) — Thu, 13 Jul 2006 23:02:05 +0200

Since I upgraded to the AMD64 architecture some months ago, I always had the problem that burning CDs did not work anymore. I used a command line like

cdrecord -V gracetime=2 dev=3,0,0 speed=24 -dao -dummy driveropts=burnfree -eject -data test.iso

but burning failed some seconds after the write started.

Now, it seems that I found the solution: with kernel 2.6 and udev, it is not necessary to use the device numbers anymore. Instead, the device file can be used directly, like

cdrecord -V gracetime=2 dev=/dev/cdrw speed=24 -dao -dummy driveropts=burnfree -eject -data test.iso

This also seems to influence the way how cdrecord and the kernel interact, because the write process now does not abort anymore.

Shooting yourself in the foot ...

nospam@example.com (Andreas Fester) — Sun, 04 Jun 2006 14:06:58 +0200

... when installing an Oracle 10 database:

When the Oracle Database Configuration Assistent asks for the database system passwords, enter something like "abc%123". Later, when the Assistent launches the instance, spend two hours to find out why the instance shuts down again almost immediately. Finally, find this in a log file:

ORA-00604: error occurred at recursive SQL level 1
ORA-00911: invalid character
Offending statement at line 2254
create user sys identified by abc%123

... when creating a Debian package:

Spend two hours to find out why your package does not display a configuration message during installation. Finally recognice that the debconf database was messed up. Then simply fix it with

# debconf-communicate
PURGE

Renaming a Debian package

nospam@example.com (Andreas Fester) — Mon, 29 May 2006 22:02:38 +0200

Recently, the authors of lincvs decided to rename the software to crossvc. This put me as the current maintainer of the lincvs Debian package into a new situation: How do I rename a Debian package? It turned out that this is indeed not so trivial, especially when a seamless upgrade should be possible with apt-get dist-upgrade. After a short web research, it turned out that the following steps are necessary:

Create a new package with the new name which will get uploaded to the NEW queue. This package Replaces, Provides and Conflicts with the old package:

Replaces: oldPackage
Provides: oldPackage
Conflicts: oldPackage (<< firstVersionOfNewPackage)

Replaces and Conflicts are obvious, and Provides assures that other packages which depend on the old package still can satisfy their dependency.
Once the package has moved from the NEW queue to unstable, create a new revision of the old package which serves as dummy package. It does not install any files (except the mandatory ones in /usr/share/doc) and depends on the new package.
Finally, after the current testing distribution has been released, file a bug asking ftpmaster to remove the old, dummy package.

I asked on debian-devel whether this is the correct approach, and it seems to. There is still some discussion ongoing whether the new package can itself provide the dummy binary packages of the old package. This would make the process much simpler ...

[UPDATE]
It turned out that is indeed possible to skip the step of uploading a new revision of the old package when the new package has left the NEW queue. A source package can own other binary packages which are already in the archive, and takeover ownership once they are uploaded. So, for the seamless upgrade, the new package simply needs to create a new binary version of the old package which depends on the new package:

Package: oldpackage
Architecture: any
Depends: newpackage

Oracle Client installation progress

nospam@example.com (Andreas Fester) — Wed, 01 Mar 2006 21:59:29 +0100

I finally managed to get the installer working (Thanks to the OTN discussion forums). The trick described there indeed works: simply temporarily rename /usr/X11R6/lib/X11/locale and symlinking /emul/ia32-linux/usr/X11R6/lib/X11/locale to /usr/X11R6/lib/X11/locale.
Then, the installer can be successfully started.

I then run over another Oracle-Debian incompatibility (but I already observed this on i386 as well, but stoped investigating back then because I had an older installation which was still running): The installer stops when linking ntcontab. There seem to be some sed incompatibilities, since the installer logfile contains output like

INFO: /bin/sed: -e Expression #1, Character 7: unterminated `s' command

The installer then hangs around for ever without utilizing CPU time. I saw that there are some make and grep processes hanging around, and it seems that the grep process waits for input but does not get it, causing it to wait forever. So I simply killed the make and the grep processes (I had to do this several times for the grep process) until the installation continued.
The net configuration assistent failed to link and to run, so I had to manually configure sqlnet.ora and tnsnames.ora. Result: the client applications like sqlplus are running well!

The difference in x86_64 linux distributions

nospam@example.com (Andreas Fester) — Wed, 01 Mar 2006 20:40:25 +0100

Most (commercial) linux distributions install their x86_64 version as a mixed environment. This means that the 64 bit libraries are installed in /lib64 and /usr/lib64, while the usual directories /lib and /usr/lib contain 32 bit libraries which are necessary to run 32 bit applications.

Debian, on the other hand, provides a pure x86_64 distribution (the amd64 port), where the 64 bit libraries are installed in /lib and /usr/lib. 32 bit libraries are either installed below /emul (through the ia32-libs package) or in a completely separate chroot environment. The chroot environment has the advantage that it uses the normal i386 packages and can even be updated with "apt-get dist-upgrade" separately from the 64 bit installation.

32 bit applications like OpenOffice run very well in the chroot environment, and even building i386 packages is possible. The only disadvantage is that the chroot environment can take up a significant amount of space.

The real problems arise if you need to install a 64 bit application which uses an installer which is built as 32 bit application. No one does this? Sure. Oracle does.
And they require a mixed installation. There seems currently no way to install the Oracle client on an amd64 debian installation.

My personal debian archive

nospam@example.com (Andreas Fester) — Sat, 05 Nov 2005 10:10:48 +0100

Yesterday I replaced my personal debian archive at http://www.littletux.net/debian (which used a simple, flat structure) with a pool based archive. The archive is handled by debpool, a debian archive management tool which is quite simple to set up. It is available from the Debian experimental archive. The main advantages from this tool are that I can use the standard dupload tool to upload packages to the archive, and that it allows to manage packages for various distributions like stable and unstable.

To access the archive, it is sufficient to add lines like

deb http://littletux.homelinux.net/debian unstable main contrib non-free deb-src http://littletux.homelinux.net/debian unstable main contrib non-free

to /etc/apt/sources.list. Note that www.littletux.net does not work.

Switched to X.org

nospam@example.com (Andreas Fester) — Sun, 23 Oct 2005 10:02:52 +0200

Yesterday, I spontaneously decided to replace the XFree86 X server with the new X.org X server on my desktop computer. A simple "apt-get install xserver-xorg discover1 mdetect xresprobe" was sufficient to migrate the server. I already heard that migration is quite simple and problem-free, so I was strained what would happen after I restarted the X server. I was excited that the server indeed started up and displayed the window manager, so at least the basic setup worked. I only had to make two additional refinements:

I replaced the "nv" driver with the "nvidia" driver. This involved re-installing the nvidia driver, because the installation I used for XFree86 did not work anymore.

I removed resolutions which I do not want to use; the one which was used as default caused the monitor to run at 60 Hz or similar.

Of course, I also tried some of the new features, especially transparency. To enable these features, the "Composite" extension must be activated with an entry like

Section "Extensions" Option "Composite" "true" EndSection

in the xorg.conf configuration file. However, for NVidia cards, this has the effect that the "glx" extension can not be used anymore. This can be changed by adding "Option "AllowGLXWithComposite" "true"" to the "Device" section in the xorg.conf file. Then, applications which use glx (like glxgears) work again.

I then activated transparency in the KDE control center. However, the "nvidia" driver seems to be really unstable when activating this feature, the X server crashed several times. So I switched back to the "nv" driver, which seems to be more stable. In either case, moving transparent windows was very slow, and also adding "Option "RenderAccel" "true"" as sometimes suggested did not help. For now, I deactivated the transparency feature again, but I look forward to this being more stable, because it looks really cool!

Next LinuxTag in Wiesbaden

nospam@example.com (Andreas Fester) — Sat, 15 Oct 2005 09:46:23 +0200

Unfortunately, LinuxTag, Europes largest Linux event, moves to Wiesbaden next year. The last three years it was in Karlsruhe, the town where I live. So I could simply walk to the event in about five minutes. I also visited it before, when it still was in Stuttgart, which is about 80 km from Karlsruhe. The presentations were always truly interesting and gave me new input. Lets see if I will make it to Wiesbaden next year; its about 150 km from Karlsruhe which is still not that far.

Adopting the synopsis package

nospam@example.com (Andreas Fester) — Mon, 10 Oct 2005 21:09:32 +0200

While I introduced myself into python lately, I was also looking for a useful tool to create documentation from python sources. Although doxygen claims to be suitable for python, I did not get any useful results from it (at least not out-of-the-box). I was also not satisfied with epydoc, since it fetches the documentation for all super classes, which is quite a lot for Qt derived classes. Finally, I found synopsis, which created very good results without requiring much configuration. The Debian package was orphaned, and the latest version in the Debian archive was 0.5.0 while the latest upstream version is 0.8.0, so I decided to adopt it. A preliminary package is now available at http://mentors.debian.net/debian/pool/main/s/synopsis/,
the RFS was sent and I hope to find a sponsor soon

Write once, install nowhere?

nospam@example.com (Andreas Fester) — Sun, 02 Oct 2005 22:14:19 +0200

I will never understand why people write applications in Java(TM), and then distribute it in some binary form, like .exe files for MS-Windows or .bin files for Linux/Unix. Instead of simply downloading a .zip or .tar.gz file, you have to choose the native platform you want the application to run on, and then execute some installation program like this:

$ ~/sjsas_pe-8_1_02_2005Q2-linux.bin Checking available disk space... Checking Java(TM) 2 Runtime Environment... Extracting Java(TM) 2 Runtime Environment files... ** glibc detected ** double free or corruption (!prev): 0x08077718 *** Deleting temporary files...

Really great ...

The cool thing in this specific case is that it is SUN Microsystems themselves where I downloaded the package from, to be more precise the J2EE reference implementation.

Going to look for the jar files I need somewhere else now...

Debian amd64 port

nospam@example.com (Andreas Fester) — Fri, 09 Sep 2005 18:46:00 +0200

Today I was able to try the amd64 port of Debian on an Intel Pentium D processor with EM64 technology. I dont have a broad overview of the various 64 bit technologies yet, but as far as I learned today the ia64 port is specific to the Intel Itanium processor, while the amd64 port supports both AMD64 CPUs and Intel EM64 CPUs. The current business card image booted well, but unfortunately the keyboard did not work anymore as soon as the debian installer showed its first menu. I tried both an USB and a PS/2 keyboard, but both have shown the same behaviour. Seems like there is more research necessary

qemu - a powerful processor emulator

nospam@example.com (Andreas Fester) — Sun, 07 Aug 2005 21:37:00 +0200

I recently tested qemu, an open source processor emulator. qemu runs on various host platforms and can emulate various target platforms. They also provide an accelerator module which runs as kernel module on x86 based Linux hosts and enables native instruction execution when an x86 based system emulates another x86 based system. I successfully installed Windows XP on a Linux host, and was really surprised about the performance of the emulated system! It is of course not as fast as a native installation, and especially graphics operations appear to be rather slow (which might be caused by a poor graphics card emulation), but at least I am now able to use the few MS-Windows applications which I still need.

An additional Debian package to come :-)

nospam@example.com (Andreas Fester) — Tue, 02 Aug 2005 21:52:00 +0200

I am in the progress of adopting the Debian package for lincvs, a really nice and useful GUI frontend for CVS. As a first step, I have created a package for the new upstream release 1.4.3 which is available at http://littletux.homelinux.org/debian.