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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
[[!toc]]
# Keeping debian/patches on a patch-queue branch
I'm keeping all patches for a Debian package that is maintained on branch *foo* on a patch-queue branch *patch-queue/foo* since:
* one can easily work with the unpatched (*foo*) and patched (*patch-queue/foo*) branches
* patches can easily be dropped, added by modifying the patch-queue branch (no messing with *quilt add*, *dpatch-edit-patch*, *cdbs-edit-patch* or the like)
* easy cherry-picking of patches for stable releases, etc.
* easy forward porting of patches to new upstream versions by using *git rebase* on the *patch-queue/foo* branch (patches already applied upatream are detected automatically).
* the generated patch in *debian/patches/* has all the necessary information to forward it upstream since it's auto generated via *git-format-patch*.
Disadvantage:
* no history on the *patch-queue/foo* branch, but you do have the history on *foo* of course.
### Workflow:
Assuming the Debian source package has it's patches in *debian/patches* and these are parseable by *git-quiltimport(1)*:
* create *patch-queue* branch and import *debian/patches* onto it using [gbp-pq](http://honk.sigxcpu.org/projects/git-buildpackage/gbp-pq):
cd $REPO
gbp-pq import
* work an patch-queue branch (add, remove, rebase, test)
* switch back to master:
git checkout master
* regenerate the patches in *debian/patches/* using [gbp-pq](http://honk.sigxcpu.org/projects/git-buildpackage/gbp-pq):
gbp-pq export
* commit the result either by using *gbp-add-patch* or simply
git commit -a debian/changelog
* update *debian/changelog* (e.g. by running "git-dch -S -a")
* build the package
* after importing a new upstream version you can use the following commands to refresh *debian/patches*:
gbp-pq rebase
git checkout master
gbp-pq export
### Team maintenance
The easiest way is to not push out any patch-queue/* branches at all. They can be recreated by any team member easily by using
git branch -d patch-queue/master
gbp-pq import
However you *can* push out patch-queue branches. Other team members must just be aware that that branches in the *patch-queue/* namespace are being rebased frequently.
# Working with 3.0 (quilt) packges
The 3.0 (quilt) format applies the patches in *debian/patches* automatically when building a source package.
If you want your debian branch to contain the unpatched source there are several ways to handle this:
## Using --git-export-dir
If you're using option *--git-export-dir* option already there's no problem since the unpatched source tree gets exported before being built (and patch by dpkg-source). Since this implies an extra copy of the whole source tree (which might be slow for big projects) and it's not really necessary when using pbuilder the next method might be more appropriate.
## Working from a patch-queue branch
Instead of building from *master* build from *patch-queue/master* prepared by *gbp-pq* as describe above. This branch has the patches already applied as dpkg-source expects it:
gbp-pq import
git-buildpackage --git-debian-branch=patch-queue/master
Build and test...
git checkout master
gbp-pq export
# Cloning a repository
If you use *gbp-clone* instead of *git clone* to clone a remote repository it will automatically set up the *debian*, *upstream* and *pristine-tar* branches for you. The [manual](http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY) explains the terminology.
# Keeping a repository up to date
After initially cloning with *gbp-clone* you can run *gbp-pull* to update your
*debian*, *upstream* and *pristine-tar* branches from the remote site. So the
complete workflow for simple team maintenance looks like this:
# Initially clone the repo once
gbp-clone git://git.debian.org/pkg-libvirt/gtk-vnc.git
cd gtk-vnc
Work on that clone, commit, release, push, etc. Now after a couple of days you
want to make more changes but don't know if another developer worked on it. So
you do:
# Update to what others might have pushed
gbp-pull
This will update all necessary branches to what other developers might have
pushed in the meantime. If you're also using a patch-queue as described above
you can refresh that too in one step:
# Update to what others might have pushed and rebuild patch-queue
gbp-pull --redo-pq
This will additionally drop your current patch-queue branch and recreate it from debian/patches.
# Preparing a Backport
I keep backports on a separate *bpo-<release>* branch like *bpo-lenny*:
git checkout bpo-lenny
git merge debian/<version-currently-in-testing>
<resolve conflict in debian/changelog>
<fix up stuff needed for backport>
gbp-lenny -sa -v <last-backported-version> --git-debian-branch=bpo-lenny
*gbp-lenny* is a shell alias:
alias gbp-lenny='nice -19 git-buildpackage --git-builder=gbp-cowbuilder-lenny'
and *gbp-cowbuilder-lenny* uses */usr/share/doc/git-buildpackage/examples/gbp-cowbuilder-sid*:
ln -s /usr/share/doc/git-buildpackage/examples/gbp-cowbuilder-sid ~/bin/gbp-cowbuilder-lenny
|
