This will allow the code for https://github.com/NixOS/nixpkgs/issues/447514
to make sure that the right team is requested for review,
even if it has been renamed in the meantime.
While the matching is currently based on the teams slug/name and not the
id, renames won't cause problems with `lib.teams`, because CI would
error if there's no match. Changing this can be future work.
The old cygwin support used -pc-windows-cygnus as the config. This is
supported by LLVM, but not by GNU. This will change it to -pc-cygwin,
which is more generally supported.
Because the kernel is now 'cygwin' rather than 'windows', isWindows will
return false. There are lots of different reasons isWindows is used in
nixpkgs, but in my experience they often have to do with posix
compatibility and don't apply to cygwin.
Co-authored-by: Brian McKenna <brian@brianmckenna.org>
Allows marking an option as invisible, without excluding its sub-options.
In practice, this is similar to `visible = true; internal = true;`,
however it is more explicit and less reliant on implementation details.
renamed `mac` to `octets` in hextets combining step for better var
naming; rephrased error message to provide a hint of expected format;
replaced `Arguments` with `Inputs` in docstring; added more test cases
for invalid hex digits; added comments in hextets combining step;
A Cross Index, short for Cross Platform Pair Index, is the essential
shape of a splice, without the invoking the more mind bending concept
of adding variations of for these 6 pairings to an existing thing so
that it can be switched out for something else.
So the purpose of a Cross Index is to contain the result of `f`\
(which may be reified in code, or just an abstract concept):
- f "build" "build"
- f "build" "host"
- ...
Splicing on the other hand refers not just to these six variants, but
to the idea of tacking them onto one of the variants. (hostTarget,
I believe)
Cross Indexes are a necessity for making cross compilation work, but
splicing is more than necessary.
At the scale of Nixpkgs, actively maintaining a package is only possible
with integration into CI. To be able to be pinged for review requests,
the maintainer must have a GitHub handle, which:
- Leads to an invitation to the NixOS org, which comes with additional
privileges.
- Allows to request the maintainer for review as a member of this org.
- Automatically requests the maintainer for review in CI.
Currently, the GitHub handle is not strictly enforced. This leads to
some new maintainers accidentally forgetting to set these. We can avoid
these mistakes and enforce them via CI.
This doesn't do the right thing here, because it evaluates
the test with nix that is evaluating the `nixpkgs-lib-tests-nix-${nix.version}`
derivation, not the Nix/Lix under test. This was just really busted for a long
time.
`fromHexString` is backed by `builtins.fromTOML`. Per [the TOML
v1.0.0 specification]:
> Arbitrary 64-bit signed integers (from −2^63 to 2^63−1) should be
> accepted and handled losslessly. If an integer cannot be represented
> losslessly, an error must be thrown.
[the TOML v1.0.0 specification]: <https://toml.io/en/v1.0.0#integer>
The saturating behaviour of the toml11 version currently used
by Nix is not lossless, and is therefore a violation of the TOML
specification. We should not be relying on it. This blocks the update
of toml11, as it became stricter about reporting this condition.
This, yes, is arguably an evaluation compatibility break. However,
integer overflow was recently explicitly defined as an error by
both Nix and Lix, as opposed to the C++ undefined behaviour it was
previously implemented as:
* <https://nix.dev/manual/nix/stable/release-notes/rl-2.25>
* <https://docs.lix.systems/manual/lix/stable/release-notes/rl-2.91.html#fixes>
This included changing `builtins.fromJSON` to explicitly
reject overflowing integer literals. I believe that the case for
`builtins.fromTOML` is comparable, and that we are effectively testing
undefined behaviour in TOML and the Nix language here, in the same way
that we would have been if we had tests relying on overflowing integer
arithmetic. I am not aware of any use of this behaviour outside of
these tests; the reverted toml11 bump in Nix did not break the 23.11
evaluation regression test, for example.
C++ undefined behaviour is not involved here, as toml11 used the C++
formatted input functions that are specified to saturate on invalid
values. But it’s still a violation of the TOML specification caused
by insufficient error checking in the old version of the library,
and inconsistent with the handling of overflowing literals in the
rest of Nix.
Let’s fix this so that Nix implementations can correctly flag up
this error and we can unblock the toml11 update.
