The previous implementation breaks if `$XDG_CACHE_HOME` is set to
anything other than what is expected, since KDE will now write the cache
there instead. Some users set `$XDG_CACHE_HOME` to something like
`$HOME/.local/cache` to de-clutter `$HOME`. In such case, the cache won't
be found and removed, which will cause the KDE runner to not be able to
launch anything. It will now work regardless.
libsoup 2 is unmaintained so WebkitGTK decided to drop support for it in next release in March 2026:
https://discourse.gnome.org/t/webkitgtk-is-removing-support-for-libsoup-2/31873
Since the package is security critical, we backport all updates to stable.
Let’s remove it before branch-off to avoid breaking stable when that version is backported.
macOS 27 is going to drop Intel support, so we’re pre‐announcing
the inevitable so that people can prepare.
We already announced that we’re aligning our OS support policy with
Apple’s starting in 25.11, so it’s very unlikely that we could
justify making an exception to devote resources to `x86_64-darwin`
support in 28.11 and beyond, after Apple stop releasing security
updates for the platform.
However, the end of support in Nixpkgs may come sooner than that. Apple
have announced that [Rosetta 2 will be pared down] by macOS 28 to not
support emulation of arbitrary applications. We use `aarch64-darwin`
builder machines exclusively and rely on Rosetta 2 to build packages
for `x86_64-darwin`. As we try to keep the builders on the latest OS
versions, that would mean that we’d lose the ability to build for
`x86_64-darwin` around the release of 27.11, unless we held back on
updating the OS on the builders for a year.
[Rosetta 2 will be pared down]: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment
Additionally, `x86_64-darwin` is the slowest system to build due to
our limited Mac builder resources and the emulation overhead. Dropping
support will more than double our effective `aarch64-darwin` build
capacity and benefit the whole project by reducing the bottleneck on
world rebuilds during `staging-next` cycles. It’s hard to find good
data on the relative market share, but the May 2025 [Steam Hardware
Survey] shows over 80% of their macOS users already being on Apple
Silicon. Therefore, I’d personally expect us to drop support by
26.11, given the trade‐off between the resources it will take to
continue supporting `x86_64-darwin` and the number of users it is
likely to benefit. (And I’m typing this on a Intel Mac myself…)
[Steam Hardware Survey]: https://store.steampowered.com/hwsurvey/processormfg/
Thanks to improved runtime configuration, there is a single binary,
sail_riscv_sim, instead of a binary for each base architecture.
The zlib dependency actually got dropped in 0.7: fb6dd20fec53 ("Bump
required sail compiler version to 0.19 and remove zlib dependency")
- `lib.attrsets.cartesianProductOfSets` was deprecated in 228621e42d
- `lib.attrsets.zip` was deprecated in fcbc4fe9ff (2013!)
- `lib.attrsets.zipWithNames` was deprecated in 00127bef3f (2009!)
The time has come.
Use the same template as every year to guide people through the upgrade.
Also, put the stuff into the NixOS release notes: the only deployment
way for the package that we truly support is via the module. I think
this shows again what a remarkably bad idea this separation is IMHO.
as with glibcxxassertions, we don't yet have a nice mechanism
for deferring support decisions to the c++ library in use, so
for now at least enabling this hardening flag will cause
_LIBCPP_HARDENING_MODE to be defined on all compilers
Allows having alternate hashed mirrors as fallbacks. Useful in case the
default hashed mirror is not accessible or doesn't have everything
needed.
Co-authored-by: Johan Herland <johan.herland@tweag.io>
Co-authored-by: Yuriy Taraday <yuriy.taraday@tweag.io>
Co-authored-by: Alexander Bantyev <balsoft@balsoft.ru>
- v0.20.0 replaced HBOX_STORAGE_DATA in favor of
HBOX_STORAGE_CONN_STRING and HBOX_STORAGE_PREFIX_PATH.
Added options for these.
- Added support for custom user/group.
