 | Staging | 374 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/ | 124 Servers |
| Staging | 374 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/ | 124 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 May 2026 | ||
 Vladimír Čunát | Maybe we'd better simply abandon tmpfs for the builds in the infra. | 14:01:16 |
 hexa | I thought about backing it with additional swap for spillover | 14:01:21 |
| hexa | so we'd get the best of both worlds | 14:01:32 |
| Vladimír Čunát | (we'll not in the best channel for this topic, but it doesn't really matter) | 14:01:40 |
| Vladimír Čunát | * (we're not in the best channel for this topic, but it doesn't really matter) | 14:01:46 |
| hexa | Redacted or Malformed Event | 14:02:09 |
| hexa | Redacted or Malformed Event | 14:02:11 |
| Vladimír Čunát | Maybe, if it doesn't spill commonly. | 14:02:13 |
| Vladimír Čunát | tmpfs + disk swap is less efficient than normal FS on the same drive in case it does spill. | 14:02:48 |
| hexa | is that so? | 14:03:14 |
| Vladimír Čunát | At least I think it was that way. Probably due to better work with consecutive storage of files. | 14:03:49 |
| Vladimír Čunát | Well, just conclusions here. I think it's unlikely to make i big difference for our use case. Killing tmpfs is just easier. I had done it on some of our machines already. | 14:05:14 |
 teutat3s | https://github.com/rust-lang/rust/issues/153879 | 14:25:51 |
 Alyssa Ross | I'm seeing a hash mismatch for yara on staging. Don't suppose anybody apart from r-ryantm got the old hash? Would like to see what's changed. | 14:49:52 |
| Alyssa Ross | aha https://github.com/NixOS/nixpkgs/pull/518630 | 14:50:27 |
 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 (he/him) | 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 |