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.
(cherry picked from commit 7636389851)
This is so you can figure out who to ask to get added to the team
Also avoid an unecessary `{ inherit lib; }` argument
(cherry picked from commit ddf8b5da4a)
The before and after of
nix-instantiate --eval -A lib.teams --strict --json | jq 'walk(if type == "array" then sort else . end)'
has been ensured to be negligible, only consisting of minor team
shortName and scope differences
(cherry picked from commit 428bd8f1a2)
No team was using the feature of having multiple GitHub teams, and this
would make it tricky to try to sync maintainer teams with GitHub teams.
(cherry picked from commit 1ea51e1f1a)
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.
(cherry picked from commit 568b19f656)
This is a partial backport of the nix_2_24 removal PR, containing
only the CI testing changes that update the tested nix versions.
(cherry picked from commit 1b7637ff08)
This suffers from the same issue as misc.nix tests, because they
were evaluated by the host nix, not the one that is being tested.
(cherry picked from commit 609c8799fa)
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.
(cherry picked from commit c2698371ef)
`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.
(cherry picked from commit 449ad44f16)
This was cherry‐picked from
<https://github.com/NixOS/nixpkgs/pull/266705> and merged as part of
<https://github.com/NixOS/nixpkgs/pull/318712>, despite there being
a blocking review on the former pointing out these kinds of issues.
This documents some of the dodgy behaviour. It also can’t handle
negative literals. It might be worth considering deprecating and
dropping this, by inlining it into `lib.network.ipv6.fromString`,
its only in‐tree user.
(cherry picked from commit 6673e05ad0)
The `nixVersions.minimum` alias has been removed on unstable, so the
TODO is not needed anymore.
The lib tests can't be run with Nix 2.3 anymore, because this version is
not available on unstable anymore - and thus also not in the pinned
nixpkgs that CI is run with.
(cherry picked from commit cc3d2295b6)
Previously we were taking nixVersions and this made external use from
the Lix repo's CI annoying.
We should probably also test other nix versions than stable (i.e. also
latest and Lix), but this involves writing GitHub Actions about it and
maybe not running it on every single PR. Future work.
(cherry picked from commit 332bc64369)
The vast majority of CI jobs to build the lib tests are caused by
changes in the maintainer list. In this case, we currently run the full
test-suite which takes 3-4 minutes. By moving the maintainers and teams
tests out of the test-with-nix file, we save almost all of that.
Building only those two tests on a change is almost instant. This only
works, because we previously enabled cachix for the workflow.
Note, that these tests are not actually run with both nix versions, even
though they were listed in the "test with specific nix version" file.
That's because we only differ in the nix version run *inside* the
sandbox, but not doing the outer build.
Since this file seems to be re-used by NixOS/nix' CI, this is
technically a small loss in coverage for that repo, but nixpkgs CI
considerations outweigh that. But because of this, I left the other
non-nix-version-specific tests in that file.
(cherry picked from commit a7f4e0f9ae)
I believe this change is wrong both theoretically and practically.
Theoretically, `null` is available on every platform, because
`buildInputs = [ null ];` always succeeds and never throws a platform
availability error. `null` should be handled consistently with packages
that have no explicit list of supported platforms, as it of course
has no such list itself.
Practically, we use `null` to represent libraries that are always
present on a platform and do not require a library (for instance,
because they are part of `libc` or the macOS SDK). This has been
used for a long time by `libintl` (on all non‐glibc platforms),
and is also now used by `libGL` and friends on Darwin. This change
broke the check SDL3 does for OpenGL availability on Darwin, causing
<https://github.com/NixOS/nixpkgs/issues/407056>, which had to be
worked around by <https://github.com/NixOS/nixpkgs/pull/409525>.
Both `libintl` and `libGL` should count as available on platforms
where their functionality is part of the standard build environment,
and a package that is completely unavailable and whose functionality
cannot be expected should not use `null`, as it should result in
errors if used in a dependency list on an unsupported platform.
I accept that overriding with `null` is often a useful way to disable
dependencies that don’t have explicit feature flags, but I do not
think that making it work better with feature flags conditioned on
availability is worth the inconsistency and problems caused by this
change. Packages can instead expose the relevant feature flags as
arguments that default to the `lib.meta.availableOn` check or, if they
want to keep an “override the dependency to `null`” interface,
insert an explicit `pkg != null && …` check.
Additionally, the pull request was merged over a week after all
breaking changes were restricted for the 25.05 release. I believe that
the potential problems of dealing with the effects of this change for
an entire release cycle – the first release cycle where `libGL` is
`null` on Darwin, a change I made before the deadline and before this
change to `lib.meta.availableOn` – offset the risks of backporting
this revert at such a late stage.
It will cause overrides to backwards‐incompatibly revert to the
behaviour they had before the change, but since such overrides were
not possible until a few weeks ago, I hope that is an acceptable risk
compared to the potential issues leaving this in the release can
cause, given that it was merged after the deadline and has already
broken an existing construction in Nixpkgs.
This reverts commit 9338d924db.
(cherry picked from commit 98dbc7cc58)
The `importApply` docs reference using the `_key` attr along with
`importApply` or `_file`, however the actual attr name used by the
module system is `key`.
The new implementation of `mapAttrsToList` is simpler than the previous one, avoiding an extra string conversion. Benchmarking shows a slight performance improvement. See the discussion here: https://discourse.nixos.org/t/another-implementation-of-mapattrstolist
Additionally, I searched nixpkgs for expressions equivalent to the old `mapAttrsToList` and replaced them with direct calls to the new implementation.
To fix overriding packages that checks for platform compatibility, like pipewire.
`pipewire` contains the following logic to enable support for ldac depending on library platform compatibility:
```nix
ldacbtSupport = lib.meta.availableOn stdenv.hostPlatform ldacbt
```
Which is used later in the expression to create a Meson flag:
```nix
(lib.mesonEnable "bluez5-codec-ldac" (bluezSupport && ldacbtSupport))
```
This means that attempting to build `pipewire` without `ldacbt` like:
```nix
pipewire.override {
ldacbt = null;
}
```
will fail because the the Meson flag indicates the feature should be enabled, but the library is passed to `buildInputs` as `null`.
