X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-user.7.pod;h=5713064b86a781cc116d41370df1661d5c32c54f;hp=fc0d5905b2668c86bdbfdfb7ab7aeea2fc4f451f;hb=5f0580a8bbf6460363d208acfab53714f190a7a6;hpb=a45f75bad000ac3230dace4291cda2e167d8102d diff --git a/dgit-user.7.pod b/dgit-user.7.pod index fc0d5905..5713064b 100644 --- a/dgit-user.7.pod +++ b/dgit-user.7.pod @@ -30,12 +30,12 @@ or L and L. =over 4 - % dgit clone glibc jessie + % dgit clone glibc jessie,-security % cd glibc - % wget 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u + % curl 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u % git commit -a -m 'Fix libc lost output bug' % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit - % sudo apt-get build-dep glibc + % mk-build-deps --root-cmd=sudo --install % dpkg-buildpackage -uc -b % sudo dpkg -i ../libc6_*.deb @@ -55,7 +55,7 @@ Later: =over 4 % cd glibc - % dgit pull jessie + % dgit pull jessie,-security % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit % dpkg-buildpackage -uc -b % sudo dpkg -i ../libc6_*.deb @@ -66,7 +66,7 @@ Later: =over 4 - % dgit clone glibc jessie + % dgit clone glibc jessie,-security % cd glibc =back @@ -125,15 +125,23 @@ If you don't know what you're running, try this: =back +For Debian, you should add C<,-security> +to the end of the suite name, +unless you're on unstable or testing. +Hence, in our example +C becomes C. +(Yes, with a comma.) + =head1 WHAT DGIT CLONE PRODUCES =head2 What branches are there dgit clone will give you a new working tree, -and arrange for you to be on a branch like -C. +and arrange for you to be on a branch named like +C (yes, with a comma in the branch name). -There is a tracking branch for the contents of the archive, called +For each release (like C) +there is a tracking branch for the contents of the archive, called C (and similarly for other suites). This can be updated with C. @@ -141,6 +149,12 @@ This, the I, is synthesized by your local copy of dgit. It is fast forwarding. +Debian separates out the security updates, into C<*-security>. +Telling dgit C means that it should include +any updates available in C. +The comma notation is a request to dgit to track jessie, +or jessie-security if there is an update for the package there. + (You can also dgit fetch in a tree that wasn't made by dgit clone. If there's no C you'll have to supply a C<-p>I option to dgit fetch.) @@ -183,12 +197,15 @@ or upstream's git history. But for many packages the real git history does not exist, or has not been published in a dgitish form. -So yuu may find that the history is a rather short +So you may find that the history is a rather short history invented by dgit. dgit histories often contain automatically-generated commits, including commits which make no changes but just serve to make a rebasing branch fast-forward. +This is particularly true of +combining branches like +C. If the package maintainer is using git then after dgit clone @@ -215,9 +232,9 @@ that are in debian/patches before you do anything else! Debian package builds are often quite messy: they may modify files which are also committed to git, -or leave outputs and teporary files not covered by C<.gitignore>. +or leave outputs and temporary files not covered by C<.gitignore>. -Kf you always commit, +If you always commit, you can use =over 4 @@ -271,21 +288,37 @@ a complete treatment is beyond the scope of this tutorial. =over 4 - % sudo apt-get build-dep glibc + % mk-build-deps --root-cmd=sudo --install % dpkg-buildpackage -uc -b =back -apt-get build-dep installs the build dependencies according to the -official package, not your modified one. So if you've changed the -build dependencies you might have to install some of them by hand. - dpkg-buildpackage is the primary tool for building a Debian source package. C<-uc> means not to pgp-sign the results. C<-b> means build all binary packages, but not to build a source package. +=head2 Using sbuild + +You can build in an schroot chroot, with sbuild, instead of in your +main environment. (sbuild is used by the Debian build daemons.) + +=over 4 + + % git clean -xdf + % sbuild -c jessie -A --no-clean-source \ + --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn' + +=back + +Note that this will seem to leave a "source package" +(.dsc and .tar.gz) +in the parent directory, +but that source package should not be used. +It is likely to be broken. +For more information see Debian bug #868527. + =head1 INSTALLING =head2 Debian Jessie or older @@ -332,10 +365,11 @@ The proper solution is to build the package for all the architectures you have enabled. You'll need a chroot for each of the secondary architectures. -This iw somewhat tiresome, +This is somewhat tiresome, even though Debian has excellent tools for managing chroots. -C from the sbuild package is a -good starting point. +C from the package of the same name +and C from the C package are +good starting points. Otherwise you could deinstall the packages of interest for those other architectures @@ -345,9 +379,9 @@ If neither of those are an option, your desperate last resort is to try using the same version number as the official package for your own package. -(The verseion is controlled by C - see above,) +(The version is controlled by C - see above). This is not ideal because it makes it hard to tell what is installed, -because it will mislead and confuse apt. +and because it will mislead and confuse apt. With the "same number" approach you may still get errors like @@ -362,7 +396,7 @@ but passing C<--force-overwrite> to dpkg will help =head1 SHARING YOUR WORK -The C branch (or whatever) is a normal git branch. +The C branch (or whatever) is a normal git branch. You can use C to publish it on any suitable git server. Anyone who gets that git branch from you