GNU Hurd/ hurd/ running/ debian/ patch submission

Welcome to... ... the GNU Hurd!

If you fixed a Debian package which FTBFS (fails to build from source), you should submit the patch so that all users can profit from your work.

If it is not a Debian-specific patch, you should strongly consider submitting the patch upstream for inclusion. This applies even more so if it is a GNU package, or otherwise frequently used package, or you know upstream anyway.

If you had to change the code considerably and are not 100% sure you did not introduce a regression, or are not very experienced with these kinds of code changes, you should first submit your patch for review to the Debian alioth patch tracker.

If the patch is trivial, or one of the Debian porters approved your patch for submission, submit the patch to the Debian BTS (bug tracking system). You can either use the reportbug tool, or just simple mail. In any case, you should follow these guidelines:

  • The submission address is submit@bugs.debian.org.

  • The mail's subject (which will become the bug's title) should be SOURCE-PACKAGE: FTBFS on hurd-i386: REASON.

  • The first lines of the mail's body (the so-called pseudo-header):

    Package: PACKAGE
Severity: important -- not *serious*
Version: VERSION -- the version of the source package in unstable.
Tags: patch -- if you include a ready-to-be-applied patch.
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

The last three lines are used to to change the current User to the specified value (the default is the email sender/from address), specify Usertags to add the specified tags for the current user, and X-Debbugs-CC so that the mailing list knows about your report.

In the bug description, mention that the package fails to build on hurd-i386 and (if possible) quote the failure. If possible, point to the failing build log from http://buildd.debian.org/ or elsewhere.

Then, explain the failure (Debian maintainers usually do not know much about Hurd-specific failures), and attach the patch.

The patch should be in unidiff form.

If the package uses a patch system, it is preferable to submit the patch in a ready-to-use form (e.g. as a dpatch), but this is not required. Also, try to keep the patch small, e.g., do not submit a 100 KiB autotools diff for a one-line change in configure.in or a Makefile.am, but in this case mention that autotools need to be rerun and let the maintainer choose (you can suggest you would file a complete diff if the maintainer prefers).

Last but not least, try to be courteous.