Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glib.setupHook: fix gsettings-schemas location #54130

Merged
merged 1 commit into from
Jan 17, 2019

Conversation

jtojnar
Copy link
Member

@jtojnar jtojnar commented Jan 16, 2019

Motivation for this change

GLib setup hook expects GSettings schemas to be installed in ${!outputLib} and tries to move them to gsettings-schemas/$name subdirectory to prevent conflicts. But the schemas will only end up in the library output when the build system recognizes makeFlags set by the setup hook, and in that case the move is not necessary, since the flag already includes the subdirectory.

Normally, this is not an issue, since most packages relying on GSettings schemas either still use Autotools with gsettings.m4, or do not have a lib output set. But with the promulgation of multiple outputs in Nixpkgs and more and more projects switching to Meson, the issue will become increasingly common.

We first noticed this problem with nm-applet.

Closes #45043

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested building nm-applet and checked that the file is moved correctly and that path in the wrapper points to the correct output.
  • Fits CONTRIBUTING.md.

cc @worldofpeace @hedning

GLib setup hook expects GSettings schemas to be installed in ${!outputLib}
and tries to move them to gsettings-schemas/$name subdirectory to prevent
conflicts. But the schemas will only end up in the library output when
the build system recognizes makeFlags set by the setup hook, and in that case
the move is not necessary, since the flag already includes the subdirectory.

Normally, this is not an issue, since most packages relying on GSettings
schemas either still use Autotools with gsettings.m4, or do not have a lib
output set. But with the promulgation of multiple outputs in Nixpkgs and
more and more projects switching to Meson, the issue will become increasingly
common.

We first noticed this problem with nm-applet.

Closes NixOS#45043
@jtojnar jtojnar merged commit 31ff786 into NixOS:staging Jan 17, 2019
@jtojnar jtojnar deleted the glib-gsettings-prefix branch January 17, 2019 10:04
@worldofpeace
Copy link
Contributor

Just tested building networkmanagerapplet on staging and there's an issue.

We depend on libappindicator-gtk3 which needs pygtk and it's broken with

checking whether to enable threading in pygtk... yes
checking for pkg-config... no
checking for GLIB - version >= 2.8.0... no
*** A new enough version of pkg-config was not found.
*** See http://www.freedesktop.org/software/pkgconfig/
configure: error: gobject is required to build pygtk?

I recall there was some patches to remove python from here.

@jtojnar
Copy link
Member Author

jtojnar commented Jan 18, 2019

comm -12 <(git grep -l pygtk | sort) <(git grep -l appindicator | sort) indicates we do not really use pygtk with libappindicator. Also since pygtk uses GTK2, it does not make much sense to include it for GTK3 version of libappindicator. I would just drop thy python bindings.

@worldofpeace
Copy link
Contributor

Yeah, the python bindings should be in a different package too.

Do we even need them in nixpkgs?

@jtojnar
Copy link
Member Author

jtojnar commented Jan 18, 2019

xflux-gui is probably the only thing that uses it. Maybe the arch patch would help. Though, they did not remove python from configure.ac for some reason.

Or maybe we could switch to https://github.com/AyatanaIndicators/libayatana-appindicator like Debian is doing.

@jtojnar
Copy link
Member Author

jtojnar commented Jan 18, 2019

I fixed the build for now in 9e9dc22, it was probably forgotten in 5a3670b

@worldofpeace
Copy link
Contributor

I actually had some of the libayatana stuff packaged laying around in a stash.
Not sure if we should switch to using libayatana-appindicator but this sure does look like a mess 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants