I have recently started to use an amd64 kernel on my i386 Debian unstable system. Unfortunately, VirtualBox OSE does not work with that setup. When I try to start a virtual machine, it fails with an oblique error message:
RTR3Init failed with rc=-1912 (rc=-1912)
The VirtualBox kernel modules do not fit to this version of VirtualBox. The installation of VirtualBox was apparently not successful. Executing
should fix that problem. Make sure that you don’t mix the OSE version and the PUEL version of VirtualBox.
Debian bug #456391 explains the problem. In that report Michael Meskes alludes to running VirtualBox in an amd64 chroot jail, so I tried this myself. It works flawlessly, once I got it setup. Here is what I did (as root):
robinson:~# mkdir /srv/amd64
robinson:~# cdebootstrap --arch amd64 sid /srv/amd64 http://ftp.debian.org/debian/
robinson:~# chroot /srv/amd64
robinson:/# apt-get update
robinson:/# apt-get upgrade
robinson:/# apt-get install virtualbox-ose # add more packages here if needed
robinson:/# adduser --uid 1000 --no-create-home --disabled-password --disabled-login srittau
These commands install the base system and create a user account. Now I created a script called
if test ! -e $CHROOT/dev/.udev; then
mount -t none /dev $CHROOT/dev/ -o bind
if test `ls $CHROOT/proc | wc -l` = "0"; then
mount -t proc none $CHROOT/proc
if test `ls $CHROOT/sys | wc -l` = "0"; then
mount -t sysfs none $CHROOT/sys
if test `ls $CHROOT/home | wc -l` = "0"; then
mount --bind /home $CHROOT/home
chroot $CHROOT sh -c "su - srittau"
sudo amd64.sh will now enter the chroot environment as user srittau where I can start virtualbox normally.
Today I discovered on Debian’s Package Tracking System that Ubuntu has patched my Netatalk package. The patch seems to be rather useful (start cnid_metad in init if the user requests it). I just wonder why it was never submitted directly to me. Isn’t it easier just to take the upstream message than to (re-)sync every time I release a new version?
Below are relevant comments from my old blog system:
I just released Netatalk 2.0.3-2. This version solved the conflict with yudit by renaming /usr/bin/uniconv to /usr/sbin/netatalk-uniconv. As this is a tool that is only required very occasionally (i.e. when updating a volume from one character set to unicode, which hopefully you will only have to do once per volume), this change should be fairly unobstrusive.
Resolving the conflict with bigloo is more bothersome. Bigloo also contains a binary called afile, just like Netatalk. But since this is a tool that is possibly used regularily by some users and may even be used in scripts, I fear that simply renaming it may break things. I think I will just try to rename afile (and a few other similar commands) to apple_file, add a note to NEWS.Debian, and upload this to unstable. If too many users complain, I will probably use a transitional strategy: Rename the tools, add the note to README.Debian, but leave symlinks hanging around until after the release with etch. This would mean that the conflict with bigloo can’t be resolved until then.
Other opinions or suggestions on that matter are welcome.
Uploaded a new version of ORBit2 that fixes bug #317352. It seems that at some point ORBit2 stopped building the API documentation by default, so it wasn’t included in liborbit2-dev anymore. Fixed that by providing the –enable-gtk-doc configure option. But then the API documentation is in a really bad state.
Also noticed that the linc-cleanup-sockets utility program hardcodes /tmp. Added a simple patch to GNOME bug #149394 that fixes this problem and commited it after I got Michael Meeks’ permission. This fix isn’t in the Debian package yet, though.
Yesterday saw a new Netatalk package (2.0.2-2), since I forgot to include heimdal-dev in the build dependencies. Today another fix is needed (2.0.2-3), since it doesn’t build on amd64. I don’t expect this to be the last build failure. Let’s wait and see …
Of course I would prefer to check in the build fixes into upstream CVS, but due to my current problems with Sourceforge CVS I can’t.
When I was recently combing through new packages in aptitude, I came across a package named svn-workbench. Since I am a fan of Subversion the name got me interested. The package’s short description (“A Workbench for Subversion “) didn’t help much. So I went to the long description, which I will quote here in full:
pysvn-workbench is a workbench for subversion, written in the Python language.
Not very helpful either. So I decided to write a bug report to ask the maintainer to improve the full description to be actually useful. When I looked at the existing bug reports for svn-workbench, I saw that somebody else had already posted this problem as bug 299175.
Please take a moment to read the bug report. The original reporter pointed out clearly what the problem with the current description is. This was backed by another user who also pointed out that the Developer’s Reference recommends to include the upstream home page in the long description.
The maintainer’s response to the long description problem was simply: “send a patch”. Sorry, as a maintainer you can’t require users of your package to do your work, especially not if it’s a fundamental task as this. If you can’t even be bothered to write a short and concise description of your package, how can we assume that the rest of the package is not in the same miserable state? What does a lapidary comment such as this tell our users? In this case the seconds reporter was also Debian developer, but what if a normal user comes across this bug report? Also, why is the submitter expected to write a description of a software he doesn’t even know? If he knew he surely wouldn’t ask what the software does, would he?
Another point is the maintainer’s answer to the request to put the homepage in the description: “no, there’s one file where it belongs: debian/copyright. Adding it to several places is just a maintainance burden.” While I agree that the Developer’s Reference is not the Policy, it should not be lightly ignored. We want to have a consistent system, where users know what to expect. Also, normally there is a reason for the recommendations in the Developer’s Reference. In this case the long description should include the home page address so that users can view more information about the package before installing it. To refuse to include it in the long description for the increased “maintainance[sic!] burden” is just a weak excuse.
Our users have earned a better treatment, doko!
So, I finally found time to do Debian work again after a far too long abstinence. Unfortunately I didn’t manage to hand over my Debian stuff gracefully, but fortunately there were people having an eye on them. Jonas Smedegaard had an eye on the Netatalk package and released a security fix for it. The GNOME team, headed by Sebastien Bacher was taking care of ORBit.
The first thing I did was to hotfix some of my packages. Get out a new ORBit release and release a first version of Netatalk 2, a much requested upgrade. This new Netatalk version has many improvements and it’s good to finally have it in Debian, though there is still much work to do. Soon after releasing netatalk-2.0.2-1 I got a bug report concerning CJK support. This is something that needs to go in ASAP, but currently I don’t have the knowledge to review and apply the referenced patch. I’m out of the loop of Netatalk programming as well.
So, let’s have a look at my packages:
- This is currently seriously broken and badly needs a port to GNOME 2. AFAIR there is some unfinished work in GNOME CVS, which I have to look into. But at the moment this package is not high priority.
- Another GNOME 1 package. Before my hiatus I started to rewrite this package for GNOME 2 and there were grand plans for it. These plans are still there and I have continued the port. I hope to have a working pre-release of the new GNOME 2 package out soon, though there’s still lot of work to do, before this can be uploaded to Debian unstable.
- While I’m still listed as maintainer, I handed this package over to Loic Minier a few weeks back, and it seems to be in good hands.
- Base package for ORBit 2. Just updated from 0.8.3-1 to 0.8.5-1,
though the upstream changes were only very minor. No open bugs, this package seems to do fine.
- Base package for ORBit 1. Obsolete, see below.
- As I wrote above I just upgrade this to Netatalk 2.0. While this
was quite a major change (I got rid of the unnecessary netatalk-dev package in the process), I don’t forsee any major problems. The upstream package is quite well tested at this point and included in many other distributions. But you never know …
- ORBit 1 is an old, obsolete package from GNOME 1 days. It has a
few open bugs, but probably nothing that is worth fixing. Instead my energies should be focussed on porting all stuff that still depends on it over to GNOME 2 (see also above).
- Just upgraded to upstream version 2.12.2. This is a fairly stable,
slowly developed piece of software. Only one open bug in the Debian BTS and that is a wishlist item. This package is also doing fine and needs minimal maintenance.
Now I have to get up to snuff at what’s up with Debian. I completely missed the DPL elections and so I will not vote, since I have not enough information about what’s currently going on. Then there was the interesting proposal about dropping stable support for less-used architectures after sarge. Oh yes, speaking about sarge. It’s still not released. But then I didn’t have high hopes that it would be …