search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.02k stars 14.03k forks source link

gnome3 improvements #247

Closed viric closed 6 years ago

viric commented 11 years ago

Quick guide on gnome3 https://wiki.gnome.org/SysAdminGuide

List of issues to be fixed:

Some journalctl warnings to cleanup:

Missing core packages left to be packaged:

List of apps to be packaged:

vcunat commented 11 years ago

There were certainly some attempts. And there's a branch: https://github.com/NixOS/nixpkgs/tree/gnome-3 (I haven't tried any of these, just remembered there was a branch.)

vcunat commented 11 years ago

A few more gnome3 pieces are now in https://github.com/vcunat/nixpkgs/tree/vlada/gtk3 .

Most notably it seems that evince-3.6* works. I'm not yet sure what to do with the work. Maybe it won't break anything and can go to master, but x-updates might be more suitable.

viric commented 11 years ago

On Tue, Jan 29, 2013 at 08:45:53AM -0800, Vladimír Čunát wrote:

A few more gnome3 pieces are now in https://github.com/vcunat/nixpkgs/tree/vlada/gtk3 .

Most notably it seems that evince-3.6* works. I'm not yet sure what to do with the work. Maybe it won't break anything and can go to master, but x-updates might be more suitable.

I was waiting for someone to bring gnome3 pieces. That could allow building the GUI for gnunet.

I'll take a look at your branch. Thank you!

vcunat commented 11 years ago

@viric: I can only see the gtk-3 dependency http://packages.ubuntu.com/quantal/gnunet-gtk

... which was already there, in some older version.

viric commented 11 years ago

On Mon, Feb 04, 2013 at 04:31:50PM -0800, Vladimír Čunát wrote:

@viric: I can only see the gtk-3 dependency http://packages.ubuntu.com/quantal/gnunet-gtk

... which was already there, in some older version.

I already tried to package it, and got stuck at some gnome 3 requirement (no gtk3, of course). I can't remember now. I'll look at it in a few days.

domenkozar commented 11 years ago

@bjornfor and me are interested, anyone else?

domenkozar commented 10 years ago

I have started to package gnome3 3.10 packages, see http://hydra.nixos.org/eval/1052217

There are two issues currently:

vcunat commented 10 years ago

@iElectric:

domenkozar commented 10 years ago

I see that two packages are 3.11: I'll downgrade.

For schemas: we'll need a setup hook to pass that around. It's still pure and less error prone.

vcunat commented 10 years ago

@iElectric: you mean auto-wrapping all executables with run-time dependency on all build-time packages providing schemas?

domenkozar commented 10 years ago

@vcunat for schemas you don't need that. I'd do a setup hook that:

For icons/themes we might need to do run-time dependency on build-time packages that claim to provide icons or themes.

I'm happy to hear a better solution though :)

Phreedom commented 10 years ago

On Friday, January 10, 2014 06:21:25 AM Domen Kožar wrote:

@vcunat for schemas you don't need that. I'd do a setup hook that:

  • adds a fixup phase that copies schema from $out/share/glib-2.0/schemas/gschemas.compiled to $out/share/glib2.0/schemas/${name}/gschemas.compiled and wrapps all executables with the env var to point there.

For icons/themes we might need to do run-time dependency on build-time packages that claim to provide icons or themes.

I'm happy to hear a better solution though :)

KDE :P

How about wrapping this in nixos instead of nixpkgs? or patching the lib responsible for schemas to also look into some env var for hints?

domenkozar commented 10 years ago

There is a var that you can tell it where to look, but you need to move the schemas so they don't conflict in profile environment

domenkozar commented 10 years ago

Also, useful resource how to configure gtk at run-time: https://developer.gnome.org/gtk3/3.0/gtk-running.html

domenkozar commented 10 years ago

@vcunat downgraded 3.11 packages to 3.10, thanks for notice.

vcunat commented 10 years ago

Well, at least in cinnamon we needed to add schemas also from different packages. I don't know how it's about GNOME3...

vcunat commented 10 years ago

@Phreedom: wrapping in nixos isn't enough IMO, as many packages make much sense to run even without the GNOME3 desktop (like eye of gnome, evince).

domenkozar commented 10 years ago

For the record, jhbuild dependency files are helpful when packaging gnome3 stuff http://ftp.gnome.org/pub/GNOME/teams/releng/3.10.2/gnome-suites-core-3.10.2.modules

domenkozar commented 10 years ago

I've packaged most of the remaining gnome3 core software, last bit missing is gnome-shell.

gnome-shell fails to compile GIR files (gobject introspection). Gnome developers are saying we are linking against different gtk3 version that headers are included from.

Error:

building Shell-0.1.gir
  GISCAN   Shell-0.1.gir

(lt-gnome-shell:5650): GLib-GObject-WARNING **: specified instance size for type 'ShellEmbeddedWindow' is smaller than the parent type's 'GtkWindow' instance size

(lt-gnome-shell:5650): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
Invalid GType function: 'shell_embedded_window_get_type'

** (lt-gnome-shell:5650): ERROR **: Failed to extract GType data: Function 'shell_embedded_window_get_type' returned G_TYPE_INVALID
Command '['./gnome-shell', '--introspect-dump=/tmp/nix-build-gnome-shell-3.10.2.1.drv-1/tmp-introspectaPbggB/functions.txt,/tmp/nix-build-gnome-shell-3.10.2.1.drv-1/tmp-introspectaPbggB/dump.xml']' returned non-zero exit status -5

To test it out, checkout gnome3/gnome-shell branch and run nix-build -A gnome3.gnome_shell

domenkozar commented 10 years ago

Fixed in a7d0a53d9ed7f74a206dcda2c36d433e030f6822.

Above commit also removed a bunch of run-time dependency problems for gnome-shell. Following errors/warnings are left to be addressed before we see a working gnome-shell+mutter in action: http://bpaste.net/show/172250/

vcunat commented 10 years ago

This looks rather like some problem in virtualbox OpenGL setup... libGL error: failed to load driver: vboxvideo

domenkozar commented 10 years ago

Among other things, indeed :)

domenkozar commented 10 years ago

Just pushed very basic gnome3 support. Try it out:

      desktopManager.default = "gnome3";
      desktopManager.gnome3.enable = true;
bjornfor commented 10 years ago

@iElectric: Cool! I will try!

domenkozar commented 10 years ago

Next major milestone to fix is #1700

domenkozar commented 10 years ago

@bjornfor channels should have all the updates for gnome3.

PkmX commented 10 years ago

Do we have any resolutions on how to handle loading GTK+ modules at run-time? I'm currently dealing with IM modules, which will be installed by IM packages to their $out/lib/gtk-3.0/3.0.0/immodules/. GTK+ applications also need the environment variable GTK_IM_MODULE_FILE point to a cache file generated by gtk-query-immodules-3.0 to find them. My current proposal is:

Any thoughts?

domenkozar commented 10 years ago

@PkmX I believe noone bothered with that yet. Seems to be similar to gschemas.compiled thing.

If I understand correctly apps need GTK_IM_MODULE_FILE at runtime set with a path to a cached file of all immodules? If so, we should probably have an activation script for nixos when gtk is installed that would collect files. I think @vcunat said he has on TODO to do something similar for themes/icons

vcunat commented 10 years ago

Yes, this issue seems to be pushing up through my TODO fast this month, after being there for a year at least :-) I think nixos isn't enough, as we want user envs as well. Various re-generating could be plugged into my planned scheme, but beware of using these system/profile-wide paths -- e.g. because of gstreamer and gio modules on them I have crashes (not matching versions and bad/no check on loading them).

Also, if we find a good way of auto-detecting similar run-time dependencies, it would be nice to have some advanced analogy of autoreconfHook, which would auto-wrap the affected executables some time around fixupPhase.

lucabrunox commented 10 years ago

gnome-system-log and gnome-screenshot packaged

lucabrunox commented 10 years ago

About "Control center is not opened when clicking the icon on settings", I'm able to open it when clicking on the Settings icon from the activity, and also from the icon in the logout menu on the top right.

lucabrunox commented 10 years ago

gupnp and gupnp-igd are already packaged in nixpkgs

domenkozar commented 10 years ago

Right, that's why I didn't add it at the first place.

lucabrunox commented 10 years ago
vcunat commented 10 years ago

I'm not sure where this is set, but I'm getting user+system-installed stuff in menus (perhaps xfce startup?).

echo $XDG_DATA_DIRS
$HOME/.nix-profile/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share
lucabrunox commented 10 years ago

Right @vcunat . Though icons are not found for some reason, and applications are not found when gnome-shell is running, a restart is needed. Overall it's ok for now.

vcunat commented 10 years ago

@lethalman: XDG spec for icons (and maybe others) requires to check the mtime of each top-level icon directory every five seconds as a way to detect of changes. Unfortunately, that's useless for us, as we use nix-store dirs, where the mtime values are always the same.

lucabrunox commented 10 years ago

@vcunat yes, however also after restarting I don't see icons of user-installed applications.

vcunat commented 10 years ago

Yes, I'm fairly sure that's because user-env doesn't regenerate the gtk icon cache (one from some random package gets typically in there instead). System env has a hard-coded hack to regenerate it.

jagajaga commented 10 years ago

With cheese there is a problem of including gudev. Tried smth like https://gist.github.com/11142008 (unfinal due to gudev trouble) but no result.

lucabrunox commented 10 years ago

@jagajaga $PKG_CONFIG is not set in the configure, and even setting it from the nix expr it's not picked up. The configure.ac or build-aux must be doing something weird with $PKG_CONFIG.

lucabrunox commented 10 years ago

Proposal for gdk-pixbuf loaders and im modules @PkmX . First note that GDK_PIXBUF_MODULE_FILE and GTK_IM_MODULE_FILE are not paths, but a single file. I prefer wrapping programs instead of doing nixos activation for two reasons:

  1. Whenever it's possible, I prefer doing it in functional local-state rather than imperative global-state.
  2. Apps can be used outside of nixos if they are correctly wrapped with sane defaults.

The current approach to GDK_PIXBUF_MODULE_FILE has the following drawbacks:

  1. The same file with the same contents gets created for each package that has gdk_pixbuf build input.
  2. Even if the package does not rely on GDK_PIXBUF_MODULE_FILE, the loaders.cache file gets created.

This approach also has some advantages:

  1. $GDK_PIXBUF_MODULE_FILE is exported at build time, and it may be used for generating images from svg (gnome themes standard for example).
  2. The loaders.cache is filled in based on the build inputs of the package being built. This is not much of a feature, after all we always use gdk_pixbuf and librsvg as loaders.

Proposal: gdk-pixbuf-loaders

{ stdenv, gdk_pixbuf, librsvg }:

stdenv.mkDerivation {
  name = "gdk-pixbuf-loaders";

  builder = builtins.toFile "builder.sh" ''
    cat "${gdk_pixbuf}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache" > $out
    cat "${librsvg}/lib/gdk-pixbuf/loaders.cache" >> $out
  '';
}

Then wrap with --set GDK_PIXBUF_MODULE_FILE "${gdk-pixbuf-loaders}". By default loaders will be gdk_pixbuf and librsvg. If we ever need more loaders etc., I don't think that's a problem, we can fix / conditionate the derivation.

Disadvantage: $GDK_PIXBUF_MODULE_FILE is not known at build time for some packages needing it (which should be a few packages I hope), unless:

  1. gdk-pixbuf-loaders has a setup-hook and it's used as build input, which makes sense if the package needs loaders at build time.
  2. the derivation itself exports the needed variable.

Whether to choose between 1 or 2 depends on how many packages rely upon the $GDK_PIXBUF_MODULE_FILE variable being available at build time.

This applies to gtk im modules as well.

lucabrunox commented 10 years ago

@jagajaga the problem is that cheese requires pkg-config 0.24, while nixpkgs has 0.23.

jagajaga commented 10 years ago

@lethalman why don't we update it? :)

lucabrunox commented 10 years ago

@jagajaga pkgconfig is basically used by all packages of nixpkgs, do you want the responsibility to break everything? :P I'd start with a pkgconfig_24 = ..../0.24.nix; first, and see that it works. There's no hurry in updating it for all the packages.

vcunat commented 10 years ago

@jagajaga: It's not so easy. We probably want a patch that hasn't been ported to newer versions AFAIK (I tried to search months ago, but I haven't found a port). See #292 discussion.

lucabrunox commented 10 years ago

@jagajaga now pkgconfig 0.28 is packaged, cheese can be packaged

jagajaga commented 10 years ago

@lethalman thx. Gonna do it.

lucabrunox commented 10 years ago

@edolstra @vcunat I'd apprecciate your comment about https://github.com/NixOS/nixpkgs/issues/247#issuecomment-41255168 :)

vcunat commented 10 years ago

pixbuf loaders, state: (correct me if I'm wrong, please) It is another instance of the "plugin problem" we often encounter. However, this one is special, as typically apps only need the loaders distributed with the library itself (and no variable setting is needed to find them as long as we have GDK_PIXBUF_LIBDIR/gdk-pixbuf-2.0/2.10.0/loaders.cache on its place). The only other common loader I found is from librsvg which is used very much in gnome3 stuff. (I tried also searching for other loaders in Ubuntu http://packages.ubuntu.com/search?suite=trusty&arch=any&mode=filename&searchon=contents&keywords=libpixbufloader .)

When it's this simple, I think the best trigger is just having librsvg in build inputs. That could e.g. define that GDK_PIXBUF_MODULE_FILE variable via an env hook, so it's available both at build- and run-time. (No changes needed in expressions using this variable.) As you say, that extra loaders.cache in each build seems superfluous. We can have just one file, probably in librsvg output directly. We could again generalize that later if need be, but ATM splitting the loaders.cache generation would complicate its export via env hooks.

As for IM modules, I haven't really encountered those yet. I guess it will be different -- more like the usual "plugin problem" -- with a larger range of choice, different people (not packages) wanting different plugins...