| 16 Nov 2025 |
 dotlambda | In reply to @vcunat:matrix.org
The next one won't reach 25.11. I'm aware | 15:08:07 |
 Vladimír Čunát | I think we need staging-next-25.11 already for the auto-merging workflow to work right. | 15:08:32 |
 leona | i.e. just give your PR to staging, the backport staging-25.11 label | 15:08:35 |
| dotlambda | In reply to @leona:leona.is
Primarily we have staging-25.11 because the current staging branch won’t reach 25.11 anymore and we want to make it possible directly create the backport PR to staging-25.11. To not complicate things too much, we already create the staging-next-25.11 branch even though it has no technical sense until branchoff So it's just there for the regular automatic merges? | 15:08:36 |
| dotlambda | I thought those don't make too much sense before release-25.11 is created | 15:09:02 |
| leona | Yes. It would work without it, but then the workflow would again look different than for the other branches and I didn’t like it | 15:09:23 |
| dotlambda | I think this is more confusing than helpful and in the future, staging-next-26.05 should only be created after the last merge of staging next into master before branch-off | 15:10:00 |
| leona | We currently auto merge
master -> staging-next -> staging
master -> staging-next-25.11 -> staging-25.11
| 15:10:13 |
| leona | You don’t want staging-25.11 to exist in this stage too? This was an explicit wish by multiple contributors because previously they forgot to backport PRs from staging that didn’t reach the release | 15:11:27 |
| leona | I mean yes, we could of course create staging-next-25.11 only at the time of branch off | 15:12:26 |
| dotlambda | The latter of those automatic merges will have to be changed anyway (from master to release-25.11) so until that time why not directly merge master into staging-25.11? | 15:13:27 |
| dotlambda | In reply to @leona:leona.is
You don’t want staging-25.11 to exist in this stage too? This was an explicit wish by multiple contributors because previously they forgot to backport PRs from staging that didn’t reach the release It certainly should. I only talking about -next | 15:13:58 |
| dotlambda | * It certainly should. I'm only talking about -next | 15:15:03 |
| leona | I think that should be possible. The only reason why this currently works this way was me thinking of a workflow in a relatively short time | 15:16:05 |
| 17 Nov 2025 |
|  MATE changed their display name from mate to MATE. | 06:11:44 |
|  Uraraka ~ Ochaco changed their display name from dwd to Peri. | 23:36:50 |
| 18 Nov 2025 |
| Uraraka ~ Ochaco changed their profile picture. | 01:17:55 |
| Uraraka ~ Ochaco changed their profile picture. | 01:23:24 |
 dish [Fox/It/She] | just for documentation purposes: I'm planning to open my release notes organization PR(alphabetizing all non-highlight release notes) after release-25.11 branchoff on nov 25. After that point, anyone adding to the release notes should ensure the alphabetization is retained. | 02:47:23 |
| dish [Fox/It/She] | also, is #461884 considered a release blocker, considering its(at least from my glance at it) large severity? | 02:48:19 |
| dish [Fox/It/She] | * also, is #461884 considered a release blocker, considering its(at least from my glance at it) large severity? It's not in the release blockers project which is why I ask. | 02:48:29 |
 Tristan Ross | Can't speak for release managers but https://github.com/NixOS/nixpkgs/issues/461884 says this:
python3.withPackages: python wrapper doesn't load generated env on x86_64-linux (emulated on darwin with rosetta)
Considering it's a bug and the user is on x86_64-linux but emulated through rosetta. Emulation doesn't work the same usually as real hardware, especially rosetta so as long as it doesn't affect real x86_64-linux systems then I say it's not a blocker.
| 02:55:57 |
| Tristan Ross | * Can't speak for release managers but https://github.com/NixOS/nixpkgs/issues/461884 says this:
python3.withPackages: python wrapper doesn't load generated env on x86_64-linux (emulated on darwin with rosetta)
Considering it's a bug with argv0 and the user is on x86_64-linux but emulated through rosetta. Emulation doesn't work the same usually as real hardware, especially rosetta so as long as it doesn't affect real x86_64-linux systems then I say it's not a blocker.
| 02:57:35 |
| dish [Fox/It/She] | further down the thread theres a bug report mentioning that it effects other sorts of systems | 02:57:43 |
| Tristan Ross |
I ran into this bug today trying to build a package for aarch64-linux under x86_64-linux using QEMU/binfmt_misc emulation, so it's not Darwin-specific.
Still emulated
| 02:58:12 |
| dish [Fox/It/She] | fair enough | 02:58:25 |
| Tristan Ross | And it sounds like it's a bug with argv0 handling | 02:58:33 |
| Tristan Ross | I haven't been affected on a real aarch64-linux system | 02:58:59 |
| Tristan Ross | But if anyone doesn't say its a problem on real systems, I don't see why it would be a blocker | 02:59:20 |
| Tristan Ross | There's likely already a ton of broken things with emulated systems still, especially around unit tests | 02:59:48 |
