| 10 Apr 2026 |
 emily | but very hard for me to imagine removing volatile turning correct code into a miscompilation esp. when it was added in a "fight the optimizer" folly. ah well | 11:05:57 |
| emily | libraries upstream of the whole universe and pervasive UB that actively breaks, name a more iconic duo | 11:06:55 |
 Randy Eckenrode | Alas, it appears the libiconv issue that Autoconf tests is not addressed. Still need to see on man-db. | 11:36:39 |
 Alyssa Ross | If upstream has applied it I don't think that makes sense (rebuilds aside) | 12:20:25 |
 K900 | Rebuilds yeah | 12:20:45 |
| K900 | 18k of them | 12:20:47 |
| K900 | I guess we're not that far in yet | 12:20:59 |
 Yureka (she/her) | orrr | 13:03:27 |
| Yureka (she/her) | the other scipy failures are also because of the remaining volatile | 13:03:38 |
| Yureka (she/her) | Redacted or Malformed Event | 13:03:39 |
 sampointon | Could someone with a Mac try a build of gts with NIX_CFLAGS_COMPILE=--std=gnu17? At this point I'm suspicious of any C FTBFS as being fallout from the autotools bump and the new C23 assumption, but it's only happening on Apple platforms and I don't have one of those | 13:08:02 |
| Yureka (she/her) | So the only way I can get scipy to build on my macbook is to revert 3f6e928d34aca977bd5d4191e6d2c2338a342db5 "Declare result as volatile to keep compilers from optimizing it out" fully | 13:16:58 |
| Yureka (she/her) | Redacted or Malformed Event | 13:17:12 |
| Yureka (she/her) | but I don't know if that causes other issues on other platforms | 13:17:30 |
| K900 | Fun | 13:20:20 |
| Randy Eckenrode | Adding env.NIX_CFLAGS_COMPILE=-std=gnu17 makes it build for me. | 13:22:25 |
| sampointon | Cheers. I'll put together a PR and see if it makes sense to unconditionally set it or if the Linux rebuild damage would be too much | 13:24:42 |
| Randy Eckenrode | I didn’t check the source, but the error looked similar to others that were due to the removal of support for K&R-style function declarations. | 13:45:38 |
| Randy Eckenrode | * | 13:46:02 |
| Randy Eckenrode | man-db also fails, which is technically an improvement. It previous hung in one of its tests IIRC. | 15:37:50 |
| 12 Apr 2026 |
|  leona changed their profile picture. | 12:15:43 |
| sampointon | I think the zeroconf failure on x86_64 Linux is a flaky test. I can't reproduce it locally and previous staging-next iterations have seen the same failure (test_run_coro_with_timeout), which then clears up next run but comes back a few later | 13:50:43 |
| sampointon | Looking at the test code, it's also not exactly testing zeroconf, but actually really asyncio, and it looks suspiciously like it could fail in weird ways if a timeout unexpectedly does/doesn't occur. So I think it's more likely that the test is wrong rather than something being badly wrong with asyncio | 13:51:48 |
| sampointon | https://github.com/NixOS/nixpkgs/pull/509275 - in principle this could go via staging for the next cycle as well, but there's no guarantee it wouldn't be annoying flake again on the next run of this cycle | 14:30:07 |
| 13 Apr 2026 |
 Sandro 🐧 | the rebuild count is inflated because of home assistant, go send it | 12:08:46 |
 vcunat | I see no successful build of that package yet, so I don't think the rebuild amount is really relevant:
https://hydra.nixos.org/eval/1824377?compare=unstable&filter=.zeroconf. | 12:14:17 |
|  Harinn joined the room. | 12:18:16 |
| 14 Apr 2026 |
| vcunat | Have I missed any followups around scipy failures? I haven't managed to find anything on nixpkgs git+github. | 12:49:38 |
 hexa | weren't they openblas induced? | 12:50:08 |
| Yureka (she/her) | No. I haven't submitted anything because I don't know a good solution. | 12:50:13 |
