Raito Bezarius
21dbd7745d
Some source trees might not be representable inside of the NAR listing
format v1 as file paths (on Linux) are not guaranteed to be valid UTF-8.
When something like this happens on a large-scale build farm, a
mysterious "queued" but impossible to process job appears, this is
because we cannot write the NAR listing and serialization always fails.
Why did this work before? nlohmann was introduced _after_ such paths
were ingested, see: 09f00dd4d0.
What happened for such previously mis-serialized NAR listings?
```
curl -v 'https://cache.nixos.org/nz8p9hn00r6z7s57581c1hiv39pa1ia6.ls' |
brotli -d | jq .
```
This fixes the build of `sub-batch`
(https://github.com/kl/sub-batch/tree/master/tests/rename_invalid_utf8)
on ForkOS infrastructure.
Many thanks to Puck for the assistance on holding `rr` right on this one
and finding the history of these changes.
Change-Id: I2c2fbac70818e02810f9fd236c3a248187bf5fe7
Signed-off-by: Raito Bezarius <raito@lix.systems>
27 lines
537 B
Nix
27 lines
537 B
Nix
{ nonUtf8Inodes ? false }:
|
|
with import ./config.nix;
|
|
|
|
rec {
|
|
a = mkDerivation {
|
|
name = "nar-index-a";
|
|
builder = builtins.toFile "builder.sh"
|
|
''
|
|
mkdir $out
|
|
mkdir $out/foo
|
|
touch $out/foo-x
|
|
touch $out/foo/bar
|
|
touch $out/foo/baz
|
|
touch $out/qux
|
|
mkdir $out/zyx
|
|
|
|
${if nonUtf8Inodes then ''printf "data" > "$out/invalid-\x80file"'' else ""}
|
|
|
|
cat >$out/foo/data <<EOF
|
|
lasjdöaxnasd
|
|
asdom 12398
|
|
ä"§Æẞ¢«»”alsd
|
|
EOF
|
|
'';
|
|
};
|
|
}
|