Debian Bug report logs - #983138
ypserv: path to "bash" varies on usrmerge system

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: submit@bugs.debian.org

Subject: ypserv: path to "bash" varies on usrmerge system

Date: Fri, 19 Feb 2021 14:38:09 -0800

[Message part 1 (text/plain, inline)]

Source: ypserv
Severity: normal
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: usrmerge shell
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org

The configure script sets the BASH variable to /bin/sh when run on a
usrmerge system, resulting in the pwupdate script differing between
builds:

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

  ./usr/lib/yp/pwupdate
  
  #!/bin/bash
  vs.
  #!/bin/sh


Patch attached which passes BASH=/bin/bash to configure, to ensure a
consistent build regardless of if it is built on a usrmerge system.


Thanks for maintaining ypserv!


live well,
  vagrant

[0002-debian-rules-Pass-BASH-variable-to-configure.patch (text/x-diff, inline)]

From 4e0d9081842ed5b89c6be333ef0c14fce16503c4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagrant@reproducible-builds.org>
Date: Fri, 19 Feb 2021 22:28:16 +0000
Subject: [PATCH 2/2] debian/rules: Pass BASH variable to configure.

The configure script records the path to "bash" as /bin/sh when built
on a usrmerge system. Consistently use /bin/bash as this is the most
compatible path and avoids assumptions about the shell.

https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 48637c1..ffe1fca 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,8 @@ gen-manpages:
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure
+	# Ensure BASH variable consistently is /bin/bash
+	dh_auto_configure -- BASH=/bin/bash
 	for f in `find $(CURDIR) -name '*.8.xml'`; \
 		do d=`dirname $$f`; n=`basename $$f .xml`; [ -f $(CURDIR)/$$d/$$n ] || cp -f $(CURDIR)/debian/man/$$n $$d/.; done 
 
-- 
2.20.1

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 983138@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 983138@bugs.debian.org

Cc: Vagrant Cascadian <vagrant@reproducible-builds.org>

Subject: Re: Bug#983138: ypserv: path to "bash" varies on usrmerge system

Date: Sun, 17 Jul 2022 13:52:46 +0100

On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
> The configure script sets the BASH variable to /bin/sh when run on a
> usrmerge system, resulting in the pwupdate script differing between
> builds:
> 
>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
> 
>   ./usr/lib/yp/pwupdate
>   
>   #!/bin/bash
>   vs.
>   #!/bin/sh

In general, the Debian technical committee resolution
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
treating this class of bug as release-critical for Debian 12.

However, without knowing anything about the specifics of this package,
I'm unsure whether this specific bug is RC or not: will the pwupdate
script still work correctly with a purely POSIX shell like dash? If it
does not, then the severity of this bug should be raised to serious.

Regardless of whether this is RC or not, it would be great to have it fixed
for Debian 12. Vagrant's patch looks appropriate.

Thanks,
    smcv

Message #15 received at 983138@bugs.debian.org (full text, mbox, reply):

From: "Francesco P. Lovergine" <frankie@debian.org>

To: Simon McVittie <smcv@debian.org>, 983138@bugs.debian.org

Cc: Vagrant Cascadian <vagrant@reproducible-builds.org>

Subject: Re: Bug#983138: ypserv: path to "bash" varies on usrmerge system

Date: Fri, 5 Aug 2022 09:15:42 +0200

On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
>> The configure script sets the BASH variable to /bin/sh when run on a
>> usrmerge system, resulting in the pwupdate script differing between
>> builds:
>>
>>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
>>
>>   ./usr/lib/yp/pwupdate
>>
>>   #!/bin/bash
>>   vs.
>>   #!/bin/sh
>
>In general, the Debian technical committee resolution
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
>treating this class of bug as release-critical for Debian 12.
>
>However, without knowing anything about the specifics of this package,
>I'm unsure whether this specific bug is RC or not: will the pwupdate
>script still work correctly with a purely POSIX shell like dash? If it
>does not, then the severity of this bug should be raised to serious.
>
>Regardless of whether this is RC or not, it would be great to have it fixed
>for Debian 12. Vagrant's patch looks appropriate.
>
>Thanks,
>    smcv

