Gnome and Pantheon: install nixos wallpapers

[worldofpeace]

Motivation for this change

Fix #86146.
We were hardcoding them into settings but not installing them.

This also changes nixos-artwork slightly 581122f. Namely, install to share/backgrounds, and provide an absolute path to the file.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[jtojnar]

Do not see artwork used within path when searching g-c-c. Googling "/usr/share/artwork/gnome" shows no results, without gnome only few mentions but none of them look official. We might want to keep this for backwards compatibility, though.

[worldofpeace]

I don't really understand the failing check here.

[worldofpeace]

@ofborg eval

(I have no idea)

[jtojnar]

Would using builtins.toString on the path remove the context and fix the error?

[worldofpeace]

Would using builtins.toString on the path remove the context and fix the error?

Nope, I tried that at first and still got

error: in 'toFile': the file 'options.xml' cannot refer to derivation outputs, at /home/worldofpeace/Code/nix/nixpkgs/nixos/lib/make-options-doc/default.nix:89:16

when building the manual.

[jtojnar]

Using the following patch,

--- a/nixos/modules/services/x11/display-managers/lightdm.nix
+++ b/nixos/modules/services/x11/display-managers/lightdm.nix
@@ -133,7 +133,7 @@ in
 
       background = mkOption {
         type = types.path;
-        default = pkgs.nixos-artwork.wallpapers.simple-dark-gray-bottom.gnomeFilePath;
+        default = let pkg = pkgs.nixos-artwork.wallpapers.simple-dark-gray-bottom; pp = "${pkg}/share/backgrounds/nixos/${pkg.src.name}"; in builtins.trace (builtins.getContext pkg.gnomeFilePath) (builtins.trace (builtins.getContext pp) pp);
         description = ''
           The background image or color to use.
         '';

it looks like the issue is actually the opposite than I thought:

trace: { "/nix/store/qry13wjmx6wbj4rcb6qz2yis4m3bhin5-simple-dark-gray-2018-08-28.drv" = { outputs = [ "out" ]; }; }
trace: { }

Even though the both strings are the same, passthru strips the context, so toFile sees a path that was not mentioned in any context and complains.

Edit: Nope. Reading it wrong again.

[jtojnar]

This patch seems to work:

--- a/nixos/modules/services/x11/display-managers/lightdm.nix
+++ b/nixos/modules/services/x11/display-managers/lightdm.nix
@@ -133,9 +133,7 @@ in
 
       background = mkOption {
         type = types.path;
-        # TODO: use gnomeFilePath when fixing string context issues in make-option-doc
-        # https://github.com/NixOS/nixpkgs/issues/83863
-        default = "${pkgs.nixos-artwork.wallpapers.simple-dark-gray-bottom}/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png";
+        default = pkgs.nixos-artwork.wallpapers.simple-dark-gray-bottom.gnomeFilePath;
         description = ''
           The background image or color to use.
         '';
--- a/pkgs/data/misc/nixos-artwork/wallpapers.nix
+++ b/pkgs/data/misc/nixos-artwork/wallpapers.nix
@@ -29,7 +29,7 @@ _EOF
       '';
 
       passthru = {
-        gnomeFilePath = "${pkg}/share/backgrounds/nixos/${src.name}";
+        gnomeFilePath = builtins.unsafeDiscardStringContext "${pkg}/share/backgrounds/nixos/${src.name}";
         kdeFilePath = "/share/wallpapers/${name}/contents/images/${src.name}";
       };
 

Obviously, not a good idea. Not only it is unsafe but it would also break dependence tracking when used in derivations.

I am not sure why does not builtins.toFile support referencing the result of derivation, ¿perhaps it happens in evaluation time so it would cause IFD?

What is even weirder, when we construct the string in place as before, it shows no context:

trace: { }

but if we do the same in repl, we get a context:

nix-repl> let pkg = pkgs.nixos-artwork.wallpapers.simple-dark-gray-bottom; pp = "${pkg}/share/backgrounds/nixos/${pkg.src.name}"; in builtins.trace (builtins.getContext pp) pp
trace: { "/nix/store/qry13wjmx6wbj4rcb6qz2yis4m3bhin5-simple-dark-gray-2018-08-28.drv" = { outputs = [ "out" ]; }; }
"/nix/store/pzgmk5wx85drxbw1ikyg50gc1whi36ag-simple-dark-gray-2018-08-28/share/backgrounds/nixos/nix-wallpaper-simple-dark-gray_bottom.png"

[jtojnar]

It makes sense for the manual not to depend on other attributes but at the same time user’s configuration should. Not sure if this is solvable.

[jtojnar]

Hmm, mkOption actually supports defaultText so we can have something like a cake and eat it too. The downside is that it is rendered like a string, not a literal:

[worldofpeace]

@jtojnar Yay ✨. That seems fine to me. Re the investigation #86163 (comment), perhaps @edolstra can shed some light.