zfs_2_2: 2.2.3 -> 2.2.4; zfs_unstable: 2.2.3-unstable-2024-04-09 -> 2.2.4; python3Packages.py-libzfs: 22.12.4.2 -> 24.04.0 #308642
Conversation
|
Result of 9 packages failed to build:
89 packages built:
The py-libzfs failure seems legitimate and due to an API change—will see if I can make a patch. Haven’t looked at the others yet. |
amarshall
added
the
11.by: package-maintainer
No pre-release version at this moment, so use now-released 2.2.4.
Now compatible with Linux 6.8. https://github.com/openzfs/zfs/releases/tag/zfs-2.2.4 Need to patch py-libzfs to support incompatible API change.
|
|
amarshall
changed the title
|
@nbraud Indeed, it’s fetchpatch-ed in the zfs update commit as it’s an incompatible change that only works in concert with the zfs update. |
Ah thanks. I missed it because I looked at c6a3a06 when it's in a1dcb54... which makes more sense anyhow, that way everything builds on every commit :) PS: Confirmed |
|
I have a Not sure how that's related, but it's marked as building correctly on hydra, and I can't see any relevant change to it since |
|
I cannot replicate; ceph successfully builds on x86_64-linux on this branch, based off latest master (5c95d72). |
Exciting! I had other drvs now failing due to running out of space, so that may have been it (though it would be a strange way for the issue to manifest) |
wegank
added
the
12.approvals: 1
|
running 2.2.4 fine on my system, i dont see obvious errors on my end. |
wegank
added
12.approvals: 2
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-23.11
git worktree add -d .worktree/backport-308642-to-release-23.11 origin/release-23.11
cd .worktree/backport-308642-to-release-23.11
git switch --create backport-308642-to-release-23.11
git cherry-pick -x c6a3a06e5dec34aaaf80576760a81973644e3864 2cbe0633194e987048207cd79a662ce761f56457 a1dcb54257af49396329dc8467a465b21d7746b9 |
|
Oof. Linux 6.8 had a backport to 23.11. I'll see if I can wade through this one by hand. |
|
|
||
| # this package should point to a version / git revision compatible with the latest kernel release | ||
| # IMPORTANT: Always use a tagged release candidate or commits from the | ||
| # zfs-<version>-staging branch, because this is tested by the OpenZFS | ||
| # maintainers. | ||
| version = "2.2.3-unstable-2024-04-09"; | ||
| rev = "28520cad2500b60ce8653e431990e33f77ff08f7"; | ||
| version = "2.2.4"; |
There was a problem hiding this comment.
Since 1f32eb7#diff-fbbd794729847fb904a20232b805e7dd5781e14f8b66654d6afb59220a649cbcR214 we no longer can check enableUnstable if zfs unstable is used. Before this PR I've used (!config.boot.zfs.enabled || config.boot.zfs.package == pkgs.zfs_unstable) to check if linuxPackages_latest can be used, but now I need to add another condition if pkgs.zfs and pkgs.zfs_unstable are equal. IMO it was mistake to drop enableUnstable and require people to do Kaffeesatzläserei.
There was a problem hiding this comment.
Maybe we can add a passthru option to indicate if it's the stable or unstable version.
There was a problem hiding this comment.
I’m not sure how this is related to this PR—consider making a new issue to discuss. Anyway:
Using zfs_unstable does not imply linuxPackages_latest can be used, nor does using zfs imply it cannot be used. Instead I suggest using config.boot.zfs.package.passthru.latestCompatibleLinuxPackages to determine this.
Description of changes
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.4
Things done
nix-build -A zfs_unstable.passthru.tests -A zfs_2_2.passthru.tests; still performing some testing.nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.