I was mainly considering Jellyfish and Jaguar (and Jackrabbit).
Originally I was inclined for Jellyfish, but then I thought of the
release T-shirts someone makes and it didn't seem suitable...
Jaguar would keep the name referring to a car as well, but as a
not-too-old (Mac) OS version is codenamed that way, I didn't go for it.
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince --help` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince --version` and found version 3.28.0
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince-thumbnailer -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince-thumbnailer --help` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince-previewer -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/evince-previewer --help` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-wrapped -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-wrapped --help` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-wrapped --version` and found version 3.28.0
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-thumbnailer-wrapped -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-thumbnailer-wrapped --help` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-previewer-wrapped -h` got 0 exit code
- ran `/nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0/bin/.evince-previewer-wrapped --help` got 0 exit code
- found 3.28.0 with grep in /nix/store/xa8kjq7jlp5dy53nfd91lmiw7liwg5vw-evince-3.28.0
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 1.0.7 in filename of file in /nix/store/3mbmc1niw3y2m109f6v0xlch0pn1ml8q-editres-1.0.7
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 3.0.26 with grep in /nix/store/3x1gsqxcrbyiq3jncz9k8dfa8bi0bamf-clutter-gst-3.0.26
- found 3.0.26 in filename of file in /nix/store/3x1gsqxcrbyiq3jncz9k8dfa8bi0bamf-clutter-gst-3.0.26
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/bgpzi08y1w7zgv0iaisdd974mdy6pdpl-chunksync-0.4/bin/chunksync -h` got 0 exit code
- ran `/nix/store/bgpzi08y1w7zgv0iaisdd974mdy6pdpl-chunksync-0.4/bin/chunksync -V` and found version 0.4
- ran `/nix/store/bgpzi08y1w7zgv0iaisdd974mdy6pdpl-chunksync-0.4/bin/chunksync -h` and found version 0.4
- found 0.4 with grep in /nix/store/bgpzi08y1w7zgv0iaisdd974mdy6pdpl-chunksync-0.4
- found 0.4 in filename of file in /nix/store/bgpzi08y1w7zgv0iaisdd974mdy6pdpl-chunksync-0.4
I've started digging into the actual cause of the problem a week ago but
didn't continue fixing this.
The reason why the tests are failing is because
torvalds/linux/commit/72f5e08dbba2d01aa90b592cf76c378ea233b00b has
remapped the location of the TSS into the CPU entry area and we did
update our default kernel to version 4.14 in NixOS/nixpkgs@88530e02b6.
Back to VirtualBox: The guru meditation happens in
selmRCGuestTssPostWriteCheck, which I think is only a followup error. I
believe the right location couldn't be determined by VirtualBox and thus
the write check function triggers that panic because it's reading from
the wrong location.
So the actual problem *only* surfaces whenever we use software
virtualization, which we do for our tests because we don't have nested
virtualization available.
Our tests are also for testing the functionality of VirtualBox itself
and not certain kernel versions or kernel features, so for the time
being and until this is fixed, let's actually use kernel version 4.9 for
the guests within the VM tests. Kernel 4.9 didn't have the mentioned
change of the TSS location and thus the tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @dtzWill
