Patch Life Cycle


Follow the steps listed on the package porting page.


Send the patch for review to
Before sending the patch, make sure that you've solved all the known problems listed in the package porting general introduction and the porting guide for dummies.

Submit Draft

When the patch is good enough, you can write the draft of the official bug report.
This draft should first be sent for review to with the patch attached.

Here is an example for memstat:

Source: memstat
Version: 0.9
Severity: important
Tags: patch
Usertags: hurd


This patch solves the build problems for GNU/Hurd due to PATH_MAX
issues. The solution is to make dynamic string allocations instead of
using fixed length buffers. The patch involves one file, and is
trivial. Parts of the code have been reviewed by GNU/Hurd developers
and Debian GNU/Hurd developers and maintainers.

Is it really useful to check if BUFSIZ is defined?

Should the "whole package" be tested with valgrind on GNU/Linux?!
If yes, is there a standard procedure to do it?!

Special thanks to Jérémie and Richard for their comments!

(Not submitted yet, comments are welcome.)

Once it's been approved, you can proceed to the submission.


The bug report is the same as above, with all the FIXME, TODO and final comment removed.
Attach the patch and send it to
Convention for the e-mail subject: memstat: FTBFS on hurd-i386
Convention for the attachment name is: fix_FTBFS4Hurd.patch


Once the patch has been accepted, update your patch page!