| 13 Mar 2026 |
 emily | anyway no super strong feelings. I just greatly prefer having only the minimum reactive version pinning | 12:01:52 |
 Ramses 🇵🇸 | I don't disagree. I just wanted to fix the conflict and opted for what I felt was the conservative approach of sticking to what seemed to have been the common practice for this package (I checked quite a bit of the git history to check this). I worried that otherwise I got an annoyed maintainer later on asking why I unpinned their input. | 12:03:02 |
| emily | especially when it's about EOLs. you can have upstreams that stay reasonably in sync with their dependencies' cycles but need manual work for each bump. but less so for supporting only the oldest supported version and still updating in a timely fashion | 12:03:12 |
| Ramses 🇵🇸 | Seems like the kind of situation where you end up annoying someone in any case | 12:03:16 |
| emily | yeah I don't think you did anything wrong :) | 12:03:43 |
| Ramses 🇵🇸 | I fully agree that we should avoid pinning, but a merge commit in -next without a PR to give the maintainers a chance to weigh in, didn't seem like the right place to fix that | 12:05:15 |
| emily | procedurally I err very much in favour of stuff landing on staging, because the workload is high and the contributors are deeply knowledgeable on average and being a time-sensitive maintainer of last resort is no fun if it also lacks the authority to make judgement calls | 12:05:24 |
| emily | but we're violently agreeing I think 😆 | 12:05:46 |
| emily | IMO it was the -next commit that made that call rather than the merge. but those aren't great for visibility for maintainers especially if they're pushed directly, yeah | 12:06:37 |
| emily | (thank you for doing the merge!) | 12:06:45 |
| emily | we really need to move to a PR-only workflow for staging, including for merges. I'll hopefully write up plans for that soon... | 12:07:23 |
| emily | visibility and auditing is pretty awful right now | 12:07:35 |
| Ramses 🇵🇸 | Yeah, but the merge needs to arbitrage between the two (fix on -next, regular bump on master) | 12:07:40 |
| Ramses 🇵🇸 | I noticed a prior issue from you about that, while searching for docs on how to do this merge | 12:08:12 |
| Ramses 🇵🇸 | That would make things a lot more transparent (but potentially also a bit more laborious) | 12:08:39 |
| Ramses 🇵🇸 | I wasn't totally sure whether we were, so good to know! 😁 | 12:09:26 |
| emily | yeah, making the workflow not painful is the main consideration. I think having a pre-made ref you can push to would help offset that | 12:11:29 |
| emily | as well as specifically avoiding mass rebuilds and eval issues percolating to -next which sucks | 12:11:55 |
| emily | I've thought more lately about how we can avoid conflicts arising in the first place though | 12:12:07 |
| emily | the ideal would be that we don't get two PRs that don't know about each other both landing in different "timelines" at all | 12:12:38 |
| emily | multiple merge queues kind of dampen the benefit of having them | 12:13:52 |
| Ramses 🇵🇸 | Yeah, AFAICT, the commit to switch kitty to a non-EOL go could've gone to master, which would've avoided this conflict and discussion. But maybe there were other reasons why it didn't, I don't have the context | 14:20:46 |
| Ramses 🇵🇸 | But in general indeed it's hard to know when you make a PR to master, that there are any conflicting changes on staging(-next). And even if we detected this in CI, I don't think it's always possible to modify the changes such that they cleanly apply on both branches | 14:22:24 |
| emily | well, I had some ideas for making it so that they always can :) but which ones are practical, not sure | 15:52:03 |
| emily | at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be goo | 15:52:22 |
| emily | * at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be good | 15:52:33 |
| Ramses 🇵🇸 | In reply to @emilazy:matrix.org
at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be good Definitely | 17:58:55 |
| 15 Mar 2026 |
 whispers [& it/fae] | hai. chromium seems to be having issues on staging-next on my system. if i build (well, substitute) chromium on the latest staging-next, trying to run it immediately sigills on my system (x86_64-linux nixos):
~> nix run github:nixos/nixpkgs/521d05a303dcd44e66f27ad94cc244adaabace12#chromium
[0314/233404.245952:ERROR:third_party/crashpad/crashpad/util/process/process_memory_range.cc:75] read out of range
fish: Job 1, 'nix run github:nixos/nixpkgs/52…' terminated by signal SIGILL (Illegal instruction)
whereas nix run github:nixos/nixpkgs/master#chromium launches successfully. this might be a »my system is fucked issue«, but i'm wondering if anyone else can maybe reproduce this? | 03:37:52 |
| whispers [& it/fae] | …and now that i post i remembered there's a nixos test. that indeed does fail, so i don't think it's just a me thing. fun | 03:40:38 |
| whispers [& it/fae] | * …and now that i post i remembered there's a nixos test. that indeed does fail as well, so i don't think it's just a me thing. fun | 03:40:43 |
