[OE-core] bash ptests: use runuser? also remaining errors.

[Randy MacLeod]

Richard, et. al.

I have two patches (ptest-runner, bash) that enable all but two [*]
of the bash-ptests to pass. A potential problem is that when started by
ptest-runner, 'su' (both busybox and util-linux versions), results in
a few of bash's tests failing whereas they work if started by 'runuser'.
The test failure is due to a warning:
     bash: cannot set terminal process group (16036): \
           Inappropriate ioctl for device
that contaminates the test logs and makes a diff with the expected
results fail. I can easily redirect that warning to /dev/null but
that seems wrong and would be a patch that we'd have to carry in
oe-core.

To get 'runuser' from util-linux into an image, it seems that you need:
  - the RDEPENDS for ptest,
  - REQUIRED_DISTRO_FEATURES = "pam" in bash.inc, and
  - to set the 'pam' DISTRO_FEATURE in your local.conf.

Is that something you are willing to do for all ptests or perhaps just
for bash's ptests?  If so, I'll clean-up my ptest-runner patch and
send this to the list.


I also considered using util-linux's 'setpriv' but enabling that
has turned into a mess of dependency loops and other build problems.
man runuser:
    If the PAM session is not required then recommended solution
    is to use setpriv(1) command.

Other solutions to properly starting user tests from root are welcome!

Thanks in advance,
-- 
# Randy MacLeod
# Wind River Linux


[*] FYI, the two remaining failures are:

1.
run-read:
   # cat tests/read6.sub
   # test read with a timeout of 0 -- input polling
   # sleep with fractional seconds argument is not universal
   echo abcde | { sleep 0.25 2>/dev/null ; read -t 0; }
   echo $?

   read -t 0 < $0
   echo $?

   read -t 0
   echo $? <-- returns 1, when 0 is expected.

I can reproduce this on my workstation but only when using ptest-runner
and initially logging into the console as root. That's a little odd and
seems like I need to continue to improve ptest-runner.


2.

run-trap:
   # cat tests/trap3.sub
   PS4='+[$LINENO] '
   trap 'echo trap: $LINENO' ERR

   set -x

   echo 1
   echo 2
   echo 3 | cat | false <--- error
   echo 4

This is a scheduler behaviour difference between the common case
on a workstation and the common case in qemu. The test case does
warn about the completion order not being deterministic so I plan
to ignore it.

 From tests/run-trap:
   UNIX versions number signals and schedule processes differently.
   If output differing only in line numbers is produced, please
   do not consider this a test failure.

Still, it's notable and slightly odd that the common case output
is different.