Cargo 1.84.0 broke fetchCargoTarball hashes, so fetchCargoTarball is
not long for this world. Tell people to use fetchCargoVendor, which
Nixpkgs is currently in the process of switching to across the tree.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
OctoPrint and its plugins are packaged in the form of multiple overlays,
each adding one or more packages built with `buildPythonPackage`. In
the NixOS module, the core `octoprint` package is then combined with
zero or more of the plugin packages into one `python.withPackages`
environment that is referenced by the systemd service unit.
Since plugins have to use the OctoPrint modules at runtime, they receive
the `octoprint` Python package as part of `propagatedBuildInputs`.
However, the current implementation of the plugins overlay takes this
dependency from the `super` package set, i.e., the stage preceding the
plugins overlay.
The use of `super` packages for dependencies is problematic here, as
there may be other subsequent overlays that modify the `octoprint`
package, and the `octoprint` that ends up in the final package set may
not be the same that the plugin was built against.
Things work out fine in the absence of any `octoprint` overrides, or if
no plugins are used. Combining the two in a NixOS configuration,
however, breaks the build with a collision of OctoPrint executables:
error: builder for '/nix/store/7sjbm51s4j5p02s76ncrb6arzb5nwph7-python3-3.12.8-env.drv' failed with exit code 255;
last 1 log lines:
> error: collision between `/nix/store/rg9mixyc0qpdgn3ynrlwlp2qk9l5gh6a-python3.12-OctoPrint-1.10.3/bin/octoprint' and `/nix/store/ws68951jy8gx7q9n09xgpykkwhia82mb-Overridden-OctoPrint-1.10.2/bin/octoprint'
For full logs, run 'nix-store -l /nix/store/7sjbm51s4j5p02s76ncrb6arzb5nwph7-python3-3.12.8-env.drv'.
error: 1 dependencies of derivation '/nix/store/sgmn253inypq9hi722a9817w1ji8lkb8-unit-octoprint.service.drv' failed to build
error: 1 dependencies of derivation '/nix/store/aydjfz8xf8s87hxc60vpnkzbclj5knj5-system-units.drv' failed to build
error: 1 dependencies of derivation '/nix/store/97a3pr2v2b5yjw9g3za5rbc6blb2q808-etc.drv' failed to build
The collision is between the overridden `octoprint` from the final
package set and the non-overridden version that the plugins depend on
(and end up propagating to their consumers).
They all should be using one and the same `octoprint` package, which is
the one from `self`, the final package set after applying all overrides.
Modify the `buildPlugin` helper function accordingly.
Fixes: https://github.com/NixOS/nixpkgs/issues/370946
Alyssa Ross