Package: dgit Version: 9.16 Prior to dgit 9.16, dgit would not tolerate (with 3.0 (quilt)) (a) treechanges involving the creation of executable files (b) treechanges involving file executability changes
In #949675 it was reported that this made dgit unable to handle an actual package: a version of glibc, as it happens. In response I committed: a0ac573f8359 "dgit: tolerate making quilt patches creating +x files" I evidently at the time thought that the fact that this package actually existed and did this was sufficient to know that all would be well and I could relax the check. So I did so. There was a test case, testing that this was rejected. Foolishly, I just dropped the test. This was because I thought (and indeed I still think) that what is accepted by dpkg-source actually depends on whatever the installed version of diff does. For 1.0, dpkg-source carefully validates diffs to check they have nothing untoward; for 3.0 it delegates completely to diff - leading to uncontrolled introduction of source package features which don't work on older versions of Debian. I must have thought that the test failure was for this reason. However, there is a flaw in this reasoning. The fact that dpkg-source can extract these things (on at least some versions of Debian) does not mean that it can create them. Now that I investigate #995056, I find that it cannot. Empirically, dpkg-source claims that there are no changes to represent. I believe the situation with treechanges (a) (#949675) and (b) #995056 is the same. Looking at the patches in the glibc_2.32-4 source package, I find that debian/patches/git-updates.diff is like this: GIT update of https://sourceware.org/git/glibc.git/release/2.32/master from glibc-2.32 diff --git a/NEWS b/NEWS index 485b8ddffa..2afe250ccf 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,25 @@ See the end for copying conditions. ... diff --git a/sysdeps/x86_64/configure b/sysdeps/x86_64/configure old mode 100644 new mode 100755 index 84f82c2406..fc1840e23f Whereas a dpkg-source-generated patch is like this: Description: <short summary of the patch> TODO: Put a short summary on the line above and replace this paragraph ... Author: Ian Jackson <ijack...@chiark.greenend.org.uk> --- The information above should follow the Patch Tagging Guidelines, please ... Origin: <vendor|upstream|other>, <url of original patch> Bug: <url in upstream bugtracker> ... Last-Update: 2022-08-25 --- /dev/null +++ example-1.1/newx @@ -0,0 +1 @@ +hi This is a mess. I think it means that dpkg-source cannot rely (solely or mostly) on dpkg-source for constructing debian/patches because the other tools people are using are strictly more powerful - and we need to match their feature set. Relaxing the check in dgit worked for Peter because he didn't need to actually manipulate any of the dpkg-source-unmanipulatable patches. My attempt to introduce a test case for this situation failed because it involved actually creating a new patch. I think the problem is in `quiltify_dpkg_commit`. Maybe the answer is to give up on dpkg-source --commit entirely. The only call sites are in quiltify whichruns in a playtree. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
