ok 119 setup_file is not over parallelized ok 120 running the same file twice runs its tests twice without errors not ok 121 parallelity factor is met exactly # (in test file test/parallel.bats, line 127) # `[[ "${#lines[@]}" -eq $parallelity ]]' failed # 1..10 # ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_hardened-j4_test-20210817-100010 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.0 * /usr/lib/llvm/12 12.0.1 Python 3.9.6 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.54.0 * The following VMs are available for generation-2: Available Java Virtual Machines: (none found) The Glorious Glasgow Haskell Compilation System, version 8.10.4 HEAD of ::gentoo commit ba2d72b2c82b26954651689795ab4bcb36ba16fc Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Aug 22 23:21:31 2021 +0000 2021-08-22 23:21:29 UTC emerge -qpvO dev-util/bats [ebuild N ] dev-util/bats-1.4.1
Created attachment 735265 [details] emerge-info.txt
Created attachment 735268 [details] dev-util:bats-1.4.1:20210823-003229.log
Created attachment 735271 [details] emerge-history.txt
Created attachment 735274 [details] environment
Created attachment 735277 [details] etc.portage.tar.bz2
Created attachment 735280 [details] temp.tar.bz2
I can reproduce the issue when "sys-process/parallel" is installed. That one test will fail for both versions currently in the tree. Not having "sys-process/parallel" installed looks good, but that should be "added value" and not conflict in any way.
The test failure seems to boil down to a "ps" not delivering the expected result. Might be some kind of sandbox FEATURE. Running that same test outside or portage looks good, but inside that "ps" will not find "bats-exec-test" and "$output" will be empty, resulting in "${#lines[@]}" being "0" instead of the expected "5"
Could not find the rootcause or a valid patch against upstream. So proposing a change to patch out the failing test, see pull-request
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7746b3a35179bf129899d5684789d2e668937fc4 commit 7746b3a35179bf129899d5684789d2e668937fc4 Author: Henning Schild <henning@hennsch.de> AuthorDate: 2021-08-24 08:41:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-25 02:53:35 +0000 dev-util/bats: disable failing test Could not figure out why exactly that test fails, but it has to do with the portage environment it runs in. Outside that environment it works just fine and upstream will have tested that when they release to us. Closes: https://bugs.gentoo.org/809755 Signed-off-by: Henning Schild <henning@hennsch.de> Signed-off-by: Sam James <sam@gentoo.org> dev-util/bats/bats-1.3.0.ebuild | 6 ++++++ dev-util/bats/bats-1.4.1.ebuild | 6 ++++++ 2 files changed, 12 insertions(+)
