The Packaging Guides on this wiki are no longer being actively maintained. The information here is being ported to a new guide. You can file bugs and help to write it by visiting the guide's Launchpad project.

Seeking Sponsorship

If you have made a change to the package and you do not have rights to upload the package then you will need to seek a sponsor.

Note that most sponsorship is still done via debdiffs, and some sponsors will prefer that, so you may wish to attach a diff to the bug as well.

1 - Linking to bugs

You will need a bug report to seek sponsorship you should close this issue from your debian/changelog. Fill in the changelog entry by running dch -i and add the LP: #12345 entry as normal. For example:

seccure (0.0+svn44-2ubuntu1) natty; urgency=low

  * debian/control: Set XS-Python-Version for compatibility >= 2.5 (LP: #12345)

 -- Barry Warsaw <>  Mon, 04 Jan 2010 15:33:52 -0500

As of Intrepid, the best way to commit this is to put the bug number in the changelog, and use debcommit. This will issue the correct bzr command, linking it to the Launchpad bug you've specified. Make sure to use text of the form "LP: #12345, #12346"; if you leave out the space or the # then debcommit will not detect it. You can use debcommit -n to check what it's going to do.

Now, when you push the branch to launchpad it will link the branch and the bug report.

It is not critical to have a link to a bug for every change you make, but if you are fixing reported bugs then linking to them will be useful.

2 - Pushing to Launchpad

Now you should push the branch to launchpad so that it can be retrieved by others. You do this by pushing it to a branch under your user (since you won't have permission to push it back to the original branch location):

$ bzr push lp:~james-w/ubuntu/natty/seccure/seccure-fix-12345

where you change "james-w" for your launchpad username, and "natty" for the release that you are targetting. Note that the only element of the branch location that is arbitrary is the final element ("seccure-fix-12345"). Although it can take any value, please try to ensure that it is meaningful. See ../GettingTheSource for further details.

If you linked a commit to a bug number using debcommit then this will show up on the bug page as having a possible fix for the bug.

However, pushing the branch alone usually isn't enough to get Ubuntu developers to review your change. You should next propose a merge so that the developers can find your fix and review it.

To do this run:

$ bzr lp-propose

If that fails, then you can use

$ xdg-open

where most of the URL matches what you used for "push". Then you can use the link "Propose for merging into another branch", and then type in an explanation of your change in the "Initial Comment" box. Lastly click "Propose Merge" in order to complete the process.

Note that if you had to get a branch for a particular user/team (see the example on ../GettingTheSource), you will need to push to a branch named like that in the example above, but you will need to change the "target branch" when you propose to match the original branch you retrieved.

3 - Generating a debdiff

As noted in the beginning most of the sponsors still prefer sponsoring debdiff attached to bug reports.

One way is to run the following command from your branch.

$ bzr diff -rbranch:../seccure

Another way is to run the following command from your branch.

$ bzr diff -r-2..-1 > ../my-super-awesome.debdiff

Another way is to is to open the merge proposal and download the diff.

You should ensure that diff has the changes you expect, no more and no less.

Name the diff appropriately e.g. seccure-fix-12345.debdiff and attach it to the bug report.

4 - Dealing with feedback from sponsors

If a sponsor reviews your change and asks you to change something then you can do this fairly easily. Simply go to the branch that you were working in before and make the changes requested, and then commit.

$ bzr commit

Now you can push your changes up to launchpad as before, but bzr will have remembered where you pushed to, so you can simply run

$ bzr push

Then you can reply to the request for changes explaining what you changed and asking for re-review, or reply on the merge proposal page in Launchpad.

Note if you are sponsored via debdiff attached to a bug report you need to manually update it as described in step 3.

5 Try your patch out with sponsor-patch

Some sponsors use the tool sponsor-patch from the package ubuntu-dev-tools to streamline the sponsorship process. Once you've requested sponsorship, try this out too, you might find some issues before a sponsor spends their time on it.

First thing you should do is setup pbuilder or sbuild for testing your package build in a clean environment. Its highly recommended to set one of these up and try out builds using them before you even request sponsorship, as it will help you to avoid basic mistakes like missing build dependencies.

Once you have one of these run either:

$ sponsor-patch -b -B sbuild -w ~/testbuild XXXXXX


$ sponsor-patch -b -B pbuilder -w ~/testbuild XXXXXX

Where XXXXXX is the bug report ID you are trying to close.

This should download your patch, the orig file, and test the build in a clean environment, in almost the same exact way that a sponsor would do it.


DistributedDevelopment/Documentation/SeekingSponsorship (last edited 2013-12-03 12:24:46 by dholbach)