| 29 Jun 2026 |
 Myria | So, at most 2 weeks, the usual length of a cycle. We're already 2-3 days in. | 15:23:20 |
 whispers [& it/fae] | if you want to merge the update into Nixpkgs now, iirc it's fine to merge into staging-next if you want, though it won't can't reach master any faster than that staging-next merge does. | 15:23:57 |
| whispers [& it/fae] | * if you want to merge the update into Nixpkgs now, iirc it's fine to merge into staging-next if you want, though it won't/can't reach master any faster than that staging-next merge does. | 15:24:05 |
 Grimmauld (any/all) | Why does so much shit want latest rust all the time anyways? Like surely you can go back some versions for most boring applications.... | 15:26:16 |
 orekushii | Thank you for the responses! | 15:28:47 |
| orekushii | It's no problem, I'll revisit it once the merge lands | 15:29:08 |
 Ben Sparks | anything after 1.80 is fair game (1.82 promoted aarch64-darwin to tier 1, for example). maybe 1.85 for edition 2024 | 15:30:51 |
| Ben Sparks | * anything after 1.80 is fair game (1.82 promoted aarch64-darwin to tier 1, for example). maybe 1.85 for edition 2024 (but non-bleeding edge would be ncie) | 15:32:21 |
 Lach | In reply to @brightone:matrix.org
Hey everyone! I'm unfamiliar with the staging workflows, and was looking to update qsv to 21.1.0, which requires Rust 1.96.0. I found https://github.com/NixOS/nixpkgs/pull/525279 (rust: 1.95.0 -> 1.96.0), which was merged to staging a month ago. What are the next steps to land Rust 1.96 in master? How to monitor progress? I would appreciate any hints :) https://nixpk.gs/pr-tracker.html is good for that | 15:40:08 |
 emily | the new features are nice and since the compatibility guarantees are strong it's cheap to update | 15:42:20 |
| emily | and distros like Debian stable ship versions so old that it's miserable to support, so either you make yourself very sad or you just roll with rustup | 15:42:47 |
| emily | I think it's a good thing largely and it's up to distros to meet the challenge of keeping up | 15:43:07 |
| emily | and yes, it's fine to base on/merge into staging-next | 15:43:23 |
| emily | the basic stuff gets cached pretty quickly so you should be able to do your PR pretty normally on top of it after the first few days of a cycle | 15:43:38 |
 K900 | OK fucking hell do I have to bisect paperless | 16:44:54 |
 dotlambda | I can look into it | 16:47:39 |
| K900 | Have fun | 16:47:47 |
| K900 | It makes no fucking sense | 16:47:50 |
| K900 | I'll just let the bisect run and pray | 16:47:54 |
| dotlambda | It's probably more efficient to only look at the direct dependencies | 16:48:22 |
| Grimmauld (any/all) | Consider: If hydra GC eats a dependency of a python package, and doCheck happens to be false, it'll break WAY WAY later if something is imported but required dependencies are lost as requisites | 16:51:09 |
| K900 | Nothing to do with Hydra | 16:51:21 |
| K900 | It's just failing tests in increasingly stupid ways | 16:51:31 |
| Grimmauld (any/all) | the GC shenanigans worry me a lot with optional dependencies, but on python it could be even worse | 16:51:36 |
| K900 | My money is on filelock | 16:52:44 |
| K900 | Which they abuse in absolutely abhorrent ways | 16:52:51 |
| K900 | But the fun part is that if I downgrade filelock, setuptools explodes | 16:54:51 |
| Grimmauld (any/all) | python 3.14? | 16:56:04 |
| K900 | Nope | 16:56:08 |
| K900 | Same thing on 3.13 | 16:56:11 |
