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

Jump to bottom

glib.setupHook: fix gsettings-schemas location #54130

Merged
merged 1 commit into from Jan 17, 2019
Merged

glib.setupHook: fix gsettings-schemas location #54130

merged 1 commit into from Jan 17, 2019

Conversation

jtojnar
Copy link
Contributor

@jtojnar jtojnar commented Jan 16, 2019 •
edited

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

@jtojnar
glib.setupHook: fix gsettings-schemas location
388faed 
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 mentioned this pull request Jan 17, 2019
Merged
6 tasks
@jtojnar jtojnar added this to In Progress in GNOME Jan 17, 2019
@jtojnar jtojnar changed the base branch from master to staging January 17, 2019 06:04
@jtojnar jtojnar merged commit 31ff786 into NixOS:staging Jan 17, 2019
GNOME automation moved this from In Progress to Done 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
Contributor 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
Contributor 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
Contributor 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 😄

@jtojnar jtojnar mentioned this pull request Jan 20, 2019
Closed
@johnramsden johnramsden mentioned this pull request Feb 12, 2020
Closed
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@worldofpeace worldofpeace worldofpeace approved these changes

Assignees
No one assigned
Labels
10.rebuild-darwin: 501+ 10.rebuild-linux: 501+
Projects
GNOME
  
Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@jtojnar @worldofpeace @GrahamcOfBorg