Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #373089 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG Simon McVittie <smcv@debian.org> - 2024-09-30 12:50 +0200
    Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG Santiago Vila <sanvila@debian.org> - 2024-09-30 13:10 +0200
      Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG Fabian Greffrath <fabian@greffrath.com> - 2024-09-30 16:00 +0200
        Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG Santiago Vila <sanvila@debian.org> - 2024-10-01 03:40 +0200
          Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG Fabian Greffrath <fabian@greffrath.com> - 2024-10-01 07:50 +0200

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

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

[toc] | [next] | [standalone]

#373091

Thanks for the testing. Some more data to consider:

- When I build with 1 CPU, I have never found the build problem so far.
- When I build with 2 CPUs, I got a failure rate of 66%
(16 failures over 24 tries so far).
- Given that 66% > 50%, "does not build from source" is more
true than "builds from source" (so please do not downgrade).

Given the above, my suspect is that this could be a Makefile bug,
and that it will not fix itself by merely doing another upload.

I would try how it behaves when using --no-parallel.

Thanks.

[toc] | [prev] | [next] | [standalone]

#373107

Maybe the `deutex -h` output to stdout get spoiled by other build steps 
running in parralel, so that it doesn't include "PNG" as an isolated 
word anymore?

  - Fabian

[toc] | [prev] | [next] | [standalone]

#373118

[Multipart message — attachments visible in raw view] — view raw

Hi. To test, I simplified the line in the Makefile to this:

deutex -h | grep -qw PNG

This should have the same effect but without the explanatory error message,
i.e. if it fails, make will stop.

The build log for a failed build looks like this:

deutex -h | grep -qw PNG
make -C lumps/dehacked # graphics/text depends on generated dehacked files
make[3]: Entering directory '/<<PKGBUILDDIR>>/lumps/dehacked'
../../scripts/simplecpp -DFREEDM < dehacked.txt > ../fdm_deh.lmp
make[2]: *** [Makefile:56: deutex-check] Error 141
make[2]: *** Waiting for unfinished jobs....

I searched for error 141 and found this:

https://stackoverflow.com/questions/19120263/why-exit-code-141-with-grep-q

So, the error in freedoom seems to happen because of two things:

a) using grep -q
b) The SHELL="bash -Eeuo pipefail" definition in debian/rules.

I don't know what would be the best way to fix this.

Maybe we could just take for granted that deutex has PNG support,
because it has, and drop the check in the toplevel Makefile,
as in the attached patch.

(I withdraw my suggestion to use --no-parallel).

Thanks.

[toc] | [prev] | [next] | [standalone]

#373119

Thank you very much for this update!

Am 2024-10-01 03:26, schrieb Santiago Vila:
> Maybe we could just take for granted that deutex has PNG support,
> because it has, and drop the check in the toplevel Makefile,

Since `deutex-check` isn't declared as a .PHONY rule, I think I can just 
run `touch deutex-check` before the build and be done with it.

  - Fabian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web