Skip to contentSkip to conversation

sanity.bbclass: check /bin/sh is dash or bash

PATCH In review Robert Yang 4 participants 7 messages Jun 26, 2015 – Jun 29, 2015

lore
Share & tools
lore
#0 lore raw

cover sanity.bbclass: check /bin/sh is dash or bash

The following changes since commit 2587b83faabdc8858e8746201805369ed8d53ba8:

wpa-supplicant: Revert "Make SystemD D-Bus config conditional" (2015-06-24 14:03:25 +0100)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib rbt/sh
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/sh

Robert Yang (1):
sanity.bbclass: check /bin/sh is dash or bash

 meta/classes/sanity.bbclass |    4 ++++
 1 file changed, 4 insertions(+)
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH 1/1 sanity.bbclass: check /bin/sh is dash or bash

The build would fail when /bin/sh links to ksh or csh, we only test dash and bash AFAIK.

* When /bin/sh -> csh:

  $ bitbake quilt-native
$ bitbake quilt-native -cfetch
Illegal variable name.
Illegal variable name.
[snip]
uname: extra operand `2'
Try `uname --help' for more information.

* When /bin/sh -> ksh:
If there are only a few tasks running, for example,
"bitbake quilt-native", the build would be OK, but it would fail if we
run "bitbake world" for a while, there would be a lot of "Broken pipe"
errors:
Exception: CalledProcessError: Command
'cd /path/to/xx; find . -type d -print | tar -cf - -C /path/to/sysroot-destdir -p --files-from - --no-recursion | tar -xf - -C /path/to/xxx' returned non-zero exit status 2 with output tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
find: `standard output': Broken pipe
find: write error

[YOCTO #7917]

---
 meta/classes/sanity.bbclass |    4 ++++
 1 file changed, 4 insertions(+)
meta/classes/sanity.bbclass +4 -0
index d9eff90..2855941 100644
@@ -835,6 +835,10 @@ def check_sanity_everybuild(status, d):
     if 'vdi' in d.getVar('IMAGE_FSTYPES', True) and 'live' in d.getVar('IMAGE_FSTYPES', True):
         status.addresult("Error, IMAGE_FSTYPES vdi and live can't be built together\n")
 
+    # Check /bin/sh links to dash or bash
+    real_sh = os.path.realpath('/bin/sh')
+    if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
+        status.addresult("Error, /bin/sh links to %s, must be dash or bash\n" % real_sh)
 
 def check_sanity(sanity_data):
     class SanityStatus(object):
Signature · 1 line
1.7.9.5
#2 lore raw
Quoted 3 lines · Robert Yang

The build would fail when /bin/sh links to ksh or csh, we only test dash and bash AFAIK.

Hmm, would this break self-hosted builds, as you don’t check for busybox, or am I missing something? Not that I’ve ever done a build like that, other than using the old build appliance, and I don’t know much about how that was built, but maybe someone else knows better than I :)

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#3 lore raw
Quoted 7 lines · Christopher Larson

On Thu, Jun 25, 2015 at 11:23 PM, Robert Yang <[email protected]> wrote:
The build would fail when /bin/sh links to ksh or csh, we only test dash
and bash AFAIK.

Quoted 5 lines

Hmm, would this break self-hosted builds, as you don’t check for busybox, or am I missing something? Not that I’ve ever done a build like that, other than using the old build appliance, and I don’t know much about how that was built, but maybe someone else knows better than I :)

I think since that is a "developer" focused image it likely has bash in it so the check will probably work there (since bash has priority over ash). Good thought though.

Cheers,

Richard

#4 lore raw
In reply to Robert Yang
Quoted 3 lines · Robert Yang

The build would fail when /bin/sh links to ksh or csh, we only test dash and bash AFAIK.

csh definitely isn't a suitable candidate for /bin/sh, and I doubt ksh is too. Are people really doing this? They're just wrong... I seriously doubt Linux would boot with /bin/sh->csh and ksh would be asking for trouble.

Was this a real world problem, or a hypothetical problem?

Ross

#5 lore raw
Quoted 11 lines · Ross

On 26 June 2015 at 07:23, Robert Yang <[email protected] <mailto:[email protected]>> wrote:

The build would fail when /bin/sh links to ksh or csh, we only test dash and bash AFAIK.

csh definitely isn't a suitable candidate for /bin/sh, and I doubt ksh is too. Are people really doing this? They're just wrong... I seriously doubt Linux would boot with /bin/sh->csh and ksh would be asking for trouble.

Hi Ross,

Yes, Ubuntu would not boot well when /bin/sh -> ksh or csh, I just took them as an example, I think that we only test on bash or dash, so I think that this checking can reduce the potential errors, and I think that we also need check SHELL, I will test and send another patch.

// Robert

Quoted 4 lines

Was this a real world problem, or a hypothetical problem?

Ross

#6 lore raw
Quoted 15 lines · Robert Yang
Quoted 11 lines · Ross

On 26 June 2015 at 07:23, Robert Yang <[email protected] <mailto:[email protected]>> wrote:

The build would fail when /bin/sh links to ksh or csh, we only test dash and bash AFAIK.

csh definitely isn't a suitable candidate for /bin/sh, and I doubt ksh is too. Are people really doing this? They're just wrong... I seriously doubt Linux would boot with /bin/sh->csh and ksh would be asking for trouble.

Quoted 6 lines

Hi Ross,

Yes, Ubuntu would not boot well when /bin/sh -> ksh or csh, I just took them as an example, I think that we only test on bash or dash, so I think that this checking can reduce the potential errors, and I think that we also need check SHELL, I will test and send another patch.

I confirmed that the build is OK when set SHELL to /bin/ksh or /bin/csh, so we don't have to check SHELL.

Quoted 7 lines

// Robert

Quoted 4 lines

Was this a real world problem, or a hypothetical problem?

Ross