1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]
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](http://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse).
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*):
* `Severity: important` -- not *serious*.
* `Version: VERSION` -- the version of the source package in unstable.
* `Tags: patch` -- as/if you include a ready-to-be-applied patch.
* `User: debian-hurd@lists.debian.org`
* `Usertags: hurd`
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-ports.org/build.php> 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.
|
