Since version 3.1.0, it has been moved to `params/parameters.toml`. Note
that an alternative to appending would be to use
`params/private-parameters.toml` but in our case, I don't think it
matters much as we don't keep the build directory.
moved the initial qtcurve package to mkLibsForQt5 function
to decouple from Qt5 version
added an alias qtcurve -> libsForQt5.qtcurve for backward compatibility
add option to disable gtk2 support (still enabled by default)
In [#100765] @vcunat pointed out that we could decouple cacert from the
NSS package to make it more rebuild friendly. Just rebuilding packages
that depend on NSS seems to be about ~100. Rebuilding all the packages
that depend on cacert is >9k as of this writing. This makes it much more
feasible to upgrade high-profile packages that are (rightfully) pedantic
on their NSS version like firefox and thunderbird.
[#100765]: https://github.com/NixOS/nixpkgs/pull/100765
The timezone dumps have switched to a "slim" format since 2020b.
This has broken various packages, including
- go 1.4 (used for bootstrapping)
- haskellPackages.tz
- libical
The "fat" format can still be generated, as this commit shows.
It seems to create files that are *mostly* the slim versions with
some more data attached.
Previously we used nodePackages only to fetch Iosevka's build
dependencies and then fetched the source code ourselves. Updates
involved changing the version and hashes in the `iosevka` derivation and
then running node-packages/generate.sh to update the build dependencies,
which in turns updates *all* of node-packages.nix.
A new proposed policy for handling node-packages.nix updates involves
batching those updates. Previously, that would mean `iosevka` and its
build dependencies could end up out of sync until the batched update was
run.
To work with the new policy, we now fetch Iosevka's source code (and
not only its dependencies) through nodePackages. Updates are done by
changing the source URL in node-packages.json, which eventually becomes
part of an update of node-packages.nix, which is then propagated to
`iosevka` itself.
One con of this strategy is that errors can not be caught directly
after the update, but only after node-packages.nix is regenerated.
