Esteemed Nixers,
we’re back from NixCon 2026 – it was a blast! Great to have met so many people, again or for the first time. Way too big and way too short to talk with everyone we wanted to.
@layus demonstrated how to do distributed incremental builds by marrying recursive-nix with the Bazel remote execution API, and… Well, it’s not that simple, so watch the full exposition for details: Nixception – incremental builds inside and outside the sandbox
Yours truly discussed history and liberally shared opinions on Sunday morning to wake everyone up, and was pleased to have so many attending: Why I changed my mind about flakes
Meanwhile, Tweagers back home were hacking:
@florentc: finished the migration to a snappy dynamic UI for the Nixpkgs security tracker
- Old and new were running in parallel for a couple of weeks to give users the opportunity to try it out and report remaining issues (which were fixed)
- We’re back to developing features again: Next steps will be to tidy up the display of packages in automatic matches, and adding a dedicated overview of packages one maintains or subscribes to.
@YorikSar: getting CUDA team’s packages built
-
Maintaining hydra-github-app as a bridge between Hydra and GitHub PRs.
Example
- Someone from our team posts a PR like python3Packages.islpy: 2026.1 -> 2026.2.2 by GaetanLepage · Pull Request #565275 · NixOS/nixpkgs · GitHub
- A script on CUDA team’s machine picks it up infra/packages/helpers/src/main.rs at 9a70a4ebba8a4268bf3bb00fd2ac22ee9a3996fa · nixos-cuda/infra · GitHub
- Clones it to nixos-cuda org: python3Packages.islpy: 2026.1 -> 2026.2.2 by nixos-cuda-channel-updater[bot] · Pull Request #777 · nixos-cuda/nixpkgs · GitHub
- Hydra GitHub App picks it up and creates a jobset from it Making sure you're not a bot!
- After all is done, it reports the result in nixos-cuda org’s clone.
-
Want to replace
nixpkgs-reviewusage on developer’s hardware with Hydra builds for everything- That really, really needs more hardware. Assisting the NixOS Foundation with getting hardware acquired.
-
Diving deep into Hydra internals:
- Trying to get Hydra’s Perl code to work in a dev environment on macOS
- Ultimately want to merge
hydra-github-appfunctionality into Hydra itself- That would would allow triggering Hydra on pull requests
- It would enable proper checks, such as determining which packages are affected
- It would also bypass the Hydra API, which is currently very limited
- Will start by making adjustments to be able to do this without Perl, rewrite the relevant parts in Rust
- Joined the Hydra Matrix room to coordinate with maintainers
@tshaynik: working on getting rules_nixpkgs support newer Bazel releases
rules_nixpkgsis a Bazel ruleset that allows bringing arbitrary tools from Nixpkgs into your Bazel build environment- It used to be that there was no meaningful way of doing dependency management with Bazel; you’d just put arbitrary things into your
WORKSPACEfile - There’s more things out there, but
rules_nixpkgswas our approach to bringing hermetic toolchains- The big downside of that was not having native remote execution, and getting store paths on to Bazel remote builders was always fiddly
- Related: Bazel remote execution with
rules_nixpkgsco-authored by @layus
- Related: Bazel remote execution with
- The big downside of that was not having native remote execution, and getting store paths on to Bazel remote builders was always fiddly
- It used to be that there was no meaningful way of doing dependency management with Bazel; you’d just put arbitrary things into your
- Currently updating
rules_nixpkgs(various toolchains, examples, …) to recent Bazel versions, one at a time- The recent release v0.14.0 by @vreuter made Bazel 7 the minimum supported version and deprecated Bazel 6
- Plan is to keep Bazel 7 and add Bazel 8, and deprecate the old
WORKSPACEapproach in favor of Bzlmod
- Maybe good to know: there’s also the other direction of running Bazel builds in Nix derivations with
pkgs.buildBazelPackage(currently undocumented)
Thunks for your attention! 