[git-buildpackage] Tracking remote pristine-tar on salsa

[Guido Günther]

Hi,
On Wed, Aug 08, 2018 at 01:57:55PM +0200, Agustin Henze wrote:
> Hi guido,
> 
> On 08/08/18 11:48, Guido Günther wrote:
> [...]
> >> Yeah, that could work. Oh, rereading my previous email I see that I didn't
> >> explain the whole scenario correctly, sorry. We are trying to write a pipeline
> >> that could be applied to any repository i.e. there are repositories with
> >> pristine-tar and there are other repositories without it. So as far I can see
> >> there isn't an automagically way for telling gbp track the origin pristine-tar
> >> if it's present. One of the goal if to KIS as possible and writing a
> >> detection
> > 
> > The good thing is that gbp buildpackage doesn't need to track
> > it. pristine-tar (as invoked by gbp buildpackage) just needs to be able
> > to find the commit.
> > 
> >> first if pristine-tar is enabled (maybe using gbp config) and then fetching the
> >> remote it doesn't sound very simple. If I write a patch with a new option like
> >> --git-force-track-remote-pristine-tar or something like that, are you willing
> >> to merge it?
> > 
> > I'm always happy to merge good patches but let's try to sort out what
> > needs to be done first?
> > 
> > "gbp buildpackage" does no remote fetching (and that's on purpose). So
> > either you already have the pristine-tar commits in your local repo (let's
> > ignore the branch name for the moment) when you start the build or you
> > haven't. In the later case s.th. else needs to fetch it.
> > 
> > That would be "gbp pull"'s job but gbp pull wasn't able to pick up
> > new branches from the remote side so I just did:
> > 
> >     https://git.sigxcpu.org/cgit/git-buildpackage/commit/?id=6dda2da54efbb81e4e1593d57eb5f30c4ef1e6d8
> > 
> 
> I've tested that commit with some tweaks to make it work (fetch_remote is
> undefined and config.py is not populated) and it does the work as expected.
> Thanks! :).

Oh, you need to pull the full branch to make it work. Sorry, I should
have said that.

> > I'm not opposed to a "use-pristine-tar when available and fall back to
> > tarball creation" but I think that's already there in a hacky way with the
> > "--git-pristine-tar --git-pristine-tar-commit" options (use
> > pristine-tar, if not create tarball and commit it to the
> > pristine-tar branch). So what about:
> > 
> >     - gbp pull --debian-branch= --upstream-branch= --pristine-tar --track-missing
> 
> Actually executing gbp pull with the new option --tracking-missing works
> perfectly because it tracks `pristine-tar` if it's there.
> 
> $ gbp pull --debian-branch= --upstream-branch= --pristine-tar --track-missing
> gbp:info: Fetching from default remote for each branch
> gbp:info: Branch 'pristine-tar' is already up to date.
> 
> >     - gbp buildpackage --git-pristine-tar --git-pristine-tar-commit
> > 
> 
> I've tried without the options `--git-pristine-tar` and
> `--git-pristine-tar-commit` and it creates the orig from pristine-tar branch
> before launch the building. So, I'm a little bit confuse here why are you
> suggesting this.

The --git-pristine-tar-commit is for the case when a project does not
use pristine-tar.

> 
> > Now pristine-tar-commit wastes time so we can make this nicer by adding
> > a list of methods for tarball creation to gbp export-orig:
> > 
> >     - gbp export-orig --from="pristine-tar,upstream-ref"
> > 
> 
> I like this, because as you said. It'll be really explicit what are we doing
> and how.
> 
> > "gbp buildpackage" and "gbp export orig" use the same logic internally
> > to build tarballs but export-orig should be simpler to deal with since
> > it carries less "don't break existing installation" code. So a patch to
> > make this possible would be great. In gitlab CI this would then become:
> > 
> >     - gbp pull --debian-branch= --upstream-branch= --pristine-tar --track-missing
> >     - gbp export-orig --from="pristine-tar,upstream-ref"
> >     - gbp buildpackage
> > 
> > Which is also splits the responsibilities nicely and makes it obvious
> > for someone looking at the output where the error happened. The above
> > list of tarball creation methods could later on be used to say:
> > 
> >     - gbp export-orig --from="pristine-tar,download,upstream-ref"
> > 
> > which is of lesser use to CI but for
> > 
> >      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902249
> > 
> 
> Ok, I see that you are solving two problems simultaneously with one new
> feature. I like it!
> 
> > It would be great to make using gbp as simple possible in your
> > gitlab CI pipelines.
> 
> Thanks for sharing your thoughts! Please let me know how can we help you! Of
> course, we are here for testing but if you want help with something else just
> tell us.

Main problem is getting around to it atm. I have some basics done and
hope to have s.th. testable next week, if not I'll put things somewhere
so you can look into finishing it if you like.

Cheers,
 -- Guido