diff options
Diffstat (limited to 'hurd/running/debian/patch_submission.mdwn')
| -rw-r--r-- | hurd/running/debian/patch_submission.mdwn | 66 |
1 files changed, 0 insertions, 66 deletions
diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn deleted file mode 100644 index 1dd8a4db..00000000 --- a/hurd/running/debian/patch_submission.mdwn +++ /dev/null @@ -1,66 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2011 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*): - - 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|mailing_lists/debian-hurd]] 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-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. |