Hi,
On Mon, Jun 11, 2018 at 02:10:52PM +0200, Jonas Smedegaard wrote:
> Quoting Guido Günther (2018-06-11 13:32:34)
> > Hi,
> > On Mon, Jun 11, 2018 at 11:59:58AM +0200, Jonas Smedegaard wrote:
> > > Quoting Guido Günther (2018-06-11 11:07:33)
> > > > On Mon, Jun 11, 2018 at 11:04:51AM +0200, Guido Günther wrote:
> > > > > On Mon, Jun 11, 2018 at 10:01:44AM +0200, Jonas Smedegaard wrote:
> > > > > > Package: git-buildpackage
> > > > > > Version: 0.9.9
> > > > > > Severity: grave
> > > > > > Justification: causes non-serious data loss
> > > > > >
> > > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > > Hash: SHA512
> > > > > >
> > > > > > "gbp import-orig --uscan" seems to choke on tarballs repacked by
> > > > > > uscan.
> > > > > >
> > > > > > With the attached debian files - changelog, copyright, and watch,
> > > > > > in an freshly created git project (i.e. just "git init"), doing
> > > > > > "gbp import-orig --uscan" will succeed but the resulting project
> > > > > > wil be missing the subdirectories translations and utils.
> > > > > >
> > > > > > Doing same without the copyright file will have all files
> > > > > > imported.
> > > > > >
> > > > > > The repacked tarball do contain the subdirectories, so it seems
> > > > > > gbp chokes on it for some reason.
> > > > >
> > > > > I rather assume thath the copyright file instructs uscan to filter
> > > > > these out?
> > > >
> > > > Oh...and as always: please provide data to reproduce the problem. Your
> > > > package is certainly not the first to be imported with --uscan and
> > > > since it works for some setups it would be good to have your test case
> > > > to find out what's different.
> > >
> > > I believe I did exactly that: Provide files to reproduce the problem.
> >
> > I was expecting a git URL and overread the "attached", found the files
> > now, sorry for the confusion.
> >
> > > Could you elaborate which kind of files you would like me to provide?
> >
> > The tarball generated by uscan "monero_0.12.2.0~dfsg.orig.tar.gz" does
> > not contain the directories you mention. When I run this:
> >
> > $ git branch upstream
> > $ gbp import-orig -v --merge-mode=replace --postimport=/bin/true
> > --no-pristine-tar --no-sign --uscan
> > …
> > $ DIRS='translations|utils' ; tar -list -af
> > monero_0.12.2.0~dfsg.orig.tar.gz | grep -qs -E "(${DIRS})/" || echo
> > "${DIRS} not found"
> > translations|utils not found
> >
> > Can you show me what I'm missing to reproduce this?
>
> Oh - I use Midnight Commander (package mc) to inspect tarballs, and
> apparently that can parse tarballs that tar cannot.
>
> Seems this is an issue of corrupted tarball, then.
>
> I now found a commandline tool that confirms that the dirs exist: Can
> you try confirm by installing package pax and running this command:
>
> paxtar tvzf monero_0.12.2.0~dfsg.orig.tar.gz '*.ts'
>
> At my end, that outputs the following:
>
> -rw-rw-r-- 1 root root 195575 Jun 3 18:41
> monero-0.12.2.0/translations/monero.ts
> -rw-rw-r-- 1 root root 230673 Jun 3 18:41
> monero-0.12.2.0/translations/monero_fr.ts
> -rw-rw-r-- 1 root root 204343 Jun 3 18:41
> monero-0.12.2.0/translations/monero_it.ts
> -rw-rw-r-- 1 root root 224691 Jun 3 18:41
> monero-0.12.2.0/translations/monero_sv.ts
Yeah, I see these with paxtar but given that dpkg (AFAIK) uses plain tar
I wonder if there's a bug here? Can you dig out what makes these files
different and if these are allowed by policy? I tried several of tar's
-H options but this did not change anything and did not find anything
related in Debian policy either.
What is monero using to create the tarball? I quick grep in the sources
didn't bring anything up.
-- Guido
