Control: tags -1 unreproducible moreinfo On Mon, 2016-01-11 at 17:07:43 +0200, Apollon Oikonomopoulos wrote: > Package: libdpkg-perl > Version: 1.18.4 > Severity: normal
> The quilt package format's check_patches_applied() silently fails to > apply patches if the first patch in the series emits a warning. An > example is the current version of python-letsencrypt (0.1.1-3), whose > first patch in the series patches a file twice - thus emitting a > warning: > > tmp/letsencrypt-0.1.1 $ dpkg-source --before-build . > dpkg-source: warning: diff > 'letsencrypt-0.1.1/debian/patches/permission-failures.patch' patches file > letsencrypt-0.1.1/letsencrypt/plugins/webroot_test.py twice > dpkg-source: warning: diff > 'letsencrypt-0.1.1/debian/patches/permission-failures.patch' patches file > letsencrypt-0.1.1/letsencrypt/plugins/webroot_test.py twice > /tmp/letsencrypt-0.1.1 $ > > Re-ordering the patches in the series file leads to the whole series > being applied normally. Since patching the same file twice is a warning > and not an error, it should not stop dpkg-source --before-build from > applying the series. Actually it's patch itself which fails, because in dry-mode it does not keep track of the previous patches that want to modify the same file and does not record the changes w/o actually applying the them. The following command shows the problem: ,--- $ LC_ALL=C LANG=C PATCH_GET=0 patch --dry-run --verbose -t -F0 -N -p1 \ -u -Vnever -b -z .dpkg-orig <debian/patches/permission-failures.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From aa6bf73d4ad828bb87b7f02a0b17e9f98360bb1b Mon Sep 17 00:00:00 2001 |From: Peter Eckersley <p...@eff.org> |Date: Mon, 21 Dec 2015 19:57:12 -0800 |Subject: [PATCH 1/3] Only test permission failures if we're not root | |or, more generally, if we're on a system where permissions are being enforced | |Closes: #1979 |--- | letsencrypt/plugins/webroot_test.py | 11 ++++++++++- | 1 file changed, 10 insertions(+), 1 deletion(-) | |diff --git a/letsencrypt/plugins/webroot_test.py b/letsencrypt/plugins/webroot_test.py |index 9f5b6bb..07e41e0 100644 |--- a/letsencrypt/plugins/webroot_test.py |+++ b/letsencrypt/plugins/webroot_test.py -------------------------- checking file letsencrypt/plugins/webroot_test.py Using Plan A... Hunk #1 succeeded at 66. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.6.4 | |From e41339cda8e8d091f0bc7babbdd9098c7d17a1f7 Mon Sep 17 00:00:00 2001 |From: Peter Eckersley <p...@eff.org> |Date: Mon, 21 Dec 2015 20:01:28 -0800 |Subject: [PATCH 2/3] Keep lint happy | |(But what about py3?) |--- | letsencrypt/plugins/webroot_test.py | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | |diff --git a/letsencrypt/plugins/webroot_test.py b/letsencrypt/plugins/webroot_test.py |index 07e41e0..137a267 100644 |--- a/letsencrypt/plugins/webroot_test.py |+++ b/letsencrypt/plugins/webroot_test.py -------------------------- checking file letsencrypt/plugins/webroot_test.py Using Plan A... Hunk #1 FAILED at 73. 1 out of 1 hunk FAILED Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.6.4 | |From f5cf58f42ef0704a9b4ddf122310527764d727ba Mon Sep 17 00:00:00 2001 |From: Peter Eckersley <p...@eff.org> |Date: Tue, 22 Dec 2015 15:42:53 -0800 |Subject: [PATCH 3/3] with .. open .. as # definitely nicer | |--- | letsencrypt/plugins/webroot_test.py | 5 ++--- | 1 file changed, 2 insertions(+), 3 deletions(-) | |diff --git a/letsencrypt/plugins/webroot_test.py b/letsencrypt/plugins/webroot_test.py |index 137a267..defe939 100644 |--- a/letsencrypt/plugins/webroot_test.py |+++ b/letsencrypt/plugins/webroot_test.py -------------------------- checking file letsencrypt/plugins/webroot_test.py Using Plan A... Hunk #1 FAILED at 67. 1 out of 1 hunk FAILED Hmm... Ignoring the trailing garbage. done `--- I guess the only thing I can do here is error out whenever the first diff patches a file multiple times. In any case you should fix this in the source package, either by merging the hunks into a single patch (what's the point of a patch series correcting the same previously introduced changes anyway? :), or by splitting the different patches into independent files. Or rearranging the patch as you mentioned. Thanks, Guillem
