#1143511 want better error for pristine-tar .gitattributes lossage

#1143511#5
Date:
2026-08-02 02:18:44 UTC
From:
To:
Dear Maintainer,

Thanks for adding pristine-tar support to tag2upload; it's nice to be
able to maintain compatiblity with the workflows of others and also use
tag2upload.

In uploading python-bumps 1.0.5-1 yesterday, the builder failed to
recreate the tarball using pristine-tar. The output doesn't give me any
clues as to why it failed:

builder:work$ tag2upload-obtain-origs p=python-bumps v=1.0.5-1 s=unstable u=c93c353afa3bf91c2f9e14052413bb2e2c24daea pristine_tar=d65b577f8d41cd09eb7f357690593e945b26cfd9
+ dgit --build-products-dir=../bpd -ppython-bumps download-unfetched-origs --write-sha256sums=.git/dgit/t2uoo/origs.sha256sums
canonical suite name for unstable is sid
package in target suite is different upstream version, 1.0.3
no .origs for package python-bumps upstream version 1.0.5
# no orig(s) in archive, generating
+ pristine-tar checkout -- ../bpd/python-bumps_1.0.5.orig.tar.gz
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
pristine-tar: Failed to reproduce original tarball. Please file a bug report.
pristine-tar: failed to generate tarball
t2u processor [dgit-repos-server]: failed command: ./ssh-builder 'tag2upload-builder@tag2upload-builder-01.debian.org' 'env -C /srv/builder.tag2upload.debian.org/tmp/autopkgtest-virt-docker.shared.0b093mpr/downtmp/work tag2upload-obtain-origs p=python-bumps v=1.0.5-1 s=unstable u=c93c353afa3bf91c2f9e14052413bb2e2c24daea pristine_tar=d65b577f8d41cd09eb7f357690593e945b26cfd9'
tag2upload-obtain-origs failed, failed with error exit status 1


Running locally, pristine-tar checkout works just fine:

$ pristine-tar checkout -- ../python-bumps_1.0.5.orig.tar.gz
pristine-tar: successfully generated ../python-bumps_1.0.5.orig.tar.gz


I'm not sure if it's something about this particular tarball, this
particular git repo, or one of the odd little corners of pristine-tar
that has led to this failure.

regards
Stuart

#1143511#10
Date:
2026-08-02 11:48:58 UTC
From:
To:
Hi.  Thanks for the report.

Stuart Prescott writes ("Bug#1143449: git-debpush: pristine-tar checkout failed on builder (but works locally)"):

I'm afraid I have no idea what this means.

These all seem plausible explanations.

I suspect different versions behaviour differently.  The tag2upload
source package construction currently runs largely on stable.

I'm afraid I don't have time to try a local repro and experiment with
different versions right now.  I might have some time for that
tomorrow.  But if you felt like telling what it does for you on stable
(if that's not what you're running) that would be very helpful.

Thanks,
Ian.

#1143511#15
Date:
2026-08-03 00:55:04 UTC
From:
To:
Hi Ian
itself from sid so that I could try out the new pristine-tar workflow
but the machine is otherwise all trixie)

Versions of packages pristine-tar depends on:
ii  bzip2                    1.0.8-6
ii  libbz2-1.0               1.0.8-6
ii  libc6                    2.41-12+deb13u4
ii  libsys-cpuaffinity-perl  1.13~03-2+b4
ii  pbzip2                   1.1.13-1
ii  perl                     5.40.1-6
ii  pixz                     1.0.7-4
ii  tar                      1.35+dfsg-3.1
ii  xdelta                   1.1.3-10.7
ii  xdelta3                  3.0.11-dfsg-1.2
ii  xz-utils                 5.8.1-1+deb13u1
ii  zlib1g                   1:1.3.dfsg+really1.3.1-1+b1

pristine-tar and xdelta3 seem most relevant and have the same versions
in trixie and sid.

Looking at this particular repo - there is a .gitattributes file - how
is the pristine-tar orig-generating path interacting with .gitattributes?

regards
Stuart

#1143511#20
Date:
2026-08-03 10:33:45 UTC
From:
To:
Hi, gbp maintainers.

It seems that gbp import-orig doesn't currently arrange that
transforming .gitattributes are disabled.  This can cause disrepancies
if upstrem origs contain files with crlf with `text` .gitattributes.

Discussion of a particular case is below and earlier in this bug.
This relates to tag2upload job 5586 and python-bumps:
https://salsa.debian.org/science-team/python-bumps.git

Stuart Prescott writes ("Bug#1143449: git-debpush: pristine-tar checkout failed on builder (but works locally)"):
works for me iff one doesn't suppress gitattributes.

In this package, considering line endings in doc/make.bat:

Line endings are CRLF in:
 * python-bumps_1.0.5.orig.tar.gz in the Debian archive.
 * the extracted source package for 1.0.5-1 (which Stuart presumably
   made and uploaded with a traditional gbp and dput based workflow).

Line endings are newlines in
 * upstream/1.0.5 tag, presumably generated by gbp import-orig.
   (Stuart, can yhou confirm, and tell us the version?)
 * salsa master branch and debian/1.0.5-1 tag.

So the source package, as built on the buildds, contains carriage
returns, but the working git branch, as the maintainers work with
locally, contains newlines!  I think this is unintended and
undesirable.  (Although, here, it's probably harmless.)

(AFAICT actual upstream git is not being used here so isn't relevant,
but presuambly it has linefeeds.  Four other files are affected too.)

I don't fully understand how pristine-tar works but I think the
overall mechanism of this failure was something like this:

 1. gbp import-orig does not suppress gitattributes.  AIUI nowadays
    gbp mostly does suppress gitattributes, so this is surprising.

    As a result, the imported git tree has newlines for this file,
    even though the tarball had carriage returns.  (Due to the `text`
    attribute which "normalises" line endings on checkin.)

    So pristine-tar makes a "baseline" .tar.gz file based on a
    git-archive, with carriage returns in, and generates an xdelta
    between that and the actual orig.

 2. When trying to regenerate the tarball, tag2upload *does*
    suppress gitattributes.  It does this right at the beginning,
    before running pristine-tar or checking anything out.

    pristine-tar (which is influenced by the local tree's settings)
    invoked by t2u generates a "baseline" .tar.gz file with newlines.

    Then pristine-tar runs xdelta to apply the .delta (a binary patch)
    but the binary patch doesn't apply because the baseline is wrong:
    the tarball with newlines doesn't match the one with crlf.

Although my view is that defusing .gitattributes is essential for
reliability, it can be controversial.  (See #1092800, #1079434.)

I think the gbp maintainers will agree with me that the output of gbp
import-orig was wrong in this case.  I guess they will probably want
to change gbp import-orig.  So I'm reassigning this bug there.

IMO pristine-tar ought not to be influenced in this way by
.gitattributes nor by local git configuration.  That just makes an
already-fragile tool more exposed to strsngeness and lossage.  I don't
know if the pristine-tar maintainers will agree; CCing them.  But a
change to pristine-tar wouldn't be suffiicent, since we need the
Debian `upstream/` git branch to contain un-transformed files.  (Eg,
if instead of tag2upload, Stuart had used `dgit push-source`, dgit
would have detected and reported this discrepancy, and failed.)

The error message Stuart got from the t2u service here is very bad.
I think we could probably do some hinting.  I'll clone this bug for
that.  See also #1115853.

Thanks to Stuart for the report and to everyone else for your
attention.

Ian.

#1143511#33
Date:
2026-08-04 15:05:46 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
dgit, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143511@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ian Jackson <ijackson@chiark.greenend.org.uk> (supplier of updated dgit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 04 Aug 2026 14:33:49 +0100
Source: dgit
Architecture: source
Version: 16.5
Distribution: unstable
Urgency: medium
Maintainer: Debian tag2upload Delegates <dgit-owner@debian.org>
Changed-By: Ian Jackson <ijackson@chiark.greenend.org.uk>
Closes: 1143511 1143562
Changes:
 dgit (16.5) unstable; urgency=medium
 .
   tag2upload development:
   * tag2upload-obtain-origs: Allow tildes in pristine-tar filenames
     Closes: #1143562.
   * tag2upload-obtain-origs: Give advice about gitattributes if
     pristine-tar fails, when applicable.  Closes: #1143511.
Checksums-Sha1:
 b167633f6b8249be978fd428e7061c4a333baf3a 2533 dgit_16.5.dsc
 3643e0904e4acb58e297a4afd82dff08ed89a3ca 1067653 dgit_16.5.tar.gz
 8e9108ceba900b1b876ab0abeaca9eeff5e8a268 1371196 dgit_16.5.git.tar.xz
 f1ae1bf1a252892f01f37646184d57a6079aa05f 17528 dgit_16.5_source.buildinfo
Checksums-Sha256:
 95957df1f3fd34f9dc3c0f7390b7ecec31d7bf425eae1a6d63f607a981a076cb 2533 dgit_16.5.dsc
 f73915e8b10188b5484f5f6f8bbf08a8e9916057bc9430f1b3408d766a675cab 1067653 dgit_16.5.tar.gz
 305d3725f77ea5384e026b28e2d2c58f15a6ab33dab89650120296d835c24148 1371196 dgit_16.5.git.tar.xz
 911b59bd96387fefba9e8f4a413fb0a7145ecf0ec66aa87068ee92333fe924fc 17528 dgit_16.5_source.buildinfo
Files:
 00836a7a7b3e59a39861a71ebc7201fc 2533 devel optional dgit_16.5.dsc
 17bb0640f98b454ce16b70a33175e56a 1067653 devel optional dgit_16.5.tar.gz
 945ac01a62e00c29552f4cdb207e6464 1371196 devel optional dgit_16.5.git.tar.xz
 038a23bc80b90c545a6a9d660b0997d7 17528 devel optional dgit_16.5_source.buildinfo
Git-Tag-Info: tag=173d9a4b94dbd707510e63d2d3a7e398b5e3c15d fp=41638114d132883b25a20ddd47515757d8002456
Git-Tag-Tagger: Ian Jackson <ijackson@chiark.greenend.org.uk>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmpx+UYACgkQYG0ITkaD
wHn0pxAAy4XGdMgp0l3aARUIfV4zKxvlab4CjH8O2UqHSiJoF1nGB/rVzqhG1gqk
NtbrYfFNN/PohEnO/GytP00Nt7duJcOnP73m0GYyQodNdkVJaIeftnHg5migqa0E
bSDq8fxBK1PDMYsnVUDXr8Cy28MGGuBIMDMTvgjQpchlPxvNbLQUKxuOlasB9xN+
qUpx25xhm2l4BDbMEDa0P/ZOjg7NWUTHCxiP0sQyfS5URVNalBeudsZ0cCpEwKgn
Zs6t+nMw5unL4H17am06ppef8nnI+/J0HUltJ/TY3XPTQMtjR2XeljNMXVmjUePj
XsqtmoN1cOBiKHkBWEbJsMtOv/EaKZrrwEdiln/joN+stj55/noB90HsGMjLyiUt
JrRcvldPeu3bR48LNgl/Ruyok+kGuyxvsrkJunWOjA/syx4O1H5d0c/Wz7l4NpRP
mdPFFsmKwe003eN3iWK171HnlWk4XamwtZsuMSGVsvjtFd7mcrcQ8rWZrfj89Kne
Ut9KdWDtkBhKnap3RArj/4XmGRUh0k2SQGuDvSLhMPLguVr8vfsvQrESSo9s5dgE
a35Py++rTC8k6nmbzORHWJ1lD5iB6e3UdZq9rFiPBKfW1QymDl0rq7VJCDKK9iqZ
/iaSJwQ0nYkTdJwV+Fp9I0TSGYXFvkuv16F2aik0xM/4ujkK1jY=
=kf47
-----END PGP SIGNATURE-----