In accordance to the upstream release cycle, we now provide 2 flavours
of the percona mysql ecosystem. The default is the LTS variant,
additionally there is now the floating `percona-server_innovation`
always pointing to the most recent regular release.
- mentioned in release notes
- adapted all depending tests and tools (xtrabackup)
Conflicts in luaPackages.luarocks-nix:
- 8b563cd9f9 switched to the new version format (prefixed by 0 since there was no relevant last tag in the branch).
bc4f6fa543 bumped version and switched to the new version format. But the tag used is not part of the branch the commit comes from (master).
Used the new version but replaced the tag prefix with 0.
- b73ec84b9e removed meta (it is already set in the overridden luarocks). But that would cause the update script to try to update the overridden luarocks (as did the previously used old.meta).
bf311d950e modified meta to fix the update script properly.
Kept the meta from the latter since it allows update script to work.
and turn it in to a list.
The current setting of system.forbiddenDependenciesRegex is a string, meaning only one such regex as any additional setting would result in conflicts.
As maintainers have already started using this setting eg. in profiles, it would be good if this setting would accept a list of regex to allow the end
user to make use of it in addition to package maintainers.
This is a breaking change that converts the 'src' csv column (a git URI) to a 'rockspec'
fullpath uri.
before this, luarocks-nix would clone the repo and look for rockspecs
with a brittle algorithm. This removes the ambiguity on which rockspec
to package while allowing to remove a bunch of brittle code from
luarocks-nix.
This reverts commit e827697fd3.
This seems to cause various issues during system activation, as reported
in https://github.com/NixOS/nixpkgs/issues/302771 for example.
Due to being close to branchoff, revert this for now.
We'll open a tracking issue to collect and sort out remaining issues.
The idea behind that is to enable users and developers of
downstream tools such as home-manager to test Nix master for several
reasons:
* Nix is currently trying to have a `master` branch that's always
releasable[1]. We're still on Nix 2.18 in nixpkgs due to too many
notable regressions. Enabling people to test latest master may help on
that end.
* This uses the most bleeding-edge Nix, but our packaging, so we can
identify issues with our packaging early.
* From what I've seen, most people are using the packages from nixpkgs
anyways instead of the upstream flake, this is far more convenient
anyways.
My plan is to update this once a week. Right now we rely on the
`installCheckPhase` here, but as soon as we have proper regression
testing[2], we may want to add `nixUnstable` there as well (however with
failures being allowed probably).
[1] https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204
[2] https://github.com/NixOS/nixpkgs/pull/304332
* Minor tweaks to note text
* Elide "The" before attribute names at start of notes
* Turn version numbers into code blocks
* Turn branding into attribute names
* Add TODOs
* Turn code-block version numbers into plain text
... following discussion on Matrix.
---------
Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>
* PHP 8.3 seems supported, so let's go for it!
* The conditions for which Nextcloud will be the default were bogus: for
<24.11 I'd suggest to go for nextcloud29 already. The people on
unstable relying on the condition were on nextcloud28 so the upgrade
will work fine.
Also, it's unstable, so such upgrades are to be expected IMHO.
* Update the release notes to reflect that the new default is Nextcloud
29 and warn that only one major upgrade at a time can be done.
Add the NixOS option `hardware.nvidia-container-toolkit-cdi-generator.enable`.
This enables the ability to expose GPU's in containers for container
runtimes that support the Container Device Interface (CDI)
Remove `cdi.static` and `cdi.dynamic.nvidia.enable` attributes.
- xz compression added for module files
- no support for kernel 6.8 or newer
- sri format used for hash
- release notes for 24.05 updated
Signed-off-by: birkb <birk@batchworks.de>
When passing a path to restartTriggers or reloadTriggers, X-Restart/Reload-Triggers
will get populated by the absolute path of the file on the machine where the
config is evaluated. This patch corrects this behavior.
