Hi Andreas,
thanks for your report. You've found several issues, see below:
On Mon, Nov 06, 2017 at 03:59:01PM +0100, Andreas Beckmann wrote:
> Package: git-buildpackage
> Version: 0.9.1
> Severity: normal
>
> Hi,
>
> I'm in the process of converting my last packages still maintained in
> svn to git :-) (nvidia-cuda-toolkit and nvidia-graphics-drivers, both in
> non-free)
>
> The upstream tarballs contain binary blobs, and cannot be maintained in git
> (or with pristine-tar) due to their incredible size, so I'm going to use
> overlays and keep only debian/* in git.
> There is one tarball per architecture, so we have to deal with multiple
> .orig-*.tar.gz components as well.
>
> For some parts of the packaging work (e.g. working with patches) I need
> to create a temporary tree including unpacked upstream tarballs
> overlayed with the debian directory and copy back the modifications to
> debian/, this was previously done with svn-do.
>
> (I always build the packages in pbuilder environments, never on the host,
> so there is always exporting used for building and I usually don't need
> (or want) a (non-temporary) full source tree on the host)
>
> The following command works as a start:
>
> gbp buildpackage --git-export=WC --git-builder='env debian_chroot="gbp-do"
> ${SHELL}' --git-postbuild='cp -vuapf "${GBP_BUILD_DIR}/debian/"* "debian/"'
> --git-notify=off
>
> the other relevant options come from debian/gbp.conf:
> [buildpackage]
> overlay = True
> export-dir = ../build-area
> create-orig = False
> pristine-tar = False
> compression = gz
> tarball-dir = ../tarballs-nvidia-cuda-toolkit
> component = [ 'ppc64el', ]
>
>
> It would be great if such functionality could be added as a new
> subcommand. Or do you have a better suggestion how to implement such a
> workflow?
I'm not familiar with svn-do so please bear with me. Looking at:
https://manpages.debian.org/stretch/svn-buildpackage/svn-do.1.en.html
we could add a "gbp overlay-do". Let's use this bug number for sorting
this out.
> Here are the issues I've encountered so far:
>
> * only the main .orig.tar.gz is unpacked, but the sub-components
> .orig-*.tar.gz are not
This is true and I've cloned the bug to get a new number.
> * since exporting does not preserve timestamps, always the full debian/
> tree will be copied back (unlike svn-do)
I'm not sure what you mean here. Preserve timestamps of what exactly the
exported debian dir? The copying back would be done by gbp-do? I you
think there's s.th. wrong already (even with a gbp overlay-do) please
clone this bug so we can work out the details there.
> * in case of failure, the --git-builder command is used as a python
> format string:
>
> ...$ gbp buildpackage --git-export=WC --git-builder='env
> debian_chroot="gbp-do" ${SHELL}' --git-postbuild='cp -vuapf
> "${GBP_BUILD_DIR}/debian/"* "debian/"' --git-notify=off
> gbp:info: Exporting 'WC' to '/path/to/package/build-area/package-tmp'
> gbp:info: Moving '/path/to/package/build-area/package-tmp' to
> '/path/to/package/build-area/package-1.0'
> (gbp-do)...$ exit 1
> exit
> Traceback (most recent call last):
> File "/usr/bin/gbp", line 151, in <module>
> sys.exit(supercommand())
> File "/usr/bin/gbp", line 147, in supercommand
> return module.main(args)
> File "/usr/lib/python3/dist-packages/gbp/scripts/buildpackage.py", line
> 550, in main
> )(dir=build_dir)
> File "/usr/lib/python3/dist-packages/gbp/command_wrappers.py", line 248, in
> __call__
> Command.__call__(self, list(*args))
> File "/usr/lib/python3/dist-packages/gbp/command_wrappers.py", line 192, in
> __call__
> self._log_err()
> File "/usr/lib/python3/dist-packages/gbp/command_wrappers.py", line 145, in
> _log_err
> log.err(self._format_err())
> File "/usr/lib/python3/dist-packages/gbp/command_wrappers.py", line 159, in
> _format_err
> err_reason=self.err_reason)
> KeyError: 'SHELL'
This is sad but true and I've cloned the bug to get a new number.
>
> * Is it possible to use an upstream-version subdirectory for the
> tarball-dir? E.g.
> tarball-dir = ../tarballs-nvidia-cuda-toolkit/%{upstream-version}
We're not doing any expansion on the tarball-dir. If this is a desireable
feature let's please move this into a separate wishlist bug.
Cheers,
-- Guido
