NixOS 24.05 packages

last thread: Node.js 20 starter

Packages: (not a permalink, I update this)

NixOS 24.05 is out, and I’ve ported a set of its packages to Glitch. As usual, here’s what came up in doing that.


Nix runs builds in an isolated environment usually (not on Glitch, as the sandboxing features require permissions we don’t have). This way the package build only has access to its explicit source files and dependencies. Those dependencies, e.g. the compiler, come as the outputs of other package builds. But then how does Nix build the compiler (or technically this is defined in Nixpkgs, the repo that defines all these builds, rather than the package manager itself)? The answer turns out to be that it downloads a prebuilt compiler. (But how do you download if you don’t have curl? There’s an escape hatch where the package manager itself can download something for you.) This primordial prebuilt compiler, is the so-called boostrap tools. Okay it comes with a bunch of other build tools too, not just a C compiler, but still.

The bootstrap tools hadn’t changed since 2019, but in this release, it did. And with it came a new-ish GCC, built with a new-ish glibc. And with a new-ish glibc came syscalls that don’t work on Glitch.

While we have configured an “overlay” that tells Nixpkgs to patch glibc to understand how Glitch handles these syscalls, the patches don’t apply to these prebuilt bootstrap tools, which are simply downloaded instead of being built from source.

So I compiled a separate patched copy of these bootstrap tools. But unfortunately, I found out that there is no way to configure Nixpkgs system to use my custom bootstrap tools instead of the stock ones. I sent a PR to add a way to do it though (stdenv: Allow user to supply their bootstrapFiles set of tools by wh0 · Pull Request #317119 · NixOS/nixpkgs · GitHub).

The result of this is now I have to modify Nixpkgs.


glibc started using the new system call fchmodat2. It’s the same story from all the other times a new system call came up. Glitch doesn’t support it, Glitch gives EPERM, but the library only understands ENOSYS to mean that the system doesn’t support it, so it interprets it as just failing. I added a new patch for this.


coreutils added a new test ls/ which doesn’t work right without setfacl support. And this took me a while to figure out why this was a problem.

  1. Lots of other coreutils tests are about access control lists, and they haven’t bothered us.
  2. Those old are written so that they skip instead of failing if there’s no access control list support.
  3. This new test is also written that way.
  4. But actually it’s written subtly wrong. It uses require_acl_ instead of require_setfacl_. BTW, if someone could tell the team (, that’d be great.
  5. When require_acl_ decides whether or not to skip, it only checks that the setfacl program is present, not that it works.
  6. But setfacl does work, you can run it on Glitch just fine.
  7. In fact you can have Nix not delete the failed build directory and go in there and run the failed tests, and it passes just fine.
  8. But the Nix build of coreutils fails every time.
  9. You can use nix-shell to run the build interactively step by step.
  10. And when you do, it builds fine.
  11. It turns out Nix runs builds with seccomp that prevents setxattr (nix/src/libstore/build/ at 2.18.1 · NixOS/nix · GitHub).
  12. It turns out setfacl is implemented on Linux with setxattr.
  13. It turns out that seccomp works on Glitch.

So anyway, I added a patch to fix the require_acl_ to be require_setfacl_, and now the test gets skipped like all the other acl-related tests. The resulting ls program works fine.


I don’t know why this didn’t come up earlier, I had built the exact same version of libgit2 before, 1.7.2. But apparently there are a few tests called “threadmania” and “fast_thread_rush” etc., and for some reason not know to me, making and joining few threads quickly is broken on Glitch (Joining threads leaves something behind?).

I added a patch to reduce the number of repetitions in those tests.


Some unhappy situation happened where we now have to build two major versions of this dependency.


OpenEXR 3 moved a lot of files around. Fortunately, I was able to write a new version of the previous patch (reduces repetitions of a thread test) that applies to version 3, and I can have the right versions of the patch applied to the right versions of the package.


Just as a note to myself, the util-linux package doesn’t seem to build right when building with multiple cores.

Okay let’s get to the point of why this is in the Glitch Feedback section.


Node.js 22 is out. But something about it takes way longer to build than Node.js 20. I can’t finish building it in 12 hours. It remains unbuilt (view). See the times on these public builds (these machines are faster than the project containers we get on Glitch, but just compare between the Node.js versions).

GitHub Actions


Glitch :pray: pls let projects go longer between mandatory restarts. Okay I asked, at least.

1 Like