cantarell-fonts build broken (GNOME 3 dependency)

[wizeman]

Issue description

On the release-18.09 branch, the cantarell-fonts package fails to build with the following errors:

building
build flags: -j4 -l4
[1/1] Generating org.gnome.cantarell.metainfo.xml_merge with a custom command.
FAILED: appstream/org.gnome.cantarell.metainfo.xml
/nix/store/hy65mn4wjswqih75gfr6g4q3xgqdm325-python3-3.6.6/bin/python3.6m /nix/store/0wrv6cips8sfzk04ca67w6vlsgy4lb3z-meson-0.46.1/bin/meson --internal msgfmthelper ../appstream/org.gnome.cantarell.metainfo.xml.in appstream/org.gnome.cantarell.metainfo.xml xml ../appstream/./
msgfmt: cannot locate ITS rules for ../appstream/org.gnome.cantarell.metainfo.xml.in
ninja: build stopped: subcommand failed.
builder for '/nix/store/52vznnzqs7iz60w7a2wln0xg13w5nkhg-cantarell-fonts-0.100.drv' failed with exit code 1
error: build of '/nix/store/52vznnzqs7iz60w7a2wln0xg13w5nkhg-cantarell-fonts-0.100.drv' failed

Steps to reproduce

Change the hash in pkgs/data/fonts/cantarell-fonts/default.nix and then:
nix-build '<nixpkgs>' -A cantarell-fonts

Technical details

Hydra has a successful build of the cantarell-fonts package cached as of September 3rd (due to cantarell-fonts being a fixed-output derivation), but if you force it to build locally it will fail.

As far as I can tell, the build fails because the GETTEXTDATADIRS environment variable is not defined. Instead, there is a GETTEXTDATADIRS_FOR_BUILD variable defined (but it's not being used?).

If I add the following line to the cantarell-fonts/default.nix file it will build successfuly:

  preBuild = ''export GETTEXTDATADIRS="$GETTEXTDATADIRS_FOR_BUILD"'';

However, I'm pretty sure that this isn't the correct solution.

This seems related to #33524, #33458 and #40139.

cc @Ericson2314

[hedning]

I'm guessing role_post actually shouldn't be used here as gettext doesn't have a concept of GETTEXTDATADIRS_FOR_BUILD, as opposed to eg. CC_FOR_BUILD which is used for cross compilation:

nixpkgs/pkgs/development/libraries/gettext/gettext-setup-hook.sh

Line 5 in 03dc647

addToSearchPath "GETTEXTDATADIRS${role_post}" "$1/share/gettext"

Just like it's not used in gobject-introspection's setup-hook as there's no concept of GI_TYPELIB_PATH_FOR_BUILD:

nixpkgs/pkgs/development/libraries/gobject-introspection/setup-hook.sh

Line 4 in 03dc647

addToSearchPath GI_TYPELIB_PATH $1/lib/girepository-1.0

Not sure why we're hitting this only with cantarell though.

[jtojnar]

Most packages that need its rules probably pick it up from XDG_DATA_DIRS where the share directory is added by gobjectIntrospection setup hook. nautilus-sendto and cantarell-fonts do not use that setup hook.

[jtojnar]

Weird, nautilus-sendto has somehow the variable set:

unpacking sources
unpacking source archive /nix/store/4aj92q4ai50y1alfk8iwjjln0j8haf17-nautilus-sendto-3.8.6.tar.xz
source root is nautilus-sendto-3.8.6
setting SOURCE_DATE_EPOCH to timestamp 1502278258 of file nautilus-sendto-3.8.6/src/nautilus-sendto.metainfo.xml.in
patching sources
configuring
preConfigure=env | grep GETTEXTDATADIRS
GETTEXTDATADIRS=/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/y1g563q2gsk1s9ivn4svc9wfyhn0p8y1-gtk+3-3.24.1/share/gettext:/nix/store/3sy9kxsywhld7qdliwmqwbxaaa38364h-appstream-glib-0.7.14/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/y1g563q2gsk1s9ivn4svc9wfyhn0p8y1-gtk+3-3.24.1/share/gettext:/nix/store/3sy9kxsywhld7qdliwmqwbxaaa38364h-appstream-glib-0.7.14/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext
GETTEXTDATADIRS_FOR_BUILD=/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/y1g563q2gsk1s9ivn4svc9wfyhn0p8y1-gtk+3-3.24.1/share/gettext:/nix/store/3sy9kxsywhld7qdliwmqwbxaaa38364h-appstream-glib-0.7.14/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/y1g563q2gsk1s9ivn4svc9wfyhn0p8y1-gtk+3-3.24.1/share/gettext:/nix/store/3sy9kxsywhld7qdliwmqwbxaaa38364h-appstream-glib-0.7.14/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext:/nix/store/y1g563q2gsk1s9ivn4svc9wfyhn0p8y1-gtk+3-3.24.1/share/gettext:/nix/store/3sy9kxsywhld7qdliwmqwbxaaa38364h-appstream-glib-0.7.14/share/gettext:/nix/store/m7qkvrfxjfz68nqc4bywjg2nkazlml2b-gettext-0.19.8.1/share/gettext:/nix/store/b6l82p13kmn3bjcx1kan4l1vn3bd271w-glib-2.58.1/share/gettext

[hedning]

Ok, looks like the plain variant is only added if buildInputs is defined (adding eg. glib to buildInputs fixes the build).

[hedning]

Hmm, so gobject-introspection's envHook might actually cause problems for cross compilation, at least when combined with wrapGAppsHook, as stuff in nativeBuildInput could end up in the wrappers.

While gettext should probably be safe, as that's all done at compile time?

[jtojnar]

I think it should not matter for cross-compilation, as /share typically contains architecture-independent data. There might be some problem with over-detecting dependencies #32293
We might fix it with #32790

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[philiptaron]

This is definitely fixed.