Le Fri, Jan 13, 2012 at 08:54:22AM +0100, Andreas Tille a écrit : > > > Perhaps you did not update the pristine-tar branch before trying to build > > the > > package ? The commande ‘gbp-pull’ will do this conveniently for you. > > I simply assumed that a `git pull` would simply do the right thing and > I guess this assumption is valid: > > $ gbp-pull > gbp:info: Branch 'master' is already up to date. > gbp:info: Branch 'upstream' is already up to date. > gbp:info: Branch 'pristine-tar' is already up to date.
‘git pull’ will only update the currently checked out branch. I wish there were an option to update all of them, but it does not seem to exist; I hope it will be added some day. In the meantime, there is gbp-pull. But why didn't it work in your hands, I am not sure. If you do not have anything committed, it is sometimes simpler to just delete the clone and restart from scratch. > IMHO, *.tar.bz which is the case for clinica does not have the same > problem as gz and files are identical. Or am I wrong here? When I checked this morning, the tarballs were not identical, and it is at least related to the fact that when I use get-orig-source, the tar file recorded my username and group (charles/charles), whereas they are obviously not the same in the pristine-tar branch. There may be a workaround… probably the --group and --name parameters of tar ? > > About just keeping the debian directory; I would not like it. Having the > > upstream source checked in is an addictive convenience for bug hunting, and > > also for copyright checking and other inspections done during upgrades. > > This > > is one of my main motivations for using Git. And within that workflow, the > > pristine-tar branch helps me to work off-line. > > I could accept this if it would work as expected but as I had it always > caused trouble to me (I do not say that it's not me who missunderstood > the process - but it should work solid enough that it is error prone). Seriously, I think that you had bad luck. Or taken differently, in some cases where you worked on git-managed packages, it was to help others, and if others need help, it is already a sign that the situation is not as easy as usual :) > $ git-buildpackage -k "Andreas Tille <[email protected]>" > dh clean > dh_testdir > dh_auto_clean > dh_clean > ./waf --nocache distclean > 'distclean' finished successfully (0.000s) > rm -f gschemas.compiled > if test -d "waflib"; then find waflib -name "*.pyc" -delete; fi > gbp:info: Orig tarball 'clinica_0.2.1~dfsg.orig.tar.bz2' found at > '../tarballs/' > gbp:info: Exporting 'HEAD' to > '/home/tillea/debian-maintain/alioth/debian-med_git/build-area/clinica-tmp' > gbp:info: Moving > '/home/tillea/debian-maintain/alioth/debian-med_git/build-area/clinica-tmp' > to > '/home/tillea/debian-maintain/alioth/debian-med_git/build-area/clinica-0.2.1~dfsg' > /bin/sh: 1: Syntax error: end of file unexpected > gbp:error: ~/bin/git-pbuilder returned 2 > gbp:error: Couldn't run '~/bin/git-pbuilder -k Andreas Tille > <[email protected]>' You must have a git-buildpackage configuration file somewhere that has some non-standard options enabled. On my system, it does not run pbuilder by default. My workflow is the following: debcheckout -a --git-track='*' $package cd $package git-buildpackage -us -uc # (I do not want to sign them before testing) # sometimes it fails and recommends to add --git-ignore-new # git-buildpackage -us -uc --git-ignore-new cd .. # Inspect, test, install, … sbuild -sAd unstable $package.dsc debsign … Cheers, -- Charles -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
