path: root/english/ports/hurd/hurd-devel-debian.wml

#use wml::debian::template title="Debian GNU/Hurd --- Development" NOHEADER="yes"
#include "$(ENGLISHDIR)/ports/hurd/menu.inc"

<h1>
Debian GNU/Hurd</h1>
<h2>
Development of the Distribution</h2>

<h3>
Packaging Hurd software</h3>
<p>
The Hurd-specific packages are maintained on <url "https://salsa.debian.org/hurd-team/">.
</p>

<h3>
Porting Debian Packages</h3>
<p>
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 <a
href="$(HOME)/devel/">Developer's Corner</a> you should know how to
extract Debian source packages and build a Debian package. Here is a
crash course for the very lazy people:</p>

<h3>
Obtaining Source and Building Packages</h3>

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

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

<p>
Building a package is done in the now existing Debian build directory
<code>package-version</code> with the command
<code>dpkg-buildpackage -B "-mMyName &lt;MyEmail&gt;"</code>.
Instead <code>-B</code> you can use
<code>-b</code> 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
<code>-uc</code> to avoid signing the package with your pgp key.</p>

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

<p>
Using pbuilder can be convenient. It can be built with
<code>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</code>
and then one can use <code>pdebuild -- --binary-arch</code> which will handle downloading build dependencies, etc, and put the result in <code>/var/cache/pbuilder/result</code>
</p>

<h3>
Pick One</h3>
<p>
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
<url "https://people.debian.org/~sthibault/graph-radial.pdf"> updated every day,
or on the most-wanted list
<url "https://people.debian.org/~sthibault/graph-total-top.txt"> (this is
long-term wanted, the short-term wanted is
<url "https://people.debian.org/~sthibault/graph-top.txt">).
It is also usually a good idea to pick from the out of date lists
<url "https://people.debian.org/~sthibault/out_of_date2.txt"> and
<url "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
<url "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.
</p>
<p>
Also, check whether work has already been done on
<url "https://alioth.debian.org/tracker/?atid=410472&amp;group_id=30628&amp;func=browse">,
<url "https://alioth.debian.org/tracker/?atid=411594&amp;group_id=30628&amp;func=browse">,
and the BTS (<url "https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd">), and <url "https://wiki.debian.org/Debian_GNU/Hurd">,
and the live state of packages on buildd.debian.org, e.g.
<url "https://buildd.debian.org/util-linux">.
</p>

<h4>
Packages That Won't Be Ported</h4>
<p>
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.
</p>

<ul>
<li>
<code>base/makedev</code>, because the Hurd comes with its own version
of this script. The Debian source package only contains a Linux
specific version.</li>
<li>
<code>base/modconf</code> and <code>base/modutils</code>, because
modules are a concept specific to Linux.</li>
<li>
<code>base/netbase</code>, because the remaining stuff that is there
is highly specific to the Linux kernel. The Hurd uses
<code>inetutils</code> instead.</li>
<li>
<code>base/pcmcia-cs</code>, because this package is Linux specific.</li>
<li>
<code>base/setserial</code>, 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.</li>
</ul>

<h3> <a name="porting_issues">
General Porting Issues</a></h3>
<p>
<a href=https://www.gnu.org/software/hurd/hurd/porting/guidelines.html>A list of
common issues</a> is available on the upstream website. The following common
issues are specific to Debian.</p>
<p>Before attempting to fix something, check whether the kfreebsd* port maybe
has some fix already, which just needs to be extended to hurd-i386.</p>

<ul>
<li>
<code>foo : Depends: foo-data (= 1.2.3-1) but it is not going to be installed</code>
<p>
The short answer is: package <code>foo</code> failed to build on hurd-i386,
and that needs to be fixed, look at the build failure on its buildd.debian.org
status page.
</p>
<p>
This typically happens when package <code>foo</code> currently fails to build,
but used to build fine before. Use <code>apt-cache policy foo foo-data</code>
to see that for instance version <code>1.2.3-1</code> of <code>foo</code> is
available, and a newer <code>foo-data</code> version <code>2.0-1</code> 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 <code>foo</code> source package (which builds the <code>foo</code>
and <code>foo-data</code> binary packages) is uploaded, the newer arch:all
<code>foo-data</code> package gets installed, even if the newer hurd-i386
<code>foo</code> 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.
</p>

</li>
<li>
<code>some symbols or patterns disappeared in the symbols file</code>
<p>
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
<code>.symbols</code> file, for instance:
</p>

<table><tr><td>&nbsp;</td><td class=example><pre>
 (arch=linux-any)linuxish_function@Base 1.23
</pre></td></tr></table>

</li>
<li>
<code>Broken libc6 dependency</code>
<p>
Some packages use an erroneous dependency on <code>libc6-dev</code>. This
is incorrect because <code>libc6</code> is specific to some architectures
of GNU/Linux. The corresponding package for GNU is <code>libc0.3-dev</code>
but other OSes will have different ones. You can locate the problem in the
<code>debian/control</code> file of the source tree. Typical solutions include
detecting the OS using <code>dpkg-architecture</code> and hardcoding the
soname, or better, use a logical OR. eg: 
<code>libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev</code>.
The <code>libc-dev</code> is a
virtual package that works for any soname but you have to put it only as the
last option.</p></li>
<li>
<code>undefined reference to snd_*, SND_* undeclared</code>
<p>
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.
</p>
<p>
If the package permits it, alsa support should be disabled on the
<code>!linux-any</code> archs (e.g. through a <code>configure</code>
option), and a <code>[linux-any]</code> qualifier added to the
alsa <code>Build-Depends</code>, and the converse added to
<code>Build-Conflicts</code>, such as 
<code>Build-Conflicts: libasound2-dev [!linux-any]</code>.
</p>
</li>
<li>
<code>dh_install: Cannot find (any matches for) "foo" (tried in ., debian/tmp)</code>
<p>
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 <tt>dh-exec</tt>,
<tt>chmod +x</tt> the <tt>.install</tt> file, and prepend the problematic lines
with e.g. <tt>[linux-any]</tt> or <tt>[!hurd-any]</tt>.
</p>
</li>
</ul>

<h3> <a name="debian_installer">
Hacking with the Debian installer</a></h3>

<p>
To build an ISO image, the simplest is to start from an existing one from <a href=hurd-cd>the Hurd CD images page</a>. You can then mount it and copy it:
</p>

<table><tr><td>&nbsp;</td><td class=example><pre>
mount debian-sid-hurd-i386-NETINST-1.iso /mnt
cp -a /mnt /tmp/myimage
umount /mnt
chmod -R +w /tmp/myimage
</pre></td></tr></table>

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

<table><tr><td>&nbsp;</td><td class=example><pre>
gunzip /tmp/myimage/initrd.gz
mount /tmp/myimage/initrd /mnt
cp ~/hurd/rumpdisk/rumpdisk /mnt/hurd/
umount /mnt
gzip /tmp/myimage/initrd
</pre></td></tr></table>

<p>
Now you can rebuild the iso with grub-mkrescue:
</p>

<table><tr><td>&nbsp;</td><td class=example><pre>
rm -fr /tmp/myimage/boot/grub/i386-pc
grub-mkrescue -o /tmp/myimage.iso /tmp/myimage
</pre></td></tr></table>

</li>
</ul>