control: tag -1 +help
control: severity -1 wishlist
Hi,
On Thu, Nov 09, 2017 at 03:37:47PM +0100, Andreas Beckmann wrote:
> On 11/09/2017 01:26 PM, Guido Günther wrote:
> > 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.
>
> source code for svn-do is here:
> https://anonscm.debian.org/viewvc/collab-maint/deb-maint/svn-buildpackage/trunk/contrib/svn-do?revision=23023&view=markup
>
> You'll have at least one user that will test "gbp overlay-do" (although
> I doubt that I'll use something else than the default "$SHELL"
> command)
Since I'm not likely to become a user of it either: could you figure
something out that works for you and keep the bug report up to date with
that? If something is missing in existing tools let me know and once we
have something working we can look into merging it in. Either in
examples/ or as an "official" command.
Cheers,
-- Guido
>
> >
> >> 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.
>
> I noticed that this is a "normal" issue (not related to my attempt to
> get something svn-do alike) the other day when I tried to build
> nvidia-cuda-toolkit on the ppc64el porterbox and half the tree was
> missing, just didn't get around to factor this out as a separate issue.
>
> >> * 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.
>
> I don't think git archive has the opportunity to "preserve" timestamps
> from the WC (seems to be one timestamp for all files, taken from newest
> file (or commit), didn't work out the details) ... but maybe that's
> something that can be "fixed" while copying back.
> I got the "cp -vuapf X Y" from svn-do, maybe something else can be used
> to only copy back files that actually changed content (not just
> timestamp). And deleting disappeared files could be considered as well.
>
> What I was thinking about here was that "cp -vuapf X Y" lists all files
> as copied back (or probably excluding the one that contributed the
> newest timestamp), making that output just noise, so the -v could be
> dropped as well. (With svn-do I usually got a list of files that were
> actually changed, plus some symlinks)
>
> >> * in case of failure, the --git-builder command is used as a python
> >> format string:
>
> > This is sad but true and I've cloned the bug to get a new number.
>
> wasn't sure if I had caused this by some "unsupported" type of command ...
>
> >> * 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.
>
> Not sure if I want to pursue this ... depends on how I'm going to handle
> the storage backend of the tarball-dir (for now it will stay on svn, and
> per-upstream-version subdirectories would have allowed to do more sparse
> svn checkouts, but I'd need to implement something in the package for that).
> But since we can reproducibly build the upstream tarballs, we don't even
> need to go through a central repository any more.
> (btw, the last upstream releases of nvidia-cuda-toolkit were about
> 2.5 GB of blobs per release)
>
>
> Andreas
>
