| 11 May 2026 |
 ghpzin | Maybe needed to explain better, at least from what I understood.
Rust removed those 2 traits around 2026-01-27 nightly version:
https://github.com/rust-lang/rust/commit/0eaef592336f0c12cd9648c989f360308d842d2d
chromium noticed it in their regular rollout:
created issue: https://issues.chromium.org/issues/480176523 reported it upstream to bytemuck: https://github.com/Lokathor/bytemuck/issues/343 made temp fix that removed 2 lines with these traits from bytemuck: https://github.com/chromium/chromium/commit/c514ee88dfe8c4dbc37a1217712b8044d1593d91#diff-2b53859a0f4fbe01ff939d29390711f4ae2f2be3921e54506fdc343593b8002c bytemuck made their fix: https://github.com/Lokathor/bytemuck/pull/344 which split that code into 2 cfg conditionals with rustversion::before and rustversion::since based on nightly version where those traits got removed
chromium pulled next version of bytemuck (1.25.0) with that fix and then removed temp fix: https://github.com/chromium/chromium/commit/90b77efcecb262823fadb67b0ce218846cd9e756 rustc in nixpkgs got to 1.95 where those traits are removed.
Assuming you would use nightly to build chromium everything is fine, nightly versions before and after work.
But if you use stable toolchain with RUSTC_BOOTSTRAP afaik rustversion does not do compares between "stable" and "nightly".
It just sets rustversion::before(some_date_here) as true and rustversion::since(some_date_here) as false, because comparison is implemented as PartialOrd that way:
Stable | Beta < Nightly < Dev
https://github.com/dtolnay/rustversion/blob/a1dfebcd35f6082886548156f02f3832f52c0853/src/bound.rs#L51-L55
So on stable rust we always get part with these traits (rustversion::before(2026-01-27)), unless we revert temp fix removal in https://github.com/chromium/chromium/commit/90b77efcecb262823fadb67b0ce218846cd9e756 that removes them.
It worked with rust 1.94 because it still had traits, probably why backport to versions before was needed:
https://github.com/NixOS/nixpkgs/blob/6443f9dfb27aa6defabd6104784332020a319af1/pkgs/applications/networking/browsers/chromium/common.nix#L614-L625
Now it is the opposite. | 15:24:11 |
|  Eli Saado joined the room. | 19:13:19 |
 sterni | vcunat: https://github.com/mirage/ca-certs/releases/tag/v1.0.3 should fix ocamlPackages.ca-certs. I’m currently travelling so may take a few days for me to get around to it (also can’t reply via email on the PR anymore, it seems) | 21:03:58 |
 hexa | staging-26.05 when | 21:52:36 |
| hexa | nvm, we have backport labels | 21:59:54 |
| hexa | thx | 21:59:54 |
| 12 May 2026 |
|  Eymeric joined the room. | 06:20:26 |
|  Guillaume joined the room. | 06:35:58 |
|  uku joined the room. | 07:17:30 |
| uku | hi, i have a package i'd like to update, but it now depends on rust 1.95.0. should i wait for this staging cycle to complete and open a draft pr targeting master, or is there some procedure for updates like these? | 07:20:00 |
 K900 | You can target staging directly | 07:20:51 |
| K900 | Or staging-next, if Rust 1.95.0 is in that | 07:20:57 |
| uku | it is i believe | 07:21:17 |
| uku | thank you! | 07:21:19 |
 WeetHet | Targeting staging is cursed, you need to build a lot of stuff | 07:24:21 |
 Vladimír Čunát | Well, if you need package update which isn't built by Hydra yet, you don't have much choice really. | 07:30:29 |
| Vladimír Čunát | But generally you can put your mass-rebuild commits atop some master commit and select staging as the merge target. | 07:31:05 |
| Vladimír Čunát | Of course there's a risk of conflicts, but usually it's not high. And it minimizes the amount of rebuilds done locally. | 07:31:34 |
 emily | @k900:0upti.me do you feel like cross-building some Qt stuff for https://github.com/NixOS/nixpkgs/pull/518539 | 12:40:08 |
| emily | (does Qt exercise Meson anywhere?) | 12:40:17 |
| K900 | Not directly | 12:41:10 |
| K900 | Qt cross is already a fuck | 12:41:16 |
| K900 | It's probably fine to make it more fuck | 12:41:35 |
| emily | it's more about not knowing whether CMake/Meson cross actually work at all after this yet | 12:46:48 |
| emily | (though they ought to) | 12:46:51 |
| K900 | Cmake cross never works, it usually just happens to kinda do the right thing by complete accident | 12:48:13 |
| emily | ok but the PR is literally moving around stuff we have to make CMake cross work :P | 13:28:21 |
 emily | I can fix this tomorrow or the day after tomorrow | 19:58:42 |
| 13 May 2026 |
| emily | vcunat: just checking on this? not sure when the first 26.11 cycle is due | 16:38:32 |
 leona | at least not in the next 7-10 days ^^ | 16:42:24 |
