Change:
<del> { lib, stdenv, fetchurl, autoreconfHook, pkg-config, fuse, util-linux, lz4, xz, zlib, libselinux , fuseSupport ? stdenv.isLinux , selinuxSupport ? false , lzmaSupport ? false </del> <ins> { lib, stdenv, fetchurl, autoreconfHook, pkg-config, fuse, util-linux, lz4, xz, zlib, libselinux, fuseSupport ? stdenv.isLinux, selinuxSupport ? false, lzmaSupport ? false, </ins> }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "erofs-utils"; <del> version = "1.7.1"; outputs = [ "out" "man" ]; </del> <ins> version = "1.8.1"; outputs = [ "out" "man" ]; </ins> src = fetchurl { <del> url = "https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/snapshot/erofs-utils-${version}.tar.gz"; hash = "sha256-GWCD1j5eIx+1eZ586GqUS7ylZNqrzj3pIlqKyp3K/xU="; </del> <ins> url = "https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/snapshot/erofs-utils-${finalAttrs.version}.tar.gz"; hash = "sha256-Xb97SS92gkYrl6dxIdQ8p2Cc2Q5l+MlpMa78ggpvDaM="; </ins> }; <del> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ util-linux lz4 zlib ] </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ util-linux lz4 zlib ] </ins> ++ lib.optionals fuseSupport [ fuse ] ++ lib.optionals selinuxSupport [ libselinux ] ++ lib.optionals lzmaSupport [ xz ]; <del> configureFlags = [ "MAX_BLOCK_SIZE=4096" ] ++ lib.optional fuseSupport "--enable-fuse" </del> <ins> configureFlags = [ "MAX_BLOCK_SIZE=4096" ] ++ lib.optional fuseSupport "--enable-fuse" </ins> ++ lib.optional selinuxSupport "--with-selinux" ++ lib.optional lzmaSupport "--enable-lzma";

Discussion:
Build log: Update PR: Revert PR: This blocked the channel. It seems most likely to be an upstream regression. There’s nothing obvious in . Probably we’ll have to report it upstream and/or peruse the . cc
I cannot parse the log in the link above or reproduce locally, could someone give some hints what happens or a reproducable way?
Hi, sorry about that! If you have Nix installed on a Linux machine, or a NixOS VM handy, should reproduce the test failure. However, I realize that’s not terribly convenient. The , (Sorry, no, that’s of course part of , so I really don’t have any idea why the erofs-utils upgrade caused us issues. I know we use erofs inside our VM and testing machinery, but I don’t know exactly where. Most likely whatever is hanging actually comes after the call.) We don’t currently have any idea why this happens for this specific test, but we know that it happens reliably and across multiple platforms. None of this is very digestible or easy to debug for someone who isn’t experienced with Nix(OS), so I was hoping one of our contributors would be able to make a more minimal reproducer to be able to send upstream, or even figure out the bug. I just put this issue up as we were having to revert the upgrade in a hurry to unblock updates for users and I didn’t want it to be forgotten about. I don’t have the time myself to try and make a minimal reproducer, but please let me know if there’s anything else I could do that would be helpful.
It almost certainly comes from this invocation of : I'll hopefully have time to look at this in more detail soon.
The log doesn’t contain “Creating Nix store image...”, FWIW. Not sure if that’s relevant to whether that code is being invoked or not.
I haven't pinpointed what is to blame, but it appears the way prints progress may have changed between 1.7.1 and 1.8.1, which is causing the issues. When telling the tooling to not print any progress, image creation occurs much more quickly (though still quite slow as the machine closures with gitlab are large).

I assume it's something on our side that's to blame since I don't actually see the progress being printed during the timeouts, so I assume something is eating the output.
Oh, I know. Since erofs-utils 1.8, we unify and the usual mkfs logic, so also prints progress too. And yes, if that is not expected, is preferred to match erofs-utils 1.7.1...
thank you for tracking this!