Bug#983208: lynx: embeds path to various binaries that differ with usrmerge
On 2021-02-21 Vagrant Cascadian wrote: > On 2021-02-21, Andreas Metzler wrote: [...] > Thanks for applying. > > I don't get the point of trying to do reproducible builds on systems > > that differ significantly (usrmerge or not), it feels like make-work. > I get that, for sure. > The current reproducible builds test infrastructure is geared towards > finding issues so that we can fix them; some of the issues may seem to > be nuanced corner-cases. > In the case of usrmerge, both usrmerge and non-usrmerge systems exist in > the wild; having fewer variables that affect the build makes it > significantly easier to reproduce a build and more resilient. Bugs > triggered by building in a usrmerge environment have actually resulted > in functionally broken packages in several cases, too, so it does seem > to me important to find them early. Ok, I see. Thankfully we will get rid of that major source of make-work (supporting both usrmerge and unmerged) post bullseye ;-) #981582 Thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#983208: lynx: embeds path to various binaries that differ with usrmerge
On 2021-02-21, Andreas Metzler wrote: > On 2021-02-21 Vagrant Cascadian wrote: >> The paths to various binaries are embedded in /usr/bin/lynx, which >> differs on a usrmerge vs. non-usrmerge system. ... >> Patch attached which passes variables to configure to use the >> non-usrmerge locations, as usrmerge installations typically have >> compatibility symlinks, but not vice-versa. > >> This does not resolve all reproducibility issues (e.g. when /bin/sh >> points to bash), but should reduce some of the noise when comparing the >> differences. > [...] > > Hello, > > Reluctantly applied. Thanks for applying. > I don't get the point of trying to do reproducible builds on systems > that differ significantly (usrmerge or not), it feels like make-work. I get that, for sure. The current reproducible builds test infrastructure is geared towards finding issues so that we can fix them; some of the issues may seem to be nuanced corner-cases. In the case of usrmerge, both usrmerge and non-usrmerge systems exist in the wild; having fewer variables that affect the build makes it significantly easier to reproduce a build and more resilient. Bugs triggered by building in a usrmerge environment have actually resulted in functionally broken packages in several cases, too, so it does seem to me important to find them early. live well, vagrant signature.asc Description: PGP signature
Bug#983208: lynx: embeds path to various binaries that differ with usrmerge
Control: tags -1 pending On 2021-02-21 Vagrant Cascadian wrote: > Source: lynx > Severity: normal > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: usrmerge > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > The paths to various binaries are embedded in /usr/bin/lynx, which > differs on a usrmerge vs. non-usrmerge system. > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/lynx.html > /usr/bin/lynx > "/bin/gzip" > vs. > "/usr/bin/gzip" > Patch attached which passes variables to configure to use the > non-usrmerge locations, as usrmerge installations typically have > compatibility symlinks, but not vice-versa. > This does not resolve all reproducibility issues (e.g. when /bin/sh > points to bash), but should reduce some of the noise when comparing the > differences. [...] Hello, Reluctantly applied. I don't get the point of trying to do reproducible builds on systems that differ significantly (usrmerge or not), it feels like make-work. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#983208: lynx: embeds path to various binaries that differ with usrmerge
Source: lynx Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The paths to various binaries are embedded in /usr/bin/lynx, which differs on a usrmerge vs. non-usrmerge system. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/lynx.html /usr/bin/lynx "/bin/gzip" vs. "/usr/bin/gzip" Patch attached which passes variables to configure to use the non-usrmerge locations, as usrmerge installations typically have compatibility symlinks, but not vice-versa. This does not resolve all reproducibility issues (e.g. when /bin/sh points to bash), but should reduce some of the noise when comparing the differences. live well, vagrant From 65e7a04ed68d33c7adf0a278948f9a7138bb1a69 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 21 Feb 2021 02:29:36 + Subject: [PATCH 1/2] debian/rules: Pass paths to various binaries. Use the non-usrmerge locations for binaries, which works on both usrmerge and non-usrmerge systems. https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html --- debian/rules | 10 ++ 1 file changed, 10 insertions(+) diff --git a/debian/rules b/debian/rules index b0ca680..7e4ca22 100755 --- a/debian/rules +++ b/debian/rules @@ -13,6 +13,15 @@ else CONFTLS := --with-ssl endif +# Ensure the most compatible helper program paths to work on both +# usrmerge and non-usrmerge systems. +BINARY_PATHS += GZIP=/bin/gzip +BINARY_PATHS += UNCOMPRESS=/bin/gunzip +BINARY_PATHS += MV=/bin/mv +BINARY_PATHS += ZCAT=/bin/zcat +BINARY_PATHS += TAR=/bin/tar +BINARY_PATHS += RM=/bin/rm + override_dh_auto_configure: ifeq ($(SSL),gnu) sed -i -e s/libssl-dev/libgnutls28-dev/g debian/control @@ -36,6 +45,7 @@ endif --enable-read-eta --enable-scrollbar --enable-syslog \ --with-zlib --with-bzlib --without-included-gettext \ --with-screen=ncursesw --enable-justify-elts \ + $(BINARY_PATHS) \ $(CONFTLS) override_dh_autoreconf: -- 2.20.1 signature.asc Description: PGP signature
