These were done manually by me, either due to not matching the regexes in the previous ones, or because of nixf-diagnose, which I have as a pre-commit hook.
When we _must_ build, prefer building locally since we probably already have the manpages here. Otherwise, Nix would send all the manpages to a remote builder which isn't likely to be much faster since building the DB is single-threaded. Hopefully a best-of-both worlds between keeping or removing 39e63f110e.
When cups-browsed was separated from cups in f1f9a54031
the implicitclass backend ($out/lib/cups/backend/implicitclass) was
moved from cups-filters to cups-browsed. When ipp-usb advertises a
printer, cups-browsed configures cups to add an implicitclass://...
printer and cups fails to find the corresponding backend:
cups.service cupsd[788465] DEBUG Canon_TR4500_series_USB device-uri: Unknown scheme in URI
cups.service cupsd[788465] DEBUG CUPS-Add-Modify-Printer client-error-not-possible: Bad device-uri scheme "implicitclass".
cups.service cupsd[788465] ERROR [Client 6] Returning IPP client-error-not-possible for CUPS-Add-Modify-Printer (ipp://localhost/printers/Canon_TR4500_series_USB) from localhost
This commit adds cups-browsed to the packages that compose the ServerBin
option of cups-files.conf so that cups can find the implicitclass
backend.
https://github.com/ipfs/kubo/releases/tag/v0.37.0
Kubo v0.37.0 embeds the repository migration from repo version v16 to v17 and the kubo-fs-repo-migrations package will not reveive any more updates.
I'll keep the `kubo-fs-repo-migrations` and `kubo-migrator` packages around for now until a future version of Kubo no longer supports calling the external migration binaries.
Since the (newest) migrations are now built into Kubo, the NixOS module now needs to call `ipfs repo migrate --to=xx --allow-downgrade` instead of `fs-repo-migrations --to xx -y`.
The `--allow-downgrade` flag is only there for the unlikely situation that someone downgrades their local Kubo version with an overlay, separate channel input or similar means. It does however not work for rolling back the NixOS generation after a Kubo upgrade which increases the repo version (not all Kubo upgrades increase the repo version). This is because the Kubo version of the previous NixOS generation doesn't have the code for upgrading to or downgrading from the newer repo version.
Since we only have one version of Kubo in Nixpkgs at a time, migrations cannot be tested automatically. I manually verified that `ipfs repo migrate` uses binaries like `fs-repo-15-to-16` provided by the `kubo-fs-repo-migrations` packages for older migrations. I also tested that the migration from v16 to v17 works on my machine using the NixOS module.
