This is happening on my nixos x86_64 machine too, so I don't think it's restricted to aarch64.

...along with tcp_bind6_error_addrinuse too

should target staging

Hmm for quite a few people it's breaking master though, so making them wait for the next staging cycle seems kinda mean.

fix'd up the commits

🤔 I ran into this when doing a staging-22.11 PR (#214874), shall we do a backport?

https://logs.nix.ci/?key=nixos/nixpkgs.214874&attempt_id=f696d55a-bec8-4b8a-8988-84cf1fa2bd80

Successfully created backport PR for staging-22.11:

• [Backport staging-22.11] libuv: expand the steaming pile of unsandboxable tests #214893

Funnily enough, this has nothing to do with flakiness. It's a kernel bug!

See https://utcc.utoronto.ca/~cks/space/blog/linux/KernelBindBugIn6016 (thanks vcunat for pointing this out).

Funnily enough, this has nothing to do with flakiness. It's a kernel bug!

See https://utcc.utoronto.ca/~cks/space/blog/linux/KernelBindBugIn6016 (thanks vcunat for pointing this out).

Ah, that explains why I couldn't reproduce OfBorg's failure. None of my machines run 6.x kernels yet.

@amjoseph-nixpkgs What 5.15 (presumably) revision do your machines run? It seems that it affects recent 5.15 versions as well, see https://lore.kernel.org/all/EF8A45D0-768A-4CD5-9A8A-0FA6E610ABF7@winter.cafe/.

Looks like you replied as I was editing away the stupidity of my first response :)

I just helped a user track down this issue, here's some data from the debugging, if it helps (I didn't come across this PR right away):

# Use a separate, temporary Nix store, so we can debug derivations that are already
# available in the main store
store="--store /tmp/store"
sudo rm -rf /tmp/store

# Fetch all build deps from the binary cache
drv="github:NixOS/nixpkgs/3954218cf613eba8e0dcefa9abe337d26bc48fd0#libuv"
nix print-dev-env $store $drv --substitute >/dev/null

# Build just the drv, without substitution
nix build --no-link --print-out-paths -L $store --no-substitute $drv

# Cleanup
sudo rm -rf /tmp/store

Hi @erikarvstedt, I determined that this was a kernel regression in 5.15 starting with 5.15.88, see the LKML thread I linked above: https://lore.kernel.org/all/EF8A45D0-768A-4CD5-9A8A-0FA6E610ABF7@winter.cafe/