The hash seems to be wrong:

unpacking source archive /tmp/nix-build-source.drv-0/bd15ac764fb8fe1995d3b2f6c8ddb643447d92aa.tar.gz
hash mismatch in fixed-output derivation '/nix/store/95kgb5385slphkbwx1246kk4ikzqyvzc-source':
  wanted: sha256:198ihsm890cng5sfbrbvf01cmxvawi06pnhcn0b9ycpskf595i3b
  got:    sha256:194yjl270r6cwhiv6hb5mc5r74kwhr55p2y0ys4hzryn35lgrvl4
cannot build derivation '/nix/store/gry498msxg1sn2ic1xapffrd0wcvlx59-zfs-kernel-unstable-2019-04-01-5.0.5.drv': 1 dependencies couldn't be built

I've been using this version for a while without problems. Fixed the hash and rebased on master. Additionally this version fixes the build for kernel 5.0 which is our linux_latest. I intend to merge this soon and maybe backport to 19.03. Any opinions?

0.8.0-rc4 isn't out because master has show-stopping, data-losing bugs. This selected commit is likely to have these bugs. openzfs/zfs#8607

It is zfsUnstable, but I fear that many people switched to it when it was an 0.8.0-rc* for encryption, and now they will have no choice but either:

• run a totally unreleased version, with severe and known bugs
• stay back on an old nixpkgs
• destroy and recreate their data to not use 0.8.0.

This said, I don't use zfsUnstable, and people probably generally shouldn't use it unless they have excellent backup hygiene based on more than just zfs send and don't mind restoring. I think this update is scary, but I also don't feel it is up to (or impacts) me. However, I also feel that if you've been using ZFS for long enough for TRIM to matter, you can probably wait until 0.8.0-rc4 comes out.

Thanks a lot for looking that up. In this case we should wait for the fix in the next rc release and use that in nixpkgs. People can still use the stable kernel from nixpkgs.

I have to use a more recent kernel due to my laptop hardware and am thankfully not using zfs send for backups. 😸

It is zfsUnstable, but I fear that many people switched to it when it was an 0.8.0-rc* for encryption, and now they will have no choice but either:

@grahamc I on the other hand was surprised to see that zfsUnstable was no longer pointing at some random commit off master but rather an rc version.
I think it's a good change to use rc rather than just picking a commit of master and going with it but I would .

If we do want to always pick rc versions I'd like a name change from zfsUnstable to zfsNext (or something similar) since "unstable" usually has the connotation to be a master commit in other packages (and even the NixOS unstable channel).

On a separate note: Let's close this, that bug looks scary.

0.8.0-rc4 isn't out because master has show-stopping, data-losing bugs. This selected commit is likely to have these bugs. zfsonlinux/zfs#8607

But that referenced bug is also part of 0.8.0-rc3. So stopping this PR because that bug looks scary doesn't actually change anything.

@adisbladis can you update this to rc4?
cc @infinisil

@Mic92 Already done in #59791