#use wml::debian::template title="Debian GNU/Hurd --- Development" NOHEADER="yes" #include "$(ENGLISHDIR)/ports/hurd/menu.inc"
The Hurd-specific packages are maintained on
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 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
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
Also, check whether work has already been done on
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.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.
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-i386,
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-i386
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].
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 |