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

[Agustin Henze]

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! :).

> 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.

> 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.

PS: Do you know if it would be easy to change calling pristine with pxz instead
of xz?

-- 
TiN

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sigxcpu.org/pipermail/git-buildpackage/attachments/20180808/a37e0f32/attachment.sig>