PRs to NixOS are a bit confused about if they should PR to release-* or nixos-* or nixpkgs-*. I think namespacing the refs will go a long way in making it more obvious.
From the nix 2.2 changelog:
> nix hash-file and nix hash-path now print hashes in SRI
> format by default. They also use SHA-256 by default
> instead of SHA-512 because that's what we use most of the
> time in Nixpkgs.
```
error: [json.exception.parse_error.101] parse error at 195: syntax error - invalid string: ill-formed UTF-8 byte; last read: '"bokml'; expected string literal
```
This is most probably caused by the upgrade in nixos-org-configurations/1b74e019b166d37a1510a99aeea86a0fa656854a
that, in turn, caused nlohmann_json to go from 2.1.0 -> 3.2.0
I haven't found concrete evidence in the changelog as to a change
changing the exception type. Though, the timing for failures matches
with this update.
Furthermore, once this fix is applied, launching the update locally
works fine.
The change in d3d33d5b25 changed how the
locally saved channel information was saved on the local machine.
* d3d33d5b25 (diff-682bf482f6dd273f1c3c49afd99b4660R192)
The changeset did *not* change the guard clause, which now made it act
like this:
1. Try readlink on the file
2. (bail as it's undefined)
The new behaviour is as more or less expected:
1. Reads the file if available
2. Split the URL components
3. Keep the last bit
This can give us an empty string, which will compare to `-1` thus
fulfilling the need.
The manpage says:
> The sums are computed as described in FIPS-180-2. When checking, the input should be a former
> output of this program. The default mode is to print a line with checksum, **a space, a character
> indicating input mode ('*' for binary, ' ' for text or where binary is insignificant),** and name
> for each FILE.
By adding the filename to the generated sha256 file, a user would be
able to download an iso, the sha256 file, then use `sha256 -c
[file].iso.sha256` to verify the file.
* * *
This fixes nixos-homepage#224
For every file "lib/debug/.build-id/<build-id>.debug" in every store
path ending in -debug in a release, this command creates an S3 key
"debuginfo/<build-id>" specifying the location of the NAR that
contains the debug info file for that build ID. Thus,
https://cache.nixos.org/debuginfo allows debug info files to be looked
up by build ID. This allows debug info files to be fetched
automatically by dwarffs [1].
One minor issue is that in theory, multiple store paths could provide
debug info files for a particular build ID. So then when we garbage
collect a store path from the binary cache, we migth invalidate a
debug info link even though there are non-GC'ed store paths that
provide the file. Ah well.
I could have used HTTP redirects, but they're kind of a pain to
configure with S3.
[1] https://github.com/edolstra/dwarffs
Otherwise we might clobber the redirects if the disk is full, and in
any case there is a time window in which .htaccess is in an
inconsistent state.
Fixes https://github.com/NixOS/nixpkgs/issues/18544.
Samuel Dionne-Riel