• ... 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

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

I was informed some time ago that my starting page is not XHTML 1.0 compliant, as it claimed on the bottom. Of course, this is not because I dont know how to use a validator ;-) Instead I blame the serendipity blog software for messing up my otherwise valid XHTML 1.0 pages. It basically happened when I inserted a list into one of the articles. I put each <li> </li> on its own line, which let serendepity insert a <br /> after each </li> tag. This is not allowed and caused the page to be not valid XHTML anymore.

Lets see if it is possible to let serendepity check the page somehow after it has been saved, so that I will at least see if new articles are valid.

[UPDATE]

There is a HTML validator already shipped with serendipity. It takes the blog entry, sends it to validator.w3.org and parses the result. I installed it in my sandbox, but it does not work: the reply from validator.w3.org is a 302 moved temporarily.

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!