Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Simon McVittie]

Control: retitle -1 freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

On Tue, 24 Sep 2024 at 19:41:09 +0200, Santiago Vila forwarded:
> deutex does not support PNG. Try building deutex with the PNG
> libraries (libpng and libpng-devel or similar packages) installed.
...
> make[2]: *** [Makefile:56: deutex-check] Error 1

I can reproduce this, but I don't understand it.

I can reproduce this if I tell sbuild (in my case bookworm's sbuild in a
bookworm VM) to rebuild the .dsc from the archive, mimicking an official
buildd, which I believe is also what Santiago's mass-rebuilds are doing.

However, I can't reproduce the failure if I rebuild the .dsc (no content
changes!), and then tell sbuild to build *that*.

The rebuilds done by the reproducible-builds infrastructure are also not
reproducing this build failure, as far as I can see.

The failure is that the upstream build system runs
`deutex -h | grep -qw PNG` and asserts that the exit status is 0 (i.e. the
help mentions PNG somewhere), as a way to fail early if built by a version
of deutex that was built without PNG support.

The version of deutex in Debian *is* built with PNG support, and does
mention it in help output; and both of my rebuilds (successful and failing)
are using the same version of deutex that was seen in Santiago's build log.
So I would have expected that all three builds would have the same
behaviour, either all successful or all failing.

At first I thought that maybe it wasn't finding /usr/games/deutex in the
PATH, but debian/rules explicitly prepends /usr/games to PATH, and in any
case my sbuild logs say the PATH already included it, the same as in
Santiago's log:

> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

The differences between the .dsc file in the archive and my
locally-rebuilt .dsc file are only timestamps (in my rebuilt .dsc,
dpkg-source has set all timestamps to the ${SOURCE_DATE_EPOCH}), and
the fact that my rebuilt .dsc is unsigned:

--- /home/smcv/tmp/deb/build/freedoom_20240930t094628/freedoom_0.13.0-1.dsc
+++ /home/smcv/tmp/deb/build/freedoom_latest/freedoom_0.13.0-1.dsc
├── GPG header
│ @@ -1,2 +0,0 @@
│ ------BEGIN PGP SIGNED MESSAGE-----
│ -Hash: SHA256
├── Files
│ @@ -1,3 +1,3 @@
│
│   6f391230509aaeb943c5b18f6890af4e 18520091 freedoom_0.13.0.orig.tar.gz
│ - bef1f6130faebd9ff116de20a62a2340 7388 freedoom_0.13.0-1.debian.tar.xz
│ + 3e1c69dc1585b8c8cd8e2b02527266f0 7376 freedoom_0.13.0-1.debian.tar.xz
├── GPG signature
│ @@ -1,17 +0,0 @@
│ ------BEGIN PGP SIGNATURE-----
│ -
│ -iQJGBAEBCAAwFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmW9VK4SHGZhYmlhbkBk
…
│ -=bC4T
│ ------END PGP SIGNATURE-----
├── filetype from file(1)
│ @@ -1 +1 @@
│ -PGP signed message
│ +ASCII text
├── freedoom_0.13.0-1.debian.tar.xz
│ ├── freedoom_0.13.0-1.debian.tar
│ │ ├── file list
│ │ │ @@ -1,10 +1,10 @@
│ │ │  drwxr-xr-x   0        0        0        0 2024-02-02 20:42:23.000000 debian/
│ │ │  -rw-r--r--   0        0        0    12942 2024-02-02 20:42:23.000000 debian/changelog
│ │ │ --rw-r--r--   0        0        0     2137 2024-02-02 20:41:54.000000 debian/control
│ │ │ --rw-r--r--   0        0        0     4458 2024-02-02 20:38:03.000000 debian/copyright
│ │ │ --rwxr-xr-x   0        0        0     1046 2024-02-02 20:12:39.000000 debian/rules
│ │ │ -drwxr-xr-x   0        0        0        0 2024-02-02 20:12:39.000000 debian/source/
│ │ │ --rw-r--r--   0        0        0       12 2024-02-02 20:12:39.000000 debian/source/format
│ │ │ -drwxr-xr-x   0        0        0        0 2024-02-02 20:12:39.000000 debian/upstream/
│ │ │ --rw-r--r--   0        0        0      178 2024-02-02 20:12:39.000000 debian/upstream/metadata
│ │ │ --rw-r--r--   0        0        0      174 2024-02-02 20:41:14.000000 debian/watch
│ │ │ +-rw-r--r--   0        0        0     2137 2024-02-02 20:42:23.000000 debian/control
│ │ │ +-rw-r--r--   0        0        0     4458 2024-02-02 20:42:23.000000 debian/copyright
│ │ │ +-rwxr-xr-x   0        0        0     1046 2024-02-02 20:42:23.000000 debian/rules
│ │ │ +drwxr-xr-x   0        0        0        0 2024-02-02 20:42:23.000000 debian/source/
│ │ │ +-rw-r--r--   0        0        0       12 2024-02-02 20:42:23.000000 debian/source/format
│ │ │ +drwxr-xr-x   0        0        0        0 2024-02-02 20:42:23.000000 debian/upstream/
│ │ │ +-rw-r--r--   0        0        0      178 2024-02-02 20:42:23.000000 debian/upstream/metadata
│ │ │ +-rw-r--r--   0        0        0      174 2024-02-02 20:42:23.000000 debian/watch

I suspect that re-uploading freedoom with no changes other than the
changelog entry, or with only janitorial changes like updating the
Standards-Version, would "accidentally" resolve this - but I don't
understand why the rebuild changes anything.

I'm very tempted to downgrade this to non-RC, on the basis that the build
failure is not preventing binNMUs (this package is Architecture: all
and therefore can't be binNMU'd anyway), is not preventing maintainer
uploads (any change, even a trivial one, seems to make the build succeed),
and is not preventing users from exercising their right to modify the
package locally (same reason).

    smcv