Le 16/11/2018 à 15:28, Guido Günther a écrit : > Here's what I do for new releases: > > 1.) git checkout debian/master > 2.) git merge <upstream-tag> > [do the debian tweaking if necessary]n > 3.) gbp dch -R -a -- debian > 4.) gbp buildpackage --git-pristine-tar-commit --git-tag > > If I want the github tarball I'd use uscan to download the tarball. The > upcoming "gbp import-ref" is supposed to make 2.) and 3.) one step with > optional filtering to make things dfsg clean (that's its main purpose). > > So the main difference I see is that you rely on github to build the > tarball while I do that locally (during the gbp invocation). This also > allows me to sign exactly this tarball.
>> Having a "--uscan" option in "gbp pristine-tar" would be useful, since >> it would allow one to merge steps 5 and 6 (or 9 and 10). > > I'm not opposed to this but I'm not likely to write it since relying on > external parties to create the tarball is nothing I do. This makes things much clearer. I failed to realize that GitHub could be considered as an untrusted source. I thought that [1] implicitly meant that they could be trusted (although they do specify to sign the tarball only after verifying that it "contains exactly the same data as the git repository"). But, isn't the whole point of pristine-tar to ensure that the orig.gz tarball is bit-by-bit identical to the upstream one ? With the method you're describing, it may be different (even if the contents is the same) than the one distributed on GitHub, which seems to contradict [2] (although I understand this is just a best practice, not a requirement from the Debian Policy). It does theoretically guarantee reproducible source packages, though. [1] https://wiki.debian.org/Creating%20signed%20GitHub%20releases [2] https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#pristinesource > Doing > > gbp clone --debian-branch=debian/master Ah ! :) You didn't specify to to add the "--debian-branch" option before. The point of the heuristic method I described in my first e-mail was to guess the Debian branch without having to specify the option, but I admit it may be overkill. > gives me a correctly checked out debian branch. If you put > > [DEFAULT] > debian-branch=debian/master > > in your ~/.gbp.conf it becomes: > > gbp clone Unfortunately, I can't do that, since most of the packages I work on (officially or for my own changes on my personal repository) have the "classic" branches names (master, upstream, pristine-tar). >> Or am I not supposed at all to have both upstream and Debian on the same >> Git repository ? I'm starting to believe that everything would be much >> simpler to have the GitHub repository to hold the upstream sources >> alone, and a separate repository (say on Salsa) to hold the Debian >> packaging branches named like gbp expects them. > > This makes having debian and upstream match much harder imho. Agreed. I wouldn't do that just to save one or two steps in my workflow, but I said it in the sense that it's what the tools seem to expect. In conclusion, I guess I'll stick with the three separated steps for downloading the tarball, committing it to the pristine-tar branch, and importing the changes in the Debian branch. Thanks for your time. Regards, -- Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
_______________________________________________ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage