[ Ports ] [ Debian GNU/Hurd ] [ News ] [ Installation ] [ Hurd CDs ] [ Documentation ] [ Development ] [ Contact ]

Debian GNU/Hurd

Development of the Distribution

Boot Disks

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>". Instead -B you can use -b if you also want to build the architecture independent parts of the package. You can use -rfakeroot instead -rsudo if you use the fakeroot package. You can do without the -r if you build as user root. You can add -uc to avoid signing the package with your pgp key.

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 either pick one of the missing packages at random, or watch out for information about the autobuilding process on the debian-hurd mailing list.

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 fsysopts to adjust the --sync option. You can set different sync intervals for each file system! To do this manually, use the syncfs utility.
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/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 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/ppp and 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.

General Porting Issues

Here is a list of common incompatibilities you may encounter when compiling insufficient portable software on the Hurd.

Bad File Descriptor
If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the open() invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use O_RDONLY, O_WRONLY or O_RDWR. This bug was observed in the fortunes and mtools packages for example.
PATH_MAX
Every unconditionalized use of PATH_MAX is a POSIX incompatibility. If there is no upper limit on the length of a path, this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use sysconf() to query the length at runtime. If sysconf() returns -1, you have to use realloc() to allocate the needed memory dynamically.
MAXHOSTNAMELEN
see PATH_MAX
MAXPATHLEN
see PATH_MAX
NOFILE
see PATH_MAX
Hurd specific #define
If you need to include specific code for the Hurd using #if...#endif, then you can use the __GNU__ symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution.
sys_errlist[] vs. strerror()
If a program has only support for sys_errlist[] you will have to do some work to make it compile on the Hurd, which has dropped support for it and does only provide strerror(). Steinar Hamre writes about strerror():
strerror() should be used because:
- It is the modern, POSIX way.
- It is localized.
- It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk)
strerror() should always be used if it is available. Unfortunately there are still some old non-POSIX systems that do not have strerror(), only sys_errlist[].

Today, only supporting strerror() is far better than only supporting sys_errlist[]. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need:

AC_CHECK_FUNCS(strerror)

To config.h.in, you need to add:

#undef HAVE_STRERROR

Then something like:
```
        #ifndef HAVE_STRERROR
        static char *
        private_strerror (errnum)
             int errnum;
        {
          extern char *sys_errlist[];
          extern int sys_nerr;

          if (errnum > 0 && errnum <= sys_nerr)
            return sys_errlist[errnum];
          return "Unknown system error";
        }
        #define strerror private_strerror
        #endif /* HAVE_STRERROR */
```
You can for example look in the latest fileutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working sys_errlist[].
Filenames ending in a slash `/'
Those are evil if they don't exist and you want to name a directory this way. For example, mkdir foobar/ will not work under the Hurd. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine.