If a VM crashes during `connect()`, e.g. because of `panic_on_fail`
during initrd, we would spin on the closed socket forever. We should
rasie an exception instead.
This fixes a problem where most NixOS option declaration paths started
with `nixos/modules/nixos/modules/`, which should have been only
just `nixos/modules/`.
Since dcc0ee9ea1, we use a source path
that includes both the `modules` and `nixos/modules`, so we don't need
to additionally prefix `nixos/modules` anymore.
Manually checked with
nix-build nixos/release.nix -A options
jq < result/share/doc/nixos/options.json '[ ."_module.args".declarations, ."meta.maintainers".declarations, ."nixpkgs.system".declarations, ."zramSwap.swapDevices".declarations ]'
Samples:
- `_module` for options defined in `lib/`
- `meta.maintainers` for options defined in `modules/`
- `nixpkgs.system` for options defined in `nixos/` with `meta.buildDocsInSandbox = false;`
- `zramSwap.swapDevices` for regular `nixos/` without that
I'm a big fan of automated tests, but in this case I am not doing that because
- the solution is a simplification, and
- no obvious place for the test, and it would couple with unrelated
downstream code more than I would like.
Before, the vsocks the test-run will use were only printed in
interactive mode. However, with `enableDebugHook = true;` this
functionality can also be used via `breakpointHook` within the build
sandbox, i.e. in the non-interactive mode.
I misremembered how much effort this is to fix, otherwise, I would've
added this to #422066 already ;)
r"[A-z]" is not equivalent to r"[A-Za-z]"; it is equivalent to r"[A-Z[]^_`a-z]".
But Python variable names cannot contain, e.g., a backtick.
So the current regex is wrong.
There is a race condition
in the new paralleized OCR code.
The race condition got "active" in commit
819d304a39 (Use futures for OCR parallelization),
however, the underlying bug already slipped in with commit
e6ea13f4ea (User proper `Path` instead of `str` in OCR code).
The OCR module applies tesseract to at most three variants
of the screenshot: the original one, and two variants that
are created by a preprocessing step (with ImageMagick).
The preprocessing step needs an output filename
that is used to write the preprocessed image file.
The "Path" commit broke the way the output file is named:
The code still attempts to append a ".negative" to *one*
of the preprocessed output files, but the method
`.with_suffix` is not suitable for that purpose:
Lateron, ".png" is also added with `.with_suffix`,
*replacing* the ".negative" and thereby yielding the
*the same* output filename for both preprocessed files.
Without parallelization, this doesn't hurt;
preprocessed files are simply created and analyzed in order.
But the parallelization commit
causes that these two tasks now run in parallel
(plus the third task that analyses the original screensshot,
but that does not cause any further harm here):
* Task 1: preprocess (non-negative), then tesseract the output
* Task 2: preprocess (negative), then tesseract the output
Both tasks use the same filename and thus the same file for the
preprocessed image that is generated, then used by tesseract.
This often creates a garbage file since both
preprocessings write that one file at the same time.
Tesseract consequently fails and
complains about bad data in its input file.
The commit at hand simply fixes the file naming
by adding ".negative.png" or ".positive.png"
to the filename for the preprocessed image.
This ensures both threads no longer hurt each
other's data and can now coexist in peace.
At work we have the use-case that several people connect to a large
Linux box to run tests and debug those interactively.
All tests write their state into a global `/tmp` -- e.g. the vde1 socket
and the VMs' state. This leads to conflicts when multiple people are
doing this.
This change tries to use XDG_RUNTIME_DIR before using Python's detection
of a global temp directory: when connecting, this requires a working
user session, but then we get working directories per user. This is
preferable over doing something like `mktemp -d` per run since that
would break use-cases where you want to keep the VMs' state across
multiple sessions (`--keep-vm-state`).
