Re: [PATCH] glib-or-gtk-build-system: new build-system
On Sat, Oct 11, 2014 at 12:13 PM, Ludovic Courtès l...@gnu.org wrote: (Adding guix-devel, which I think was dropped by mistake.) Did these libcanberra issues appear after you switched Evince and Inkscape to ‘glib-or-gtk-build-system’? No, it was the same before. If anything, with glib-or-gtk-build-system, if I add libcanberra as an input to the packages, the warning disappears. Did you browse /etc for things related to GTK+ modules? Or maybe did you check your user account’s GSettings database (I believe there’s a graphical editor to do that)? Yes, I've looked in various places, including /etc and using the dconf-editor, but could not find anything useful. However, I do not really understand how gdm3 and gnome are started up and configured on Debian. So, I may have messed the right spot. Fede
Re: [PATCH] glib-or-gtk-build-system: new build-system
On Thu, Oct 9, 2014 at 11:10 PM, Ludovic Courtès l...@gnu.org wrote: Is the GTK_MODULES environment variable defined on your system? AIUI, that tells GTK+ what modules to dlopen. No, that variable is not defined on my system. Regards, Fede
Re: [PATCH] glib-or-gtk-build-system: new build-system
Federico Beffa be...@ieee.org skribis: l...@gnu.org (Ludovic Courtès) writes: Not sure. Is libcanberra dlopened? Do you know what dlopens it, and whether it systematically does? I've not found out. I'm attaching the strace log of evince (actually the wrapper of my local package built with glib-or-gtk). Maybe you see more than me. In any case, I've checked a couple more applications making use of the gtk toolkit: inkscape, icecat. They all complain about libcanberra-gtk-module. It looks like libcanberra is used by many gtk+ applications. I’ve looked again at the strace log and can’t find anything obvious such as a config file in /home or /etc that would tell it to load libcanberra-module. However, I built Evince locally with glib-or-gtk-build-system, and it doesn’t mention anything about libcanberra: --8---cut here---start-8--- $ /gnu/store/14ja1vpbc55yfgpp4irxwriw390zbl1g-evince-3.6.1/bin/evince doc/foo.pdf ** (..evince-real-real:5821): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files Error registering document: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.evince.Daemon was not provided by any .service files GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. --8---cut here---end---8--- So I’m pretty clueless. Could it be that it receives some message over D-Bus (on your machine) telling it to load the thing? What does ‘dbus-monitor’ show? So this is the daemon the GSettings API normally connects to, right? I believe so. At least that's what I understood reading some of the documentation and some threads, e.g.: http://permalink.gmane.org/gmane.comp.gnome.shell/5897 dconf is the replacement for gconf which is now considered deprecated. For emacs specifically it appears that the warning may be suppressed with configure flags --without-gsettings and --disable-gconf: Sure, but that would be cheating. :-) Thanks, Ludo’.
Re: [PATCH] glib-or-gtk-build-system: new build-system
l...@gnu.org (Ludovic Courtès) writes: Not sure. Is libcanberra dlopened? Do you know what dlopens it, and whether it systematically does? I've not found out. I'm attaching the strace log of evince (actually the wrapper of my local package built with glib-or-gtk). Maybe you see more than me. In any case, I've checked a couple more applications making use of the gtk toolkit: inkscape, icecat. They all complain about libcanberra-gtk-module. It looks like libcanberra is used by many gtk+ applications. On debian aptitude why libcanberra-gtk-module reports the following depencencies: i task-gnome-desktop Dependsgnome-core i A gnome-core Dependsmetacity (= 1:2.34) i A metacity Dependslibcanberra-gtk0 (= 0.2) i A libcanberra-gtk0 Recommends libcanberra-gtk-module So this is the daemon the GSettings API normally connects to, right? I believe so. At least that's what I understood reading some of the documentation and some threads, e.g.: http://permalink.gmane.org/gmane.comp.gnome.shell/5897 dconf is the replacement for gconf which is now considered deprecated. For emacs specifically it appears that the warning may be suppressed with configure flags --without-gsettings and --disable-gconf: http://www.linuxquestions.org/questions/slackware-14/glib-gio-message-when-starting-emacs-after-latest-current-update-4175418191/ Not sure how emacs uses those features. Regards, Fede evince-fbe-wrapper.log.gz Description: application/gzip
Re: [PATCH] glib-or-gtk-build-system: new build-system
Federico Beffa be...@ieee.org skribis: l...@gnu.org (Ludovic Courtès) writes: Not sure. Is libcanberra dlopened? Do you know what dlopens it, and whether it systematically does? I've not found out. I'm attaching the strace log of evince (actually the wrapper of my local package built with glib-or-gtk). Maybe you see more than me. Is the GTK_MODULES environment variable defined on your system? AIUI, that tells GTK+ what modules to dlopen. Ludo’.
Re: [PATCH] glib-or-gtk-build-system: new build-system
On Mon, Oct 6, 2014 at 11:32 PM, Ludovic Courtès l...@gnu.org wrote: Excellent! Would be nice to check Evince and EOG, which were known to have this kind of problem. I've checked Evince and it works fine. I couldn't find EOG. What's the name of the package? Great. The strategy looks good to me. Mark had concerns about the wrapper approach in general, but IMO it’s OK here. Thoughts? Yes, I've read Mark's comments. I'm not ignoring his comments. I just do not have a better idea. Attached an updated patch. If it is fine, I will update the documentation in a separate patch to follow. Regards, Fede From 3bcb914162de1950ff927bc44cb91ea20bd5c1d4 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 6 Oct 2014 15:49:29 +0200 Subject: [PATCH] glib-or-gtk-build-system: New files * guix/build-system/glib-or-gtk.scm, guix/build/glib-or-gtk-build-system.scm: Add initial version of a new build-system called 'glib-or-gtk-build-system'. --- guix/build-system/glib-or-gtk.scm | 195 guix/build/glib-or-gtk-build-system.scm | 130 + 2 files changed, 325 insertions(+) create mode 100644 guix/build-system/glib-or-gtk.scm create mode 100644 guix/build/glib-or-gtk-build-system.scm diff --git a/guix/build-system/glib-or-gtk.scm b/guix/build-system/glib-or-gtk.scm new file mode 100644 index 000..8abdf9f --- /dev/null +++ b/guix/build-system/glib-or-gtk.scm @@ -0,0 +1,195 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2013, 2014 Ludovic Courtès l...@gnu.org +;;; Copyright © 2013 Cyril Roelandt tipec...@gmail.com +;;; Copyright © 2014 Federico Beffa be...@fbengineering.ch +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix build-system glib-or-gtk) + #:use-module (guix store) + #:use-module (guix utils) + #:use-module (guix derivations) + #:use-module (guix build-system) + #:use-module (guix build-system gnu) + #:use-module (guix packages) + #:use-module (ice-9 match) + #:export (glib-or-gtk-build +glib-or-gtk-build-system)) + +;; Commentary: +;; +;; This build system is an extension of the 'gnu-build-system'. It +;; accomodates the needs of applications making use of glib or gtk+ (with or +;; to be interpreted in the mathematical sense). This is achieved by adding +;; two phases run after the 'install' phase: +;; +;; 'glib-or-gtk-wrap' phase: +;; +;; a) This phase looks for GSettings schemas by verifying the existence of +;; path datadir/glib-2.0/schemas in all input packages. If the path is +;; found in any package, then all programs in out/bin are wrapped in scripts +;; where the environment variable XDG_DATA_DIRS is set and points to the +;; list of found schemas directories. +;; +;; b) Looks for the existence of libdir/gtk-3.0 directories in all input +;; packages. If any is found, then the environment variable GTK_PATH is +;; suitably set and added to the wrappers. The variable GTK_PATH has been +;; preferred over GTK_EXE_PREFIX because the latter can only point to a +;; single directory, while we may need to point to several ones. +;; +;; 'glib-or-gtk-compile-schemas' phase: +;; +;; Looks for the presence of out/share/glib-2.0/schemas. If that directory +;; exists and does not include a file named gschemas.compiled, then +;; glib-compile-schemas is run in that directory. +;; +;; Code: + +(define %default-modules + ;; Build-side modules made available in the build environment. + '((guix build glib-or-gtk-build-system) +(guix build utils))) + +(define %default-imported-modules + ;; Build-side modules imported and used by default. + '((guix build gnu-build-system) +(guix build glib-or-gtk-build-system) +(guix build utils))) + +(define (default-glib) + Return the default glib package from which we use +\glib-compile-schemas\. + ;; Do not use `@' to avoid introducing circular dependencies. + (let ((module (resolve-interface '(gnu packages glib +(module-ref module 'glib))) + +(define* (lower name +#:key source inputs native-inputs outputs system target +(glib (default-glib)) (implicit-inputs? #t) +(strip-binaries? #t) +#:allow-other-keys +#:rest arguments) + Return a bag for NAME. + (define
Re: [PATCH] glib-or-gtk-build-system: new build-system
On Wed, Oct 8, 2014 at 9:28 AM, Federico Beffa be...@ieee.org wrote: Attached an updated patch. If it is fine, I will update the documentation in a separate patch to follow. I forgot to mention that I'm not sure how to update gnu-system.am. I looked for cmake-build-system as an example, but it is not mentioned in the file. Regards, Fede
Re: [PATCH] glib-or-gtk-build-system: new build-system
Federico Beffa be...@ieee.org skribis: On Wed, Oct 8, 2014 at 9:28 AM, Federico Beffa be...@ieee.org wrote: Attached an updated patch. If it is fine, I will update the documentation in a separate patch to follow. I forgot to mention that I'm not sure how to update gnu-system.am. I looked for cmake-build-system as an example, but it is not mentioned in the file. It’s actually in Makefile.am. gnu-system.am is for things under gnu/. Ludo’.
Re: [PATCH] glib-or-gtk-build-system: new build-system
Federico Beffa be...@ieee.org skribis: On Mon, Oct 6, 2014 at 11:32 PM, Ludovic Courtès l...@gnu.org wrote: Excellent! Would be nice to check Evince and EOG, which were known to have this kind of problem. I've checked Evince and it works fine. Great. I couldn't find EOG. What's the name of the package? I remember Cyril mentioned it in a discussion, but it’s not in the tree, so forget about it. Attached an updated patch. If it is fine, I will update the documentation in a separate patch to follow. OK. From 3bcb914162de1950ff927bc44cb91ea20bd5c1d4 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 6 Oct 2014 15:49:29 +0200 Subject: [PATCH] glib-or-gtk-build-system: New files * guix/build-system/glib-or-gtk.scm, guix/build/glib-or-gtk-build-system.scm: Add initial version of a new build-system called 'glib-or-gtk-build-system'. I’ve pushed the patch after adding the files to Makefile.am and tweaking the commit log (I realize I wasn’t clear: “New files” is for the body of the commit log, whereas the subject line is typically a sentence.) Thanks! Ludo’.
Re: [PATCH] glib-or-gtk-build-system: new build-system
On Wed, Oct 8, 2014 at 12:04 PM, Ludovic Courtès l...@gnu.org wrote: Federico Beffa be...@ieee.org skribis: I've checked Evince and it works fine. By the way, note that when started, it complains about missing libcanberra as does emacs. The problem is solved by adding libcanberra as an input to both programs. Maybe libcanberra should be made a propagating-input of some lower level library? Also, as emacs, it give the warning GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. I believe this is because they can't find dconf. Any particular reason for not being in gnome.scm? Regards, Fede
Re: [PATCH] glib-or-gtk-build-system: new build-system
Federico Beffa be...@ieee.org skribis: Please find attached a new build system for applications making use of glib or gtk+. It uses wrappers as previously discussed on this list. I've successfully tested it with three packages: emacs, libcanberra and gtk+. Excellent! Would be nice to check Evince and EOG, which were known to have this kind of problem. Currently it is implemented as a separate build-system inheriting from the gnu-build-system. Essentially it adds 2 phases to the latter. IMO, it would make sense to make those 2 phases part of the gnu-build-system and enable them with the help of flags. Great. The strategy looks good to me. Mark had concerns about the wrapper approach in general, but IMO it’s OK here. Thoughts? Some mostly cosmetic comments: From dcb7dc451eac21e24e6972fa4c1a4524a7658af0 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 6 Oct 2014 15:49:29 +0200 Subject: [PATCH] glib-or-gtk-build-system: new build-system * guix/build-system/glib-or-gtk.scm, guix/build/glib-or-gtk-build-system.scm: Add initial version of a new build-system called 'glib-or-gtk-build-system'. Just “New files.” Also, make sure to add them to gnu-system.am and to mention it in the log. +(define* (glib-or-gtk-build store name source inputs + #:key (guile #f) + (outputs '(out)) + (search-paths '()) + (configure-flags ''()) + (make-flags ''()) + (glib (default-glib)) Please align parameters with ‘store’. This will have to be adjusted to the new “bags” interface. Namely, the part that adds inputs must be moved to a new procedure (called ‘lower’ in the other build systems), and ‘glib-or-gtk-build’ will be simplified accordingly. It should be simple to see what needs to be changed by looking at the other build systems, but let me know if you have any questions. +(define (rel-path-exists? path rel-path) + (directory-exists? (string-append path rel-path))) Rather (subdirectory-exists? parent sub-directory). (By convention GNU software uses “file names” or “directory names” here, whereas “path” is used for search paths.) +(define (gtk-module-dirs inputs) + Check for the existence of \libdir/gtk-v.0\ in INPUTS. Return a list +with all found pathes. If none is found return an empty list. s/dirs/directories/ and s/pathes/directories/ No need for “If none is found...”, because it’s just a special case. +(define (glib-schemas input prev) + (let* ((in (match input + ((_ . dir) dir) + (_ ))) + (datadir (string-append in /share))) +(if (rel-path-exists? datadir /glib-2.0/schemas) +(cons datadir prev) +prev))) I think this should be moved into ‘schemas-directories’. +(define (schemas-dirs inputs) + Check for the existence of \datadir/glib-2.0/schemas\ in INPUTS. Return +a list with all found pathes. If none is found return an empty list. Rather ‘schemas-directories’, and also “directories” instead of “pathes”. +(define* (glib-or-gtk-build #:key inputs (phases %standard-phases) + #:allow-other-keys #:rest args) Please align #:allow-other-keys with #:key. Lastly, could add an entry in guix.texi under “Build Systems”, ideally with references (@uref) to the GSettings and GTK+ module documentation? Could you post an updated patch? Thanks for all this! Ludo’.
