Control: clone -1 -2 Control: retitle -2 want better error for pristine-tar .gitattributes lossage Control: reassign -2 dgit-infrastructure Control: retitle -1 please defuse gitattributes in gbp import-orig Control: reassign -1 git-buildpackage
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)"): > Looking at this particular repo - there is a .gitattributes file - how > is the pristine-tar orig-generating path interacting with .gitattributes? Stuart is on the right track. I discovered that pristine-tar checkout 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. -- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
