Closes#455144
Previously, image builds with ZFS would fail with
kernel-modules-shrunk> root module: 9p
kernel-modules-shrunk> modprobe: FATAL: Module 9p not found in directory /nix/store/r4m7bmihmr40377yh33pn76wp9w33da2-kernel-modules/lib/modules/6.12.53
with said store-path only containing out-of-tree modules.
I'm pretty sure this was just missed to update in
f71277d66d.
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.
