Change:
machine.wait_until_succeeds(f"pgrep -f {i}") for i in ["gala", "io.elementary.wingpanel", "plank"]: machine.wait_for_window(i) <del> machine.wait_for_unit("bamfdaemon.service", "${user.name}") machine.wait_for_unit("io.elementary.files.xdg-desktop-portal.service", "${user.name}") </del> <ins> for i in ["io.elementary.gala.daemon@x11.service", "bamfdaemon.service", "io.elementary.files.xdg-desktop-portal.service"]: machine.wait_for_unit(i, "${user.name}") </ins> with subtest("Check if various environment variables are set"): <del> cmd = "xargs --null --max-args=1 echo < /proc/$(pgrep -xf /run/current-system/sw/bin/gala)/environ" </del> <ins> cmd = "xargs --null --max-args=1 echo < /proc/$(pgrep -xf ${pkgs.pantheon.gala}/bin/gala)/environ" </ins> machine.succeed(f"{cmd} | grep 'XDG_CURRENT_DESKTOP' | grep 'Pantheon'") # Hopefully from the sessionPath option. machine.succeed(f"{cmd} | grep 'XDG_DATA_DIRS' | grep 'gsettings-schemas/pantheon-agent-geoclue2'")

Discussion:
So, if I understand it correctly, under Wayland the user session is supposed to be managed by a user instance of systemd. In particular, I think(?), this means that all kinds of session daemons are converted to systemd units and started by instead of . I think, it is a good idea to switch to this kind of session management for X as well for forward compatibility (and for the cool features that systemd may provide for this use-case, although I am not sure if there are any). According to , GNOME 3.34 actually does it this way. So, here is the question: I don’t see this on my system, even though Pantheon relies heavily on GNOME, and I see pieces of GNOME 3.36 all around – why is that? Is this an artefact of GNOME packaging for NixOS (i.e. if I enable GNOME as a DE on NixOS, will it use systemd?) or is this due to how Elementary reuses GNOME in such an old way and thus an upstream bug? Or is this an artefact of specifically how Pantheon is packaged for NixOS? (cc
Aha elementary/session-settings/issues/17.
No necessarily. The wayland session of GNOME used to be without user services, an it could be for Pantheon as well if there's reason to still distribute it even if not default in the future. Currently both the settings-daemon and mutter are forks with patches at 3.34 to support Pantheon. Those two pieces of software need compatibility packages at pinned versions to support Pantheon properly, as they can't work as fast as GNOME breaks API every release, so we have to wait a bit for them to get the chance to catch up to port to newer libmutter versions. Though sometimes, if they break API, they don't have to make changes. But for the past several releases that for sure wasn't the case. I believe there's comments in nixpkgs where these packages are called with more terse explanation. Anyways, I'm currently Q.A'ing support for 3.36 and it seems to work good aside from a weird bug with firefox that I have to look into.
I marked this as stale due to inactivity.

&rarr;
I have some very very very newbie questions here, will be appreciate if you can offer some help (sorry I am not familiar with this field to be honest). I just tried applying the following PRs to Nixpkgs then remove the option (see ). Then I found that cannot start. To make things clearer, I the following patch to gala: I then reboot, login from LightDM, then all I see is a wallpaper and no other things. I find the following from the journal: As I can see but no so I guess isn't executed at all which leads to a timeout and process was then killed and things happened over and over again. Later I applied another patch: And this time gala doesn't compile at all, it failed with this (). Do you have any idea what is happening here? Did I miss something?
In your build log: Looks like you need to pull in the systemd development libraries as a build dependency. Probably should make that required if systemd support is enabled though so meson will fail with a missing dependency error.
Thanks for your reply! I just did some experiments on this. I am not sure, but I think we have libsystemd as build dependency. I think I figured out a solution to this: I guess to make the block work, we need to move above and also I changed to so pkg-config can discover this (I guess). Everything is working now (the desktop launches without ), thanks! I opened a upstream PR for this:
Thanks for the PR! If you're planning on shipping this, I would recommend very carefully testing everything. We've hardly done any testing of this ourselves and I don't think we plan to ship it for the elementary OS 6.0 series at all.
I marked this as stale due to inactivity. &rarr;