How do I patch a Debian package
Posted by Serge on Sat 24 Sep 2005 at 07:28
I've been looking into the new maintainer howto, to try and understand how I should properly patch an existing Debian package, in case a Sarge package rsync.
I'm being confronted with a rather anoying bug in rsync, which totally brakes rsnapshot for me. Read all about that in #317418.
Although I quite understand what Debian "stable" is all about, I fail to understand how a non-security bug, that nevertheless severely breaks a package, is not solved in Debian stable. But that's only a sidenote.
My other readings went to, as always, the very nice articles here, in particular this article rebuilding Debian Packages.
I wanted to patch rsync-2.6.4 with the patch I linked to in my bug report, to solve my rsnapshot problem. I tried it and thought I did well. The resulting package built without errors and can be found here:
The problem is, the bug remains :) I suspect the patch didn't get applied.
Basically what I did was update the changelog and saving the patch in debian/patches. I suppose there is something more to do as to tell the system to use that patch, but that tiny little detail isn't clear in the New Maintainers howto.
Even more, the examples presented never clearly explain my situation where one wants to patch an existing deb.
I also found it quite confusing when the manual explains different 'patch systems' (debuild, others, ...) I'm not sure why there are different systems.
I hope this brings an interesting view for the more advanced debian developer to understand which part of the new maintainer manual isn't quite clear. But then again, it might just be me :)
A lot of explanation, but what I want to ask is if somebody would have a look on my custom package and explain me the detail of what I missed. Thanks!
Basically, you just need to change the debian/rules file to use dpatch:
- Create a debian/patches directory
- Edit a debian/patches/00list file where you put the list of the patch you want to apply
- Create the patch template using dpatch patch-template:
dpatch patch-template -p "01_some_patch" "A random patch" \
debian/patches/01_some_patch.dpatch
- Edit the debian/rules file: you first need to source the dpatch rules ('include /usr/share/dpatch/dpatch.make'), and make use of them (clean calls unpatch, build calls patch etc.) - reading man pages is really worthy is this case!
Hope this can help.
Cheers
Julien
[ Parent | Reply to this comment ]
[ Send Message | View Serge's Scratchpad | View Weblogs ]
I updated the packages on
http://www.vanginderachter.be/downloads/debian/
One question remains: how do I make a source deb with those now?
I also wrote an antry on my blog about why this was important to me: (shameless plug)
http://www.vanginderachter.be/2005/debian-sarge-rsync-package-upd ated/
Thanks for all the help.
--
Serge van Ginderachter
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I'm using Debian Testing and trying to install OpenTSA(open timestamp) patch(about 350Kb of code), but have some difficults with it...
I'm doing as you say:
cd /home
apt-get source openssl
cp ts-20060225-0_9_8a-patch openssl-0.9.8a/
cd openssl-0.9.8a
patch -p1 < ts-20060225-0_9_8a-patch
patching file Configure
Hunk #1 succeeded at 1186 (offset 40 lines).
patching file Makefile
Hunk #1 FAILED at 11.
Hunk #2 FAILED at 59.
Hunk #5 FAILED at 137.
3 out of 5 hunks FAILED -- saving rejects to file Makefile.rej
patching file Makefile.org
patching file apps/CA.pl
patching file apps/Makefile
patching file apps/openssl.cnf
patching file apps/progs.h
patching file apps/ts.c
patching file apps/tsget
patching file crypto/cpt_err.c
patching file crypto/crypto.h
patching file crypto/opensslconf.h
Reversed (or previously applied) patch detected! Assume -R? [n]
and more... but with errors :(
If i patch the openssl-0.9.8a.orig.tar.gz with that patch it works perfect, but i need new version of debian package openssl with that patch.
How can i do it?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
but i really must recommend pbuilder if you do much building of packages (whether one package multiple times or several packages). i use pbuilder to build/backport packages on my testing desktop for my stable server.
works great even for building software that you are not going to package, but just going to tarball: build, install, & tarball it in the pbuilder chroot, then untar it on the server. i use a chroot because i usually have to muck with the configure or make files to get everything to install properly under /usr/local and i don't like doing this trial & error process on my server. sure, a plain chroot is all that's needed, not pbuilder's, but if you are already using pbuilder for building debian packages, might as well use pbuilder for this too.
[ Parent | Reply to this comment ]
And now the remaining question is ...
How to have this well intregrated with automated updates ?
(ie. in case of a security update, do you want you're package to be overwritten ? will you remember this modification in 5 years when etch will be out ?).
[ Parent | Reply to this comment ]
[ Send Message | View Serge's Scratchpad | View Weblogs ]
You probably do not want updates to overwrite them.
Pinning your package will avoid your package to be upgraded. Manually monitoring and backporting your fix would be the only way I think.
--
Serge van Ginderachter
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Two quick comments:
If that is the problem get the source:
Make your changes (ie. apply the patch).
Then run debuild, and ignore the patches directory.
Steve
--
[ Parent | Reply to this comment ]