Conversation
|
Result of 1 package built:
|
|
@adisbladis @zowoq @K900 the upgrade of this dependency should be transparent to lemmy https://git.asonix.dog/asonix/pict-rs/releases/tag/v0.5.0 |
|
Just noticed that pict-rs is now 0.5 in nixpkgs (i'm the pict-rs developer) to be consistent I think there should still be a pict-rs 0.4 package, just like there exists a pict-rs 0.3 package. pict-rs only maintains a migration path from the previous version, so 0.3 can migrate to 0.4, and 0.4 can migrate to 0.5, but 0.3 can't migrate directly to 0.5. Providing only 0.3 and 0.5 without an 0.4 option will strand users on 0.3 if they haven't yet upgraded. |
|
Hey thank you for coming by! |
This was broken by the Rust 1.80 upgrade, and is an old version that we’d have to patch to keep working. We have already done the 0.4 → 0.5 update without keeping around the old version or adding in any additional `stateVersion` logic in <NixOS#280221>. As a result, migration for 0.3 users is going to be a little awkward. I’ve done my best to provide comprehensive instructions for anyone who hasn’t already bumped to 0.4. It is probably a footgun to add `stateVersion` logic for any package that makes backwards‐incompatible schema changes and only supports migration from the immediately previous version. Users won’t get migrated by default and we have to either package and maintain an endlessly growing list of old versions or add complicated instructions like this. It’s not really practical for us to support a significantly better migration story than upstream does.
This was broken by the Rust 1.80 upgrade, and is an old version that we’d have to patch to keep working. We have already done the 0.4 → 0.5 update without keeping around the old version or adding in any additional `stateVersion` logic in <NixOS#280221>. As a result, migration for 0.3 users is going to be a little awkward. I’ve done my best to provide comprehensive instructions for anyone who hasn’t already bumped to 0.4. It is probably a footgun to add `stateVersion` logic for any package that makes backwards‐incompatible schema changes and only supports migration from the immediately previous version. Users won’t get migrated by default and we have to either package and maintain an endlessly growing list of old versions or add complicated instructions like this. It’s not really practical for us to support a significantly better migration story than upstream does.
This was broken by the Rust 1.80 upgrade, and is an old version that we’d have to patch to keep working. We have already done the 0.4 → 0.5 update without keeping around the old version or adding in any additional `stateVersion` logic in <NixOS#280221>. As a result, migration for 0.3 users is going to be a little awkward. I’ve done my best to provide comprehensive instructions for anyone who hasn’t already bumped to 0.4. It is probably a footgun to add `stateVersion` logic for any package that makes backwards‐incompatible schema changes and only supports migration from the immediately previous version. Users won’t get migrated by default and we have to either package and maintain an endlessly growing list of old versions or add complicated instructions like this. It’s not really practical for us to support a significantly better migration story than upstream does.
Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/pict-rs/versions.
meta.description for pict-rs is: A simple image hosting service
meta.homepage for pict-rs is: https://git.asonix.dog/asonix/pict-rs
Updates performed
To inspect upstream changes
Impact
Checks done
passthru.tests, if any, passedRebuild report (if merged into master) (click to expand)
Instructions to test this update (click to expand)
Either download from Cachix:
(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the
trusted-userslist or you can usesudosince root is effectively trusted.Or, build yourself:
Or:
After you've downloaded or built it, look at the files and if there are any, run the binaries:
Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of
nixpkgs-reviewrun on x86_64-linux 11 package built:
Maintainer pings
cc @happysalada for testing.