Ports / Debian GNU/Hurd / Debian GNU/Hurd --- Development

Debian GNU/Hurd

Development of the Distribution

Packaging Hurd software

The Hurd-specific packages are maintained on https://salsa.debian.org/hurd-team/.

Porting Debian Packages

If you want to help the Debian GNU/Hurd port, you should make yourself familiar with the Debian packaging system. Once you have done this by reading the available documentation and visiting the Developer's Corner you should know how to extract Debian source packages and build a Debian package. Here is a crash course for the very lazy people:

Obtaining Source and Building Packages

Obtaining Source code can be done by simply running apt source package, which will also extract the source.

Extracting a Debian source package requires the file package_version.dsc and the files listed in it. You build the Debian build directory with the command dpkg-source -x package_version.dsc

Building a package is done in the now existing Debian build directory package-version with the command dpkg-buildpackage -B "-mMyName <MyEmail>". Instead -B you can use -b if you also want to build the architecture independent parts of the package (but that is usually useless since they are already available in the archive, and building them may require additional dependencies). You can add -uc to avoid signing the package with your OpenPGP key.

Building may needed additional installed packages. The simplest way it to run apt build-dep package which will install all required packages.

Using pbuilder can be convenient. It can be built with sudo pbuilder create --mirror http://deb.debian.org/debian-ports/ --debootstrapopts --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --debootstrapopts --extra-suites=unreleased --extrapackages debian-ports-archive-keyring and then one can use pdebuild -- --binary-arch which will handle downloading build dependencies, etc, and put the result in /var/cache/pbuilder/result

Pick One

Which package needs to be worked on? Well, every package that is not yet ported, but needs to be ported. This changes constantly, so it's preferred to concentrate first on packages with a lot of reverse dependencies, which can be seen in the package dependency graph https://people.debian.org/~sthibault/hurd-i386/graph-radial.pdf updated every day, or on the most-wanted list https://people.debian.org/~sthibault/hurd-i386/graph-total-top.txt (this is long-term wanted, the short-term wanted is https://people.debian.org/~sthibault/hurd-i386/graph-top.txt). It is also usually a good idea to pick from the out of date lists https://people.debian.org/~sthibault/hurd-i386/out_of_date2.txt and https://people.debian.org/~sthibault/hurd-i386/out_of_date.txt, as these used to be working, and are now broken probably only for just a couple of reasons. You can also just pick one of the missing packages at random, or watch out for autobuilding logs on the debian-hurd-build-logs mailing list, or use the wanna-build list from https://people.debian.org/~sthibault/hurd-i386/failed_packages.txt . Some build issues are easier to fix than the others. Typically, "undefined reference to foo", where foo is something like pthread_create, dlopen, cos, ... (which are obviously available on hurd-i386), which just shows that the configure step of the package forgot to include -lpthread, -ldl, -lm, etc. on the Hurd too. Note however that ALSA MIDI functions are not available.

Also, check whether work has already been done on https://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse, https://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse, and the BTS (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd), and https://wiki.debian.org/Debian_GNU/Hurd, and the live state of packages on buildd.debian.org, e.g. https://buildd.debian.org/util-linux.

It's better to push the porting fix to upstream itself, since that's where it will have to land eventually ; better discuss directly with them rather than via the Debian maintainer of the Debian package. We can easily apply the fix as an upload to Debian's unreleased suite while waiting for the patch to be released by upstream and land in Debian.

Packages That Won't Be Ported

Some of these packages, or parts of them, might be portable later, but currently they are considered to be unportable at least. They are normally marked as NotForUs in the buildd database.

• base/makedev, because the Hurd comes with its own version of this script. The Debian source package only contains a Linux specific version.
• base/modconf and base/modutils, because modules are a concept specific to Linux.
• base/netbase, because the remaining stuff that is there is highly specific to the Linux kernel. The Hurd uses inetutils instead.
• base/pcmcia-cs, because this package is Linux specific.
• base/setserial, because it is specific to the Linux kernel. However, with the port of Linux char drivers to GNU Mach, we might be able to use it.

