Added revised version from pcb-rnd.
[geda-pcb/pcjc2.git] / README.ppa
blob7b328bea37ed75af141e05a932f191a4f4ecba9b
2 How to build packages for the Launchpad PPA
3 -------------------------------------------
5 As you may have noticed already, Launchpad and Ubuntu are tightly connected,
6 so this HowTo assumes you run Ubuntu or an Ubuntu derivate. It may work similar
7 on Debian, but no guarantees.
9 This HowTo also assumes you build for Ubuntu release 'vivid'. In case you build
10 for another release, simply replace each occurence of 'vivid' with that other
11 release name.
14 Web references, prerequisites
15 -----------------------------
17 What a PPA, a Personal Package Archive, is:
19   https://help.launchpad.net/Packaging/PPA
22 Packaging for a PPA happens the same way as packaging for Debian or Ubuntu it's
23 self. Ubuntu wiki pages about packaging start here:
25   http://packaging.ubuntu.com/html/
28 About the few differences between PPAs and regular packages (e.g. version
29 number):
31   https://help.launchpad.net/Packaging
34 Required packages, next to the environment to build gEDA it's self:
36   sudo apt-get install packaging-dev ubuntu-dev-tools
39 Other than that you also have to be member of the gEDAhead Launchpad team,
40 signed Ubuntus Code of Conduct and uploaded the public part of your SSH key.
42   https://launchpad.net/~geda
43   https://launchpad.net/codeofconduct
44   https://launchpad.net/people/+me/+editsshkeys
47 Getting started
48 ---------------
50 If you want to upload the packages later, you need your personal GPG key. On
51 how to create such a key, see
53   https://help.ubuntu.com/community/GnuPrivacyGuardHowto
55 To use this key it has to be added to your personal Launchpad account. Visit
57   https://launchpad.net/people/+me/+editpgpkeys
59 and follow the instructions. 'gpg --fingerprint' lists your keys with
60 fingerprints. After the fingerprint is imported, Launchpad will send you an
61 encrypted email and being able to decrypt it (your emailer should do this)
62 means this part works fine. Click the activation link in the email and be done.
64 Without the key you can still build the package, e.g. to find out wether
65 packaging works or to install it locally. The build process will abort a moment
66 before completion, but after creating the packages.
69 We want to build straight from the Git repo. However, Debian packaging builds
70 much on the assumption that developers ("upstream") and packagers are two
71 different entities. Some packaging tools assume source code tarballs in
72 specific places, which we don't have, unless we create them just for building
73 the package.
75 Luckily, the existence of Git has come to the attention of Debianers these
76 days, so they start to use repository clones for packaging ... which is very
77 similar to packaging from the original repo. See
79   https://wiki.debian.org/PackagingWithGit
81 The debian/ directory is already part of our Git repo.
83 Central tool is 'git-buildpackage'. It creates a temporary "upstream" tarball
84 straight from a Git stored object (usually a branch), not from the currently
85 checked out files of this repository. This temporary tarball is then passed to
86 the usual packaging tools, which in turn unpack it again.
88 To deal with the upstream-less situation 'git-buildpackage' needs a few
89 parameters. This is how it's run:
91   git-buildpackage --git-ignore-new --git-force-create \
92                    --git-upstream-branch=master --git-upstream-tree=BRANCH \
93                    --git-export-dir=packagebuild
95 Explanation:
97   --git-ignore-new
98     Ignores that there are uncommitted files when fetching the temporary build
99     tarball from Git. Without this flag, such files cause an abort.
101   --git-force-create
102     Overwrites an eventually already existing result tarball.
104   --git-upstream-branch=master
105   --git-upstream-tree=BRANCH
106     Tells which branch to fetch the temporary build tarball from and that
107     'master' is a branch.
109   --git-export-dir=packagebuild
110     Unpacks the temporary build tarball in 'packagebuild'. Without this flag,
111     this happens in the main directory and then dpkg-buildpackage complains
112     about files existing, but not being part of the build tarball.
115 Doing a (weekly) PPA upload
116 ---------------------------
118 First you have to update the changelog. Debian packaging insists on this and
119 also uses the signature of the top changelog entry to look for the signature
120 GPG key.
122   # For simplicity, take the first available signature.
123   MY_SIGNATURE=$(gpg --list-secret-keys | \
124                  awk '/^uid/ { $1 = ""; sub(/^[ ]+/, ""); print; }' | \
125                  head -1)
126   echo "My signature is ${MY_SIGNATURE}."
127   TODAY=$(date +%Y%m%d)
128   TIMESTAMP=$(date -R)
129   REL=vivid
130   mv debian/changelog temp
131   echo "pcb (${TODAY}-gedahead-weekly) ${REL};" \
132        "urgency=low"                                    > debian/changelog
133   echo                                                 >> debian/changelog
134   echo "  * Weekly build."                             >> debian/changelog
135   echo                                                 >> debian/changelog
136   echo "  For changes see" \
137        "http://git.geda-project.org/pcb/log/"          >> debian/changelog
138   echo                                                 >> debian/changelog
139   echo " -- ${MY_SIGNATURE}  ${TIMESTAMP}"             >> debian/changelog
140   echo                                                 >> debian/changelog
141   cat temp >>debian/changelog
142   rm temp
143   sed -i "s/^Uploaders:.*/Uploaders: ${MY_SIGNATURE}/" debian/control
144   unset MY_SIGNATURE TODAY TIMESTAMP REL
145   # git-buildpackage picks up comitted stuff, only, so commit the above.
146   git commit debian/changelog debian/control -m "weekly build"
149 Then build as explained above:
151   # We want to build from our current branch, which is not always 'master'.
152   THIS=$(git symbolic-ref --short HEAD)
153   rm -rf packagebuild
154   git-buildpackage --git-ignore-new --git-force-create \
155                    --git-upstream-branch=${THIS} --git-upstream-tree=BRANCH \
156                    --git-export-dir=packagebuild
157   unset THIS
160 Launchpad PPAs accept only sources, they build binaries them selfs. Trying
161 to upload binaries results in a rejection of the whole package, so let's see
162 the above as a preparation and build test and rebuild for source-only packages.
163 It takes only a few seconds.
165   THIS=$(git symbolic-ref --short HEAD)
166   rm -rf packagebuild
167   git-buildpackage --git-ignore-new --git-force-create \
168                    --git-upstream-branch=${THIS} --git-upstream-tree=BRANCH \
169                    --git-export-dir=packagebuild --git-builder='debuild -S'
170   unset THIS
173 Last build step is to upload the package to the gEDAhead PPA:
175   dput ppa:geda/weekly packagebuild/pcb_*-gedahead-weekly_source.changes
178 To round up, remove this committed changelog entry and the build:
180   git reset --hard HEAD^
181   rm -rf packagebuild
184 Building with pbuilder
185 ----------------------
187 If you want to modify the packaging system, e.g. for testing dependencies, it's
188 a good idea to build in a chroot'ed environment. There are many tools out there
189 to make this easy ... and almost as many which I (Traumflug) found to not
190 work as described. If you think that's me, well, have a look at
192   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779255
194 The tool which was found to actually work is 'pbuilder'. It's very similar to
195 the tool used by these build farm machines (sbuild).
198 We have build dependencies in 'universe', so let's pbuilder know this:
200   echo "COMPONENTS=\"main restricted universe multiverse\"" > ${HOME}/.pbuilderrc
202 Then build a base chroot image:
204   # To build for 32-bit on a 64-bit machine, add --architecture i386
205   # To build for a different distribution, add --distribution vivid
206   sudo pbuilder create --debootstrapopts --variant=buildd
208 It's recommended to update this chroot image once daily:
210   sudo pbuilder update
213 The above has to be done only once. To actually build the package, prepare the
214 source package as shown in the previous section, but don't upload to Launchpad
215 and also don't remove packagebuild/. Then it's as simple as this:
217   (cd packagebuild && sudo pbuilder build *.dsc)
219 Built packages end up in /var/cache/pbuilder/result/.
222 Cleaning:
224   sudo rm -r /var/cache/pbuilder  # remove chroot image and apt cache
226 ... and don't forget to remove the stuff made in the previous section.
229 TODO:
230 -----
232 pcb version isn't set, after packaging the application its self still reports
233 "pcb-1.99z". The --git-prebuild=COMMAND parameter for git-buildpackage might
234 come in handy here for setting this on the fly (citation for its man page):
236   execute COMMAND from the build directory before calling debuild or the
237   application specified via --git-builder. Exported environment variables
238   are: GBP_GIT_DIR (the repository the package is being built from),
239   GBP_BUILD_DIR (the build dir).
242 Put all this into a script, perhaps a Makefile target.
245 Review each dependency. Like removing it from the build machine, then trying to
246 build and run the binary. Likely this dependency list is a decade old, so it
247 well might contain obsolete entries.
250 There are tools to create a package changelog from Git history. Might be
251 better than putting a link to the public Git repository.
253   https://marquiz.github.io/git-buildpackage-rpm/man.gbp.dch.html