| 11 Oct 2025 |
 ris_ | this kinda brings me back to "i'm amazed wrapped compilers work for wasm at all" | 10:51:40 |
| ris_ | falling back to "all hardening flags", i think, was due to me trying to be minimally intrusive when making an already-major PR and not wanting to default to "no hardening" and be the reason someone didn't realize all their hardening flags have been off for years | 10:58:34 |
| ris_ | now that it's separate from the big PR that introduced it, the change to making it hard-fail, on its own, may not be too disruptive | 10:59:30 |
 Yureka (she/her) | fwiw, some more build failures: https://spectrum-os.org/lists/archives/spectrum-devel/82249ddc-ae1a-4e3a-a6ae-bb4717243fca@yuka.dev/ | 10:59:42 |
| ris_ | i think the expectation would be that the compiler would have hardeningUnsupportedFlags properly defined so this would not be an issue | 11:03:56 |
 K900 | Then maybe we should throw if we have neither? | 11:04:30 |
| ris_ | * i think the expectation was that the compiler would have hardeningUnsupportedFlags properly defined so this would not be an issue | 11:04:48 |
| ris_ | these all sound like sensible suggestions | 11:05:12 |
| Yureka (she/her) | I still don't think all supported hardening flags should be enabled by accident | 11:05:26 |
| Yureka (she/her) | given hardening flags also have performance penalties | 11:05:37 |
| Yureka (she/her) | that's what pkgsExtraHardening is for | 11:05:48 |
| K900 | I think what we want is probably
if [compiler explicitly declares supported] then [that] else [some set of sane defaults] - [compiler explicitly declares unsupported] | 11:07:08 |
| 12 Oct 2025 |
|  Anton (he/him) changed their display name from Anton to Anton (he/him). | 13:17:58 |
 emily | can we eat ~10k Ruby rebuilds on -next to fix extension modules with LLVM 21? | 14:21:25 |
| emily | could be conditioned on Darwin only for now | 14:21:30 |
 Vladimír Čunát | Sounds OK to me. | 14:46:55 |
| emily | re the whole doing periodic merges via PR thing | 15:55:00 |
| emily | what if we just used the merge queue to ensure that nothing goes into master or staging-next that won't cleanly merge into the branches after it? | 15:55:17 |
| emily | and switched things around so that, if you would cause a merge conflict on a later branch, you instead merge it into the later branch | 15:55:34 |
| K900 | That is going to completely stall some PRs | 15:55:39 |
| emily | and then "backport" it to the earlier ones | 15:55:40 |
| K900 | I think | 15:55:43 |
| emily | stall howso? | 15:55:51 |
| K900 | Oh god that's going to be so painful | 15:55:53 |
| emily | why? | 15:55:58 |
| K900 | Because nothing will backport cleanly and then we have to check backports and oof | 15:56:12 |
| emily | it means the conflicts can be resolved per-PR | 15:56:03 |
| emily | rather than all at once | 15:56:08 |
| emily | I don't understand | 15:56:22 |
| emily | that's exactly the case of periodic merges failing | 15:56:26 |