General Porting Issues

A list of common issues is available on the upstream website. The following common issues are specific to Debian.

Before attempting to fix something, check whether the kfreebsd* port maybe has some fix already, which just needs to be extended to hurd-any.

• foo : Depends: foo-data (= 1.2.3-1) but it is not going to be installed

  The short answer is: package foo failed to build on hurd-any, and that needs to be fixed, look at the build failure on its buildd.debian.org status page.

  This typically happens when package foo currently fails to build, but used to build fine before. Use apt-cache policy foo foo-data to see that for instance version 1.2.3-1 of foo is available, and a newer foo-data version 2.0-1 is available. This is because on debian-ports, architecture-independent (arch:all) packages are shared among all architectures, and thus when a newer version of the foo source package (which builds the foo and foo-data binary packages) is uploaded, the newer arch:all foo-data package gets installed, even if the newer hurd-any foo binary package cannot be built, thus leading to incompatible versions. Fixing that requires making the debian-ports archive use dak instead of mini-dak, which is still ongoing work.

• some symbols or patterns disappeared in the symbols file

  Some packages maintain a list of the symbols that are expected to appear in libraries. This list is however usually obtained on a Linux system, and thus include symbols which may not make sense on non-Linux systems (e.g. due a Linux-only feature). One can however introduce conditionals in the .symbols file, for instance:

  (arch=linux-any)linuxish_function@Base 1.23

• Broken libc6 dependency

  Some packages use an erroneous dependency on libc6-dev. This is incorrect because libc6 is specific to some architectures of GNU/Linux. The corresponding package for GNU is libc0.3-dev but other OSes will have different ones. You can locate the problem in the debian/control file of the source tree. Typical solutions include detecting the OS using dpkg-architecture and hardcoding the soname, or better, use a logical OR. eg: libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev. The libc-dev is a virtual package that works for any soname but you have to put it only as the last option.

• undefined reference to snd_*, SND_* undeclared

  Some packages use ALSA even on non-Linux architectures. The oss-libsalsa package provides some emulation over OSS, but it is limited to 1.0.5, and some features are not provided, such as all sequencer operations.

  If the package permits it, alsa support should be disabled on the !linux-any archs (e.g. through a configure option), and a [linux-any] qualifier added to the alsa Build-Depends, and the converse added to Build-Conflicts, such as Build-Conflicts: libasound2-dev [!linux-any].

• dh_install: Cannot find (any matches for) "foo" (tried in ., debian/tmp)

  That typically happens when upstream didn't install something because it didn't recognize the OS. Sometimes it's just dumb (e.g. it doesn't know that building a shared library on GNU/Hurd is exactly like on GNU/Linux) and that needs fixing. Sometimes it actually makes sense (e.g. not installing systemd service files). In that case, one can use dh-exec: build depend on dh-exec, chmod +x the .install file, and prepend the problematic lines with e.g. [linux-any] or [!hurd-any].

Hacking with the Debian installer

To build an ISO image, the simplest is to start from an existing one from the Hurd CD images page. You can then mount it and copy it:

mount debian-sid-hurd-i386-NETINST-1.iso /mnt
cp -a /mnt /tmp/myimage
umount /mnt
chmod -R +w /tmp/myimage

You can mount the initial ram disk, and e.g. replace a translator with your own version:

gunzip /tmp/myimage/initrd.gz
mount /tmp/myimage/initrd /mnt
cp ~/hurd/rumpdisk/rumpdisk /mnt/hurd/
umount /mnt
gzip /tmp/myimage/initrd

Now you can rebuild the iso with grub-mkrescue:

rm -fr /tmp/myimage/boot/grub/i386-pc
grub-mkrescue -o /tmp/myimage.iso /tmp/myimage

Back to the Debian Project homepage.