gnome: 49.4 -> 50.0

[vitorpavani]

Bump core GNOME packages from 49.x to 50.0 ("Tokyo"), released 2026-03-18.

Packages updated:

• mutter: 49.4 → 50.0 (also bumps libmutter_api_version 17 → 18)
• gnome-shell: 49.4 → 50.0
• gnome-control-center: 49.5 → 50.0
• nautilus: 49.4 → 50.0
• gdm: 49.2 → 50.0

Dependency bumps required by GNOME 50:

• gjs: 1.86.0 → 1.88.0
• libinput: 1.29.2 → 1.30.2
• pipewire: 1.4.10 → 1.6.2
• libglycin: 2.0.8 → 2.1.0
• blueprint-compiler: 0.18.0 → 0.20.2
• gexiv2: 0.14.6 → 0.16.0
• gsettings-desktop-schemas: 49.1 → 50.0

Notable changes in GNOME 50:

• Wayland-only: X11 session removed from Mutter (X11 apps still work via XWayland)
• Parental controls with screen time, bedtime schedules, auto-lock
• Accessibility: Orca overhaul, Reduced Motion option, improved braille
• Remote Desktop: hardware acceleration (Vulkan/VA-API), HiDPI, camera redirection
• Display: improved VRR, fractional scaling, HDR screen sharing, color management v2

Release notes: https://release.gnome.org/50/

Things done

• Built on platform:
  • x86_64-linux
    • mutter ✅
    • gnome-shell ✅
    • gnome-control-center ✅
    • nautilus ✅
    • gdm ✅
    • gjs ✅
    • libinput ✅
    • pipewire ✅
    • libglycin ✅
    • blueprint-compiler ✅
    • gexiv2 ✅
    • gsettings-desktop-schemas ✅
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
    • mutter: passthru.tests.libdirExists ✅ (verifies libmutter-18 dir exists)
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
  • gjs --version → gjs 1.88.0 ✅
  • gnome-shell --version → GNOME Shell 50.0 ✅
  • mutter --version → mutter 50.0 ✅
  • gnome-control-center --version → gnome-control-center 50.0 ✅
  • gdm --version → GDM 50.0 ✅
  • nautilus: tarball hash verified (50.0), --version hangs on Tracker3 D-Bus (expected outside session)
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module update: when the change is significant.
    • Added release note for X11 session removal in nixos/doc/manual/release-notes/rl-2605.section.md
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[bobby285271]

🫠 I would say gnome-session & gdm update will (still) be non-trivial this cycle, I made at least bobby285271@d0c7294 bobby285271@39c0272 bobby285271@dcc3691 bobby285271@21747bb bobby285271@5b17c92 bobby285271@b6bc9d3 when I tried updating gdm to 50.beta and still nixosTests.gnome stuck.

I think @jtojnar will start the 50 PR when they finish their traveling.

[nekowinston]

I bumped a few more packages and got nixosTests.gnome to complete (on aarch64-linux) on my branch https://github.com/nekowinston/nixpkgs/tree/gnome-50-bump if that's any help. I couldn't get past the testGtk4Warnings.sh test in gjs, don't really know how to fix it atm.

[bobby285271]

Hi, since the size of this PR will go much larger at the end, it will be nice to use one commit per package update (usually we use fixup! commits if you don't want to force push often). So we won't got lost tracking which updates are reviewed.

And sorry for being rude, do you mind disclosing whether and how LLMs are used in this PR? 🙇 I was very sorry to ask this but the workflow here do look like LLMs.

[vitorpavani]

Hi @bobby285271 — thanks for the feedback, and sorry for the late reply.

On LLM usage: Yes, Claude was used as an AI assistant throughout this PR — for researching build requirements (minimum version constraints, upstream changelogs), diagnosing patch failures, and drafting commit messages. All changes were reviewed, tested locally, and verified by me. I think it's only fair to be transparent about this.

On commit structure: Understood — we'll restructure the branch to use one commit per package update. The current history has some squashed commits that bundle multiple packages together. We'll split those before requesting a proper review.

A few notes on the current state:

• We saw @nekowinston's branch got nixosTests.gnome passing on aarch64-linux — we'd like to align with that work and pick up anything we're missing
• The branch is ~3200 commits behind staging and will need a rebase
• We're actively testing GNOME 50 in a local VM to validate the changes before pushing further

[bobby285271]

Thanks for the clarification. I guess I would treat this as an ACK for me to rewrite existing commits when needed in this case. (I will do a force push in next 0-2 hours done, though not ensuring every existing fixups are kept yet and not ensuring stuff builds yet).

Before force push: 8d1fdae

[nekowinston]

As for my work on my branch, I didn't use any LLMs, and sorry about the one massive wip commit on Sunday, I just wanted to make the most of the weather rather than writing lots of commit messages 😅
I'd be happy to break them out into smaller commits today if that's any help!

[erialsan]

👍️👍️👍️👍️👍️

[vcunat]

I expect it will be best to merge already, given the timeline for NixOS 26.05.

[theCapypara]

This makes no sense to merge in this state, GDM is still broken.
Unless that is fixed, this can't go into the next release.
I am also not sure if anything else is really tested, given that getting past gdm was a blocker before?

[dtomvan]

We can fix GDM later in non-staging I suppose. Maybe even backport a fix, who knows. But we kinda can't keep hydra waiting to build the 99% that is working.

[szlend]

If I understand this correctly, the proposed fix for GDM is just a NixOS config change: vitorpavani@d508f37

So no rebuild necessary, if true.

[enzuru]

I have ported my PR to fix GDM permissions to staging: #517777

[vcunat]

I could've spent some work on splitting the mass-rebuild parts from this PR and merging only those so far, but I was optimistic. We have two weeks before this reaches master. In the worst case we can do the splitting later and revert whatever is necessary to keep GNOME working, even if whole would go back to 49.

[vcunat]

Before the merge I at least went through changes to packages that looked like large rebuilds (i.e. affecting a lot more than gnome*) and those did look good.

[theCapypara]

With GNOME 48 and before we had a separate gnome staging branch. Would that maybe make sense again for next time?