 | Staging | 371 Members |
| Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/ | 122 Servers |
| Staging | 371 Members |
| Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/ | 122 Servers |
| Sender | Message | Time |
|---|---|---|
| 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:
which split that code into 2 cfg conditionals with rustversion::before and rustversion::since based on nightly version where those traits got removed
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 < Devhttps://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:23:10 |
| 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:
cfg conditionals with rustversion::before and rustversion::since based on nightly version where those traits got removed
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 < Devhttps://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:23:51 |
| 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:
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 < Devhttps://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 |
 vcunat | Well, if you need package update which isn't built by Hydra yet, you don't have much choice really. | 07:30:29 |
| vcunat | But generally you can put your mass-rebuild commits atop some master commit and select staging as the merge target. | 07:31:05 |
| vcunat | 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 |