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
|
We maintain a patch series for multiple gcc releases. Each release has sources
available in the gcc-$gcc_release-sources packages. We carry corresponding
patches in patches/gcc-$gcc_release/. Note that this differs from the usual
setup where the source being patched lives in the same repository as the patches
themselves. The usual patch-management tools (most notably gbp-pq) make this
assumption, so as it stands we cannot use them. What we do instead is described
below.
We have a separate git repository that contains sources for the released
gcc-$gcc_release packages and our patches, as git commits. This repository is at
ssh://git.debian.org/git/crosstoolchain/gcc-$gcc_release.git
There are several branches here:
- "upstream" is the source as released by the gcc project
- "master" is "upstream" + a few commits. This is the debianization of this
source by the Debian gcc maintainer
- "patches" is "master" + a few commits. This is the debianization with patches
needed for building a cross compiler. Each patch lives in a separate git
commit
- "patches-$gcc_debian_version" is the "patches" branch for a particular debian
version of gcc. At some point, this was the main patches branch. Thiese
branches exist for easy future reference
When a new Debian gcc release is made, the workflow to update the patches
(automated by auto_build_all.sh):
1. 'apt-get update' to make the new sources available
2. gcc-$gcc_release repository: Clean out the repository. "git status" should
say that the "working directory" is clean: no changes and no untracked files are
present
3. gcc-$gcc_release repository: run
gbp import-dsc --download gcc-$gcc_release-source
This should import the new sources, updating the "upstream" and "master"
branches
4. gcc-$gcc_release repository: at this point, the "master" branch and the
"patches" branch have diverged, since the "patches" branch is a descendant of
the old "master", not the one we just updated. We thus rebase the "patches": Run
git checkout patches; git rebase master && git branch patches-$version
where $version is the version of the new debian gcc-$gcc_release release. The
$version is a more fine-grained version that doesn't have its own
gcc-$version-source package, but has a gcc-$gcc_release package instead: for
instance we could have gcc_release=4.9 and version=4.9.2-10. The patches may or
may not apply cleanly to the new sources. If not, do the usual git thing to
resolve conflicts until we have our patches in a form we like, descending from
the "master" branch. The new "patches-$version" branch is retained for easy
future reference. Unlike the "patches" branch, that branch does now move around
as patches are rebased.
5. We can now export the patches as files that quilt can consume later.
cross-gcc repository: Remove old patches; run
git rm patches/gcc-$gcc_release/*; mkdir -p patches/gcc-$gcc_release
gcc-$gcc_release repository: with the "patches" branch checked out, run
git format-patch -o path_to_cross_gcc_repo/patches/gcc-$gcc_release master
cross-gcc repository: Commit new patches; run
cd patches/gcc-$gcc_release; ls *.patch > series; git add *; git commit -m 'patch update'
6. gcc-$gcc_release repository: push the changes
git push --all
works to push the "master" and "upstream". The "patches" branch doesn't follow a
linear history, however (more on this in a bit), so it needs to be pushed
explicitly:
git push origin +patches:patches
This workflow allows us to use git to manage the patches as much as is possible.
An annoying property of this workflow is that in our gcc-$gcc_release tree it
would be normal to rewrite the history in the "patches" branch. The exported
patches are versioned normally in the cross-gcc tree, but in the
gcc-$gcc_release tree, the "patches" branch is more ephemeral. This is important
to recognize. Thus the golden copy of the current patch set is in the exported
files, NOT in the "patches" tree and the "patches-$version" branch. The exported
patches can be imported back to git with the 'git am' command.
|
