Tag: Debian

Categories
Debian

VirtualBox on i386 with amd64 Kernel

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

‘/etc/init.d/vboxdrv setup’

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
[...]
robinson:/#

These commands install the base system and create a user account. Now I created a script called /usr/local/bin/amd64.sh:

#!/bin/sh

CHROOT=/srv/amd64

if test ! -e $CHROOT/dev/.udev; then
    mount -t none /dev $CHROOT/dev/ -o bind
fi
if test `ls $CHROOT/proc | wc -l` = "0"; then
    mount -t proc none $CHROOT/proc
fi
if test `ls $CHROOT/sys | wc -l` = "0"; then
    mount -t sysfs none $CHROOT/sys
fi
if test `ls $CHROOT/home | wc -l` = "0"; then
    mount --bind /home $CHROOT/home
fi
chroot $CHROOT sh -c "su - srittau"

Running sudo amd64.sh will now enter the chroot environment as user srittau where I can start virtualbox normally.

Categories
Debian

Ubuntu (Non-)Collaboration

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:

Ubuntu mass-submits patches

by Sami Dalouche

Hi,

I’m not 100% sure, but I think that Ubuntu massively sends patches when a new version is released…

Any confirmation ?

Not as far as I know

by Chris Cunningham

Canonical specifically request that work is sent upstream because it reduces the workload for their employees. Launchpad is meant to make this a straightforward process. I’m sure it wasn’t malicious, although you could always find out by asking directly.

– Chris

“Ubuntu” as an entity.

by Jeff Bailey

Sebastien,

Remember that “Ubuntu” isn’t an entity, it’s a project of people – some of whom work for Canonical.

Canonical employees (of which I am one) are expected to submit fixes that we do to packages back to Debian. Others who work on Ubuntu (community volunteers, people paid by companies other than Canonical) are requested to do so, but are not forced.

“netatalk” is in universe, which is a section of the distribution worked on pretty much entirely by community members.

I hope that helps! Feel free to email me if you have specific questions.

Tks,

Jeff Bailey

by Zak B. Elep

Hi jroger! 🙂

I was the last one to merge in the previous Ubuntu changes to your package. It (the patch) was already in Breezy courtesy of Ante Karamatic (ivoks), and I remerged it again to your last two versions of netatalk.

I was intending to inform you the soonest about this change, but my school (and non-Ubuntu) work has been my concern in the past few weeks, and, as I see that the PTS already has a link to Scott’s patch repository, I felt that I should leave it to you whether to merge in the changes or not, since it is your prerogative to do so, being netatalk’s maintainer.

Perhaps a better improvement for the PTS interacting with the Ubuntu archive would be automatic notification when Ubuntu changes are committed. I myself would like this, since I maintain/adopt some Debian packages myself, and it would be a great convenience for me if someone else looks at my package(s) in Ubuntu and makes changes without having to contact me first.

I hope that helps 🙂 If you have some questions, just look for me on freenode 🙂

Cheers,

Zakame

by Sebastian Rittau

Thanks to everybody who has responded. I am aware that Ubuntu consists of many maintainers, and not all are working for Canonical. I would really like some automatic system that forwards (new) Ubuntu patches to Debian maintainers. The integration of Scott’s repository into the PTS is a great first step. I just probably just check the PTS more often. 🙂 

Categories
Life

Blonde Joke

Normally, I don’t like blonde jokes, but this one is really good! Oh and: Happy New Year!

But the really funny thing about this is that I stumbled across it on Planet Debian, a computer-related RSS aggregator. And while following the links, I came across The Ferret’s blog. Ferret is a well-known employee of the Magic web site and store StarCityGames. Small world indeed.

Categories
Debian Netatalk

Netatalk 2.0.3-2

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.

Categories
Debian Netatalk

New Netatalk Packages

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.

Categories
Debian

Maintainer Responsibilities and Arrogance

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!

Categories
Debian

I’m back to Debian

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:

gnome-chess
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.
gnome-pim
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.
gtk-doc
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.
libidl
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.
linc
Base package for ORBit 1. Obsolete, see below.
netatalk
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
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).
orbit2
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 …