#1021456 bwbasic: reproducible-builds: build path embedded in /usr/bin/bwbasic

Package:
src:bwbasic
Source:
src:bwbasic
Submitter:
Vagrant Cascadian
Date:
2024-03-13 09:21:57 UTC
Severity:
normal
Tags:
#1021456#5
Date:
2022-10-08 22:04:54 UTC
From:
To:
The build path is embedded in /usr/bin/bwbasic:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/bwbasic.html

  /build/1st/bwbasic-2.20pl2/bwbasic.c:118
  vs.
  /build/2/bwbasic-2.20pl2/2nd/bwbasic.c:118

The attached patches fix this by adjusting the upstream Makefile to use
the default CFLAGS (by appending the arguments), and disables format
string hardening which causes build failures (and was previously
ignored, as CFLAGS was not used).

According to my local tests, with this patch applied, bwbasic should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining bwbasic!

live well,
  vagrant

#1021456#10
Date:
2024-03-12 22:33:24 UTC
From:
To:
Dear Maintainer,

Because Debian builds packages from a fixed build path, neither the 'reprotest'
utility in Salsa-CI, nor the Reproducible Builds team's package test
infrastructure for Debian[1] currently check for equivalent binary package
output from differing source package build paths.

This means that your package will pass current reproducibility tests; however
we believe that source code and/or build steps still embed the build path into
the binary package output, making it more difficult than necessary for
independent consumers to check the integrity of those packages by rebuilding
them themselves.

As a result, this bugreport will remain open and be re-assigned the 'wishlist'
severity[2].

For more information about build paths and how they can affect reproducibility,
please refer to: https://reproducible-builds.org/docs/build-path/

Thanks,
James

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities

#1021456#17
Date:
2024-03-13 09:18:02 UTC
From:
To:
A correction for a mistake in my previous message:

Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise
variations of the build-path, and will fail if it builds binary packages that
contain different contents as a result.