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 _______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
