Only PRs to packages in pkgs/by-name can be merged with the merge bot, so
this is what lets the package's maintainers act on r-ryantm's bumps.
Both callPackage calls took empty argument sets, so no .override interface
changes. simpleBuildTool stays in all-packages.nix, being an alias rather
than a definition.
Assisted-by: Claude Code (Claude Opus 5)
Before this commit, an expression like `pkgs.gradle_8.override { java = pkgs.openjdk17; }` would produce a
gradle package which uses jdk 17, but has a setup hook which uses jdk 21.
Previously the regex for updating Gradle matched any major version,
resulting in version bumps like #504857 where gradle_8 was updated to
9.4.1.
After this change, the version regexp is tagged to a specific major
version. That way gradle_8 is only updated to versions that start with
'8'. At the same time version updates are enabled for gradle_9 if they
start with '9'.
Last but not least, `nix-update-script` is now called with
`--use-github-releases` because without it the updater defaults to using
GitHub's releases Atom feed, and just returns the most recent releases,
causing the gradle_8 update to fail because no matching release version
could be found.
E.g. when applying bubblewrap jails with jail.nix to sbt, to reduce the
blast radius of software delivery chain attacks, a warning is emitted by
the lib.meta.getExe function. But this does not depend on the external
jails.nix project, at all. This happens with every caller of the getExe
function on sbt inside nixpkgs as well.
evaluation warning: getExe: Package "sbt-1.11.7" does not have the
meta.mainProgram attribute. We'll assume that the main program has
the same name for now, but this behavior is deprecated, because it
leads to surprising errors when the assumption does not hold. If the
package has a main program, please set `meta.mainProgram` in its
definition to make this warning go away. Otherwise, if the package
does not have a main program, or if you don't control its
definition, use getExe' to specify the name to the program, such as
lib.getExe' foo "bar".
This triggers 1 "rebuild", however this is not really a rebuild.
This commit just moves `build2.passthru.bootstrap` to
`build2-bootstrap`, which is seen as a new package.
It is already build since it's a dependency of `build2`.
in conclusion this doesn't create any rebuilds
