Development of the Distribution
Currently, we do not work on native boot disks. We are laying out some of the necessary foundations for that, though, and sometimes port individual necessary packages for that. If you want to help, work on the debian-installer project and make sure its components run on the Hurd.
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
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 -rsudo "-mMyName <MyEmail>".
-B you can use
-b if you also want to build the architecture independent
parts of the package. You can use
-rsudo if you use the fakeroot package. You can do
-r if you build as user root. You can add
-uc to avoid signing the package with your pgp key.
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 http://people.debian.org/~sthibault/graph-radial.pdf updated every day, or on the most-wanted list http://people.debian.org/~sthibault/graph-total-top.txt (this is long-term wanted, the short-term wanted is http://people.debian.org/~sthibault/graph-top.txt). It is also usually a good idea to pick from the out of date list http://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 http://people.debian.org/~sthibault/failed_packages.txt.gz .
Also, check whether work has already been done on http://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse, http://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse, and the BTS (http://firstname.lastname@example.org;tag=hurd), and http://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.
base/update, because the Hurd does not need an update daemon (the filesystems sync themselves). To change to sync interval, you can use
fsysoptsto adjust the
--syncoption. You can set different sync intervals for each file system! To do this manually, use the
base/makedev, because the Hurd comes with its own version of this script. The Debian source package only contains a Linux specific version.
base/ld.so, because the Hurd does use the linker that ships with the GNU C library.
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
base/pcmcia-cs, because the Hurd does not have any PCMCIA support (and even if it had, this package is probably Linux specific).
base/procps, because this code is specific to the Linux proc filesystem.
base/pppconfig, because the Hurd does not have any PPP support (and even if it had, this package is probably 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.
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
libc6is specific to some architectures of GNU/Linux. The corresponding package for GNU is
libc0.3-devbut other OSes will have different ones. You can locate the problem in the
debian/controlfile of the source tree. Typical solutions include detecting the OS using
dpkg-architectureand 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-devis 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-anyarchs (e.g. through a
configureoption), 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].