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

Debian GNU/Hurd

Development of the Distribution

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-get 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. You can add -uc to avoid signing the package with your pgp key.

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

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/graph-radial.pdf updated every day, or on the most-wanted list https://people.debian.org/~sthibault/graph-total-top.txt (this is long-term wanted, the short-term wanted is https://people.debian.org/~sthibault/graph-top.txt). It is also usually a good idea to pick from the out of date lists https://people.debian.org/~sthibault/out_of_date2.txt and https://people.debian.org/~sthibault/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/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.

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

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

Back to the Debian Project homepage.