bug: checking sway config file fails even when config is valid

[genevieve-me]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

https://github.com/nix-community/home-manager/commit/3a435342e2e5e2bff1d3331c2bd9e70f25693ea2 completely breaks a nix build if the sway config file refers to a file in a user's directory (eg a background image). To be specific, the line causing home-manager to fail is output."*".background = "${config.xdg.userDirs.pictures}/wallpaper.png fill";.

00:00:00.156 [sway/commands/output/background.c:122] Unable to access background file '/home/genevieve/pics/wallpaper.png': No such file or directory
00:00:00.156 [sway/config.c:872] Error on line 96 'background /home/genevieve/pics/wallpaper.png fill': unable to access background file '/home/genevieve/pics/wallpaper.png' (/nix/store/4gcrn3gb57h5xw6ckkqhfkknqv5z491w-sway.conf)
00:00:00.156 [sway/config.c:435] Error(s) loading config!

Maintainer CC

@amarshall

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.8.5, NixOS, 24.05 (Uakari), 24.05.20240412.cfd6b5f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/yy5l09gfsagkv8rswblknmsjc2gyr20d-source`

[Janik-Haag]

+1 on this, I'm getting the same error when using a custom xkb_map input method with sway. edit: a quick workaround is to just set wayland.windowManager.sway.checkConfig = false;

[rycee]

Must be related to https://github.com/nix-community/home-manager/pull/4644. Perhaps @amarshall has an idea how to avoid this issue? Ideally the checker should not attempt to check external files, there is no guarantee they'll exist at configuration build time.

[sysedwinistrator]

+1 on this, I'm getting the same error when using a custom xkb_map input method with sway. edit: a quick workaround is to just set wayland.windowManager.sway.checkConfig = false;

I have a similar error, I'm referencing a custom xkb_layout that I have defined in my NixOS system configuration under services.xserver.extraLayouts (the option apparently has been renamed to services.xkb.extraLayouts).
While it would be possible to reproduce what the NixOS module does; namely, building a package with the custom layouts using pkgs.xorg.xkeyboardconfig_custom; and then then setting XKB_CONFIG_ROOT to "${xkb_custom}/etc/X11/xkb" in the checkPhase; I don't see a way to override the configFile derivation without running into an infinite recusionn.

TL;DR It would be nice if it were possible to override the configFile derivation to be able to customize the checkPhase.

[leonm1]

While I think I could solve this by committing my wallpaper to my nixos flake git repo, I would not like to start putting image files in my git repo, since that would begin to bloat the size considerably.

I imagine just about every person using Sway has a wallpaper set, should we disable by default or revert this check until we have a solution?

[amarshall]

As mentioned, the workaround to a failing check is programs.sway.checkConfig = false;.

Here’s a PR to add preCheckConfig to customize the check environment.

[LunNova]

Sway config check also fails when running on nvidia proprietary drivers at time of build, somehow that detail is sneaking into the build sandbox.

[amarshall]

@LunNova What’s the error? This is surprising since we pass --unsupported-gpu when validating.

[LunNova]

Oh my bad, it's printing a warning about proprietary nvidia drivers but the actual error was failing to load my wallpaper from my home directory.

[thiagokokada]

In my case, after fixing an issue where my config was looking at . "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh" (that is similar to what other people are seeing, looking at a file that is only available after activation) instead of . "${config.home.sessionVariablesPackage}/etc/profile.d/hm-session-vars.sh", I got another issue:

00:00:00.003 [wlr] [render/wlr_renderer.c:343] Cannot create Vulkan renderer: no DRM FD available
00:00:00.003 [wlr] [render/wlr_renderer.c:423] Could not initialize renderer
00:00:00.003 [sway/server.c:143] Failed to create renderer

I am assuming this is because I am using Home-Manager module for NixOS instead standalone, and this makes the build run in a systemd service instead of as the current user.

But yes, the current checks seems to be kinda too restrictive to be useful.

[amarshall]

I am assuming this is because I am using Home-Manager module for NixOS instead standalone, and this makes the build run in a systemd service instead of as the current user.

I’m not sure what you mean here—are you running single-user Nix rather than multi-user? Multi-user Nix builds should be running as a build user, never as current user.

[thiagokokada]

I’m not sure what you mean here—are you running single-user Nix rather than multi-user? Multi-user Nix builds should be running as a build user, never as current user.

No, if you use Home-Manager as a NixOS module instead of Home-Manager standalone, the activation phase of Home-Manager run as a systemd service instead as a script from the user perspective.

But ok, if this is run at the build time instead of activation time this makes my comment irrelevant. It is still something that is happening though, for some reason the config failed while my config itself works fine for me.

[thiagokokada]

Maybe the issue is because I am using setting export WLR_RENDERER=vulkan to use the vulkan renderer?

[amarshall]

Yes this check is run as part of build, not activation.

That does seem to be it, as adding that to the HM test makes it fail with the same error. With the above PR it should be possible to manipulate the check to unset just that env var while still checking everything else. How are you setting WLR_RENDERER?

[teto]

While I think I could solve this by committing my wallpaper to my nixos flake git repo, I would not like to start putting image files in my git repo, since that would begin to bloat the size considerably.

My screenshot was already committed to the repo but the path was not accessible in the sandbox so I fixed that. I think the tests works as intended, if you want a reproducible HM experience. I find the check helpful as it helped me find an issue with my config, the suggested workarounds look a bit complex to support this nice-to-have-but-not critical feature so I would vote for disabling the check by default since it triggers several complaints.

[thiagokokada]

Yes this check is run as part of build, not activation.

That does seem to be it, as adding that to the HM test makes it fail with the same error. With the above PR it should be possible to manipulate the check to unset just that env var while still checking everything else. How are you setting WLR_RENDERER?

https://github.com/thiagokokada/nix-configs/blob/c069dafd0657efb97e8e0ad7c38fe432c33f012b/home-manager/desktop/sway/default.nix#L105-L106

[thiagokokada]

Yes this check is run as part of build, not activation.

That does seem to be it, as adding that to the HM test makes it fail with the same error. With the above PR it should be possible to manipulate the check to unset just that env var while still checking everything else. How are you setting WLR_RENDERER?

Not sure if the PR above would solve the issue because extraSessionCommands are embedded in the binary itself.

Maybe if this test added some environment variable that allowed us to check if it is in test mode, but not sure if the complexity is worth it.

[thiagokokada]

Ok, fixed the issue by setting WLR_RENDERER=vulkan,gles2,pixman. This allows the wlroots to fallback to other renderers if vulkan is not available.

[TilCreator]

My (dirty) fix is to set the background (or other breaking config settings) in a sway startup command (this has the problem that errors with that config setting will not be reported by swaynag)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/services-xserver-xkb-extralayouts-doesnt-seem-to-be-compatible-with-sway/46128/7