Hi Eduard, sorry for the delay. Hopefully I have your concerns covered: On Mon, May 23, 2016 at 08:14:34PM +0200, Eduard Bloch wrote: > Hallo, > * Guido Günther [Sun, May 22 2016, 05:36:39PM]: > > retitle 824801 buildpackage: option to force sloppy test builds > > summary 824801 It should be simple to perform a build of the current HEAD > > without having to worry about upstream branches, pristine-tar and the like > > > > On Fri, May 20, 2016 at 08:37:54AM +0200, Guido Günther wrote: > > > On Thu, May 19, 2016 at 11:40:38PM +0200, Eduard Bloch wrote: > > > > Package: git-buildpackage > > > > Version: 0.7.4 > > > > Severity: wishlist > > > > > > > > Hi, > > > > > > > > I remember having reported a similar issue a couple of years ago and > > > > back then it was closed with a useless coment. This time I stumbled upon > > > > it again and still cannot find a SANE solution. With SANE, I mean > > > > user-friendly. I, as user, wish to have an option to make a test build. > > > > Without having an upstream tarball! > > > > (that is the key point. The debian branch is a fork of the upstream > > > > branch after all, it should just work). > > > > > > > > WRT dpkg-buildpackage itself, I can easily force it to act like on a > > > > native package and just build me my binary packages. But with gbp, this > > > > simple task becomes PITA: it wants me to have some upstream reference or > > > > else... (see below). > > > > > > > > Sorry, there really should be an easy and user-friendly way to let me > > > > just build it, no matter whether there is an upstream tag or not. I > > > > did RTFM and nothing ringed a bell there. If there is an easy way, > > > > please document it properly.
The sheer amount of options needed is not particularly user friendly but you can force gbp to create a tarball from whatever you have in your working copy since some time now: https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.special.html#GBP.SPECIAL.SLOPPYTARBALL > > > > dh_clean > > > > rm -rf debian/apt-cacher-ng.service debian/apt-cacher-ng.tmpfile > > > > dbgen/dbgenerator.* dbgen/dbupdate > > > > debconf-updatepo > > > > ... > > > > gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at > > > > '../tarballs/' > > > > gbp:error: Pristine-tar couldn't checkout > > > > "apt-cacher-ng_0.9.3.orig.tar.xz": fatal: Path > > > > 'apt-cacher-ng_0.9.3.orig.tar.xz.delta' does not exist in > > > > 'refs/heads/pristine-tar' > > > > pristine-tar: git show > > > > refs/heads/pristine-tar:apt-cacher-ng_0.9.3.orig.tar.xz.delta failed > > > > > > It's still the same as back then: don't sue pristine tar if you don't > > > want it and tell gbp that you're fine with just picking the head of your > > > upstrema branch. > > > > That said an option that creates a tarball not from the upstream branch > > but just takes the current tree, drops debian/ and creates an upstream > > tarball from it would probably also helpful in the above situation (at > > least for 3.0 (quilt). > > > > This would also allow to test patches without having to move to a pq > > first. We would just have to make sure we create a unique version number > > just like -S in gbp dch. > > Oookay, I am not that familiar with the details nor do I use any > "advanced" workflow like pq. For simple packages, I prefer simple > solutions and feel enslaved if some tool attempts to be too smart and > to enforce it's own conventions, no matter whether they make sense or not. > > Anyhow, And the good news, after some experiments it was possible to > force the build that way with: > gbp buildpackage --git-no-pristine-tar --git-no-create-orig > --git-builder="fakeroot debian/rules binary" > > So, thanks! > > But it still does not feel right. I am trying to be constructive here... > > First: it's about the usability of the package. I mean, for you it was obvious > that pristine-tar is the culprit. For me, it was not. > > IMHO, a helpful error message (after the pristine-tar barking) would say > something ADDITIONAL like: > > "pristine-tar method failed to construct upstream source. Please use one > of the -git-upstream-* options or see documentation for other ways of > upstream source configuration." > > Second: even using --git-no-pristine-tar it still does not build. > > gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at > '../tarballs/' > gbp:error: upstream/0.9.3 is not a valid treeish > > Aapparently you need to specify --git-upstream-tree OR both, > --git-upstream-branch and --git-upstream-tag set to HEAD (which does not > feel right either because HEAD is not a tag, strictly speaking). Maybe > HEAD is also wrong (works by accident? The manpage does not explain it). > Anyhow, maybe the error message should be more explicit about the reason > in case where upstream-branch is already set but that is not considered > enough information to build the original source. > > And, another inconvenient thing: I'd expect all -git-upstream* options > in a line in the manpage. But they are spread all around, even in the > synopsis. This does not feel right eighter, especially since after > finding --git-upstream-tag and --git-upstream-branch one might think > that he is out of options now (--git-upstream-tree is... well, not > obvious, and BTW, "treeish" is cool git dev's slang but maybe not > the best word for a user message). See: https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.buildpackage.html which hopefully makes it simpler to spot wich options are of relevance. If you have more improvements that's great! Cheers, -- Guido > > And only after a while I found out that --git-no-create-orig is also a > solution (even a better one than using --git-upstream-* options). Maybe > the error message above for pristine-tar could also mention > --git-no-create-orig as an alternative. > > Anyhow, I am much happier than an hour ago. Have a nice day/night! > > Regards, > Eduard. >