The patch looks good enough to fix the pwupdate generation. In any case, the
script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks indifferent.

-cheers

-- 
Francesco P. Lovergine

Message #20 received at 983138@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: "Francesco P. Lovergine" <frankie@debian.org>, Simon McVittie <smcv@debian.org>, 983138@bugs.debian.org

Subject: Re: Bug#983138: ypserv: path to "bash" varies on usrmerge system

Date: Fri, 05 Aug 2022 09:23:48 -0700

[Message part 1 (text/plain, inline)]

On 2022-08-05, Francesco P. Lovergine wrote:
> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
>>> The configure script sets the BASH variable to /bin/sh when run on a
>>> usrmerge system, resulting in the pwupdate script differing between
>>> builds:
>>>
>>>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
>>>
>>>   ./usr/lib/yp/pwupdate
>>>
>>>   #!/bin/bash
>>>   vs.
>>>   #!/bin/sh
>>
>>In general, the Debian technical committee resolution
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
>>treating this class of bug as release-critical for Debian 12.
>>
>>However, without knowing anything about the specifics of this package,
>>I'm unsure whether this specific bug is RC or not: will the pwupdate
>>script still work correctly with a purely POSIX shell like dash? If it
>>does not, then the severity of this bug should be raised to serious.
>>
>>Regardless of whether this is RC or not, it would be great to have it fixed
>>for Debian 12. Vagrant's patch looks appropriate.
>>
>>Thanks,
>>    smcv
>
> The patch looks good enough to fix the pwupdate generation. In any case, the
> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks indifferent.

Given that it's the BASH variable, I figured using /bin/bash would make
more sense and allow consistent builds.

Oddly, it appears to be build reproducibly currently even though no
source changes happened between bullseye and bookworm (both currently
version 4.1-2):

  https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ypserv.html


So something changed back in March ... the toolchain? The reproducible
builds infrastructure? hrm.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 983138@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: "Francesco P. Lovergine" <frankie@debian.org>, Simon McVittie <smcv@debian.org>, 983138@bugs.debian.org

Subject: Re: Bug#983138: ypserv: path to "bash" varies on usrmerge system

Date: Fri, 05 Aug 2022 10:20:23 -0700

[Message part 1 (text/plain, inline)]

On 2022-08-05, Vagrant Cascadian wrote:
> On 2022-08-05, Francesco P. Lovergine wrote:
>> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
>>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
>>>> The configure script sets the BASH variable to /bin/sh when run on a
>>>> usrmerge system, resulting in the pwupdate script differing between
>>>> builds:
>>>>
>>>>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
>>>>
>>>>   ./usr/lib/yp/pwupdate
>>>>
>>>>   #!/bin/bash
>>>>   vs.
>>>>   #!/bin/sh
>>>
>>>In general, the Debian technical committee resolution
>>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
>>>treating this class of bug as release-critical for Debian 12.
>>>
>>>However, without knowing anything about the specifics of this package,
>>>I'm unsure whether this specific bug is RC or not: will the pwupdate
>>>script still work correctly with a purely POSIX shell like dash? If it
>>>does not, then the severity of this bug should be raised to serious.
>>>
>>>Regardless of whether this is RC or not, it would be great to have it fixed
>>>for Debian 12. Vagrant's patch looks appropriate.
>>>
>>>Thanks,
>>>    smcv
>>
>> The patch looks good enough to fix the pwupdate generation. In any case, the
>> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks indifferent.
>
> Given that it's the BASH variable, I figured using /bin/bash would make
> more sense and allow consistent builds.
>
> Oddly, it appears to be build reproducibly currently even though no
> source changes happened between bullseye and bookworm (both currently
> version 4.1-2):
>
>   https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ypserv.html


> So something changed back in March ... the toolchain? The reproducible
> builds infrastructure? hrm.

From some local testing, this doesn't actually appear to be a usrmerge
issue, but a /bin/sh -> /bin/bash vs. /bin/sh -> /bin/dash issue.


I'm not sure why the reproducible builds infrastructure doesn't catch
this, will look into it...


Regardless, the patch would make the package build reproducibly, and
would be great to apply.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.