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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
