| 21 Apr 2026 |
 dramforever | right, the thing i was wondering is if these things have been significantly worked on since i haven't heard much, which could be just me not listening to the right places | 04:54:43 |
| dramforever | but it sounds like it's more of a "no these are still problems" situation | 04:54:59 |
| dramforever | * but it sounds like it's more of a "no these are still very much problems" situation | 04:55:05 |
 K900 | They haven't no | 04:58:47 |
| dramforever | thanks | 04:59:03 |
 mynacol | I am the author of a partial rewrite of the deno package. I cannot reproduce the build failure on x86_64-linux. Is the correct approach to try a rebuild? | 14:54:32 |
| mynacol | * I am the author of a partial rewrite of the deno package. I cannot reproduce the build failure on x86_64-linux (the other systems built fine). Is the correct approach to try a rebuild? | 14:55:02 |
 hexa | uh, I built that yesterday on my desktop | 14:57:08 |
| hexa | was a fun hour or two, but it did build for me | 14:57:17 |
| hexa | restarted and bumped, because it's needed for yt-dlp | 14:57:47 |
 mdaniels5757 | Redacted or Malformed Event | 23:20:49 |
| mdaniels5757 | * Also deno on aarch64-linux is both failing and cached? https://hydra.nixos.org/build/326614946
% nom-build -A deno --max-jobs 1 --cores 40
this path will be fetched (36.40 MiB download, 154.06 MiB unpacked):
/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12
copying path '/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12' from 'https://cache.nixos.org'
┏━━━ Downloads │ Host
┃ │ │ │ localhost
┃ │ ↓ 1 │ │ https://cache.nixos.org
┗━ ∑ ↓ 0 │ ↓ 1 │ ⏸ 0 │ Finished at 23:16:11 after 5s
/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12
| 23:20:57 |
| mdaniels5757 | * Also deno on aarch64-linux is both failing and cached? https://hydra.nixos.org/build/326614946
% nom-build -A deno
this path will be fetched (36.40 MiB download, 154.06 MiB unpacked):
/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12
copying path '/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12' from 'https://cache.nixos.org'
┏━━━ Downloads │ Host
┃ │ │ │ localhost
┃ │ ↓ 1 │ │ https://cache.nixos.org
┗━ ∑ ↓ 0 │ ↓ 1 │ ⏸ 0 │ Finished at 23:16:11 after 5s
/nix/store/hlcqry5vcs08x9dqm8gdlrs748fc433f-deno-2.7.12
| 23:21:19 |
| mdaniels5757 | Deno is also failing on aarch64-linux (https://hydra.nixos.org/build/326614946); /nix/store/w6xna8ysbkqxgcwzjv3wvdlqhqxnghj6-deno-2.7.12 is on the community builder so it definitely has succeeded before. | 23:23:44 |
| hexa | loving flaky tests on a 2 hour build | 23:26:20 |
| hexa | get's me in a mood | 23:26:26 |
| 22 Apr 2026 |
| mynacol | Oh man, why are there so many issues after merging my PR? 😅 I had maybe one strange build failue in the ~30 test builds while developing that PR. I created https://github.com/NixOS/nixpkgs/pull/512137 to skip at lest one failing test. | 08:42:47 |
| mynacol | And I don't understand the hydra website. https://hydra.nixos.org/build/326614946 and https://hydra.nixos.org/build/326734886 succeeded but the log shows errors; and https://hydra.nixos.org/build/326734884 and https://hydra.nixos.org/build/326734883 failed (timed out), but in the logs it succeeded. Is that a known Hydra bug/inconsistency? | 08:42:50 |
 Mindavi | In reply to @mynacol:mynacol.xyz
And I don't understand the hydra website. https://hydra.nixos.org/build/326614946 and https://hydra.nixos.org/build/326734886 succeeded but the log shows errors; and https://hydra.nixos.org/build/326734884 and https://hydra.nixos.org/build/326734883 failed (timed out), but in the logs it succeeded. Is that a known Hydra bug/inconsistency? Rebuilds keep the old logs as well, is that what you maybe see? | 08:44:26 |
| mynacol | I just clicked on the log of e.g. https://hydra.nixos.org/build/326734886 and it shows failures despite succeeding. Could very well be an old log, but then how do I get/see the new one? | 08:46:28 |
| hexa | Huh, odd | 08:47:00 |
| 23 Apr 2026 |
 Arian | Moving this from private channel to public because the incident is now public
https://www.githubstatus.com/incidents/zsg1lk7w13cf
I think we should disable merge queues in nixpkgs as a pre-caution. Just had a repo corrupt itself at work due to this incident.
We don't have squash merges in nixpkgs so maybe we're not affected but it'd prefer to be cautious.
@lassulus:lassul.us do you have permission bits to disable this on the repo? | 20:17:40 |
 Winter | not sure i love that idea | 20:23:50 |
| Winter | cc mdaniels5757 | 20:24:21 |
| Winter |
| 20:24:27 |
| Arian | I'm hoping we're not affected because of us not having squash/rebase enabled ... But who knows | 20:26:01 |
 emily | I don't think there's reason for us to act if they've explicitly narrowed it down that way | 20:28:40 |
| emily | (though admittedly they also don't say "corruption", do you have any details on that?) | 20:29:08 |
| emily | I expect any issue along those lines is far less likely with merge commits since it's not rewriting commits | 20:29:21 |
| emily | i.e. the way they've narrowed it down makes me strongly suspect it's an issue in their reimplementation of git replay type functionality | 20:29:42 |
