* GSettings schemas
@ 2016-02-11 22:29 Fabian Harfert
0 siblings, 0 replies; 3+ messages in thread
From: Fabian Harfert @ 2016-02-11 22:29 UTC (permalink / raw)
To: guix-devel
Hi!
Trying to use some successfully built packages I noticed that they fail
to start because of missing installed GSettings schemas. When the
profile is build, each package, that has a gschemas.compiled file in
its share/glib-2.0/schemas/ directory overides the one of the last
package so that lots of schemas are missing.
I think it would be enough to just call 'glib-compile-schemas' with the
profile output directory as an argument after all packages are in the
profile, where their XML schema files live in share/glib-2.0/schemas/.
That would generate one gschemas.compiled for all of them.
WDYT?
Fabian
^ permalink raw reply [flat|nested] 3+ messages in thread
* emacs package
@ 2014-09-13 13:13 Federico Beffa
2014-09-15 7:55 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-13 13:13 UTC (permalink / raw)
To: guix-devel
Hi,
I've installed guix 0.7 and its emacs package (and updated with "guix
pull" and "guix package -u"). When I start emacs I get the following
message:
Gtk-Message: Failed to load module "canberra-gtk-module"
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
I'm on Debian 7.6 with the packages libcanberra-gtk-module and
libcanberra-gtk3-module. I've noticed that guix provides a libcanberra
package. Should I install that one as well? If yes, shouldn't the
emacs package install it automatically? Is it possible to make emacs
find the system installed libcanberra library?
Also I'm wondering about the meaning of the second line.
Regards,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-13 13:13 emacs package Federico Beffa
@ 2014-09-15 7:55 ` Ludovic Courtès
2014-09-16 7:38 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-15 7:55 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> I've installed guix 0.7 and its emacs package (and updated with "guix
> pull" and "guix package -u"). When I start emacs I get the following
> message:
>
> Gtk-Message: Failed to load module "canberra-gtk-module"
> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
> will not be saved or shared with other applications.
It looks like a mere warning, not a fatal error, right?
FWIW I don’t see it on the whole Guix system here.
> I'm on Debian 7.6 with the packages libcanberra-gtk-module and
> libcanberra-gtk3-module. I've noticed that guix provides a libcanberra
> package. Should I install that one as well? If yes, shouldn't the
> emacs package install it automatically? Is it possible to make emacs
> find the system installed libcanberra library?
Using the host distro’s libcanberra would likely fail in unexpected
ways.
Perhaps the solution would be to add libcanberra as an input to the
‘emacs’ package, in emacs.scm. Would you like to try that?
> Also I'm wondering about the meaning of the second line.
I don’t think Emacs uses GConf for anything serious, so I wouldn’t worry
about that. ;-)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-15 7:55 ` Ludovic Courtès
@ 2014-09-16 7:38 ` Federico Beffa
2014-09-16 20:04 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-16 7:38 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Mon, Sep 15, 2014 at 9:55 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> I've installed guix 0.7 and its emacs package (and updated with "guix
>> pull" and "guix package -u"). When I start emacs I get the following
>> message:
>>
>> Gtk-Message: Failed to load module "canberra-gtk-module"
>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
>> will not be saved or shared with other applications.
>
> It looks like a mere warning, not a fatal error, right?
>
Correct, it is not a fatal error.
> FWIW I don’t see it on the whole Guix system here.
>
>> I'm on Debian 7.6 with the packages libcanberra-gtk-module and
>> libcanberra-gtk3-module. I've noticed that guix provides a libcanberra
>> package. Should I install that one as well? If yes, shouldn't the
>> emacs package install it automatically? Is it possible to make emacs
>> find the system installed libcanberra library?
>
> Using the host distro’s libcanberra would likely fail in unexpected
> ways.
>
> Perhaps the solution would be to add libcanberra as an input to the
> ‘emacs’ package, in emacs.scm. Would you like to try that?
>
I will try out.
Regards,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-16 7:38 ` Federico Beffa
@ 2014-09-16 20:04 ` Federico Beffa
2014-09-17 9:11 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-16 20:04 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Tue, Sep 16, 2014 at 9:38 AM, Federico Beffa <beffa@ieee.org> wrote:
> On Mon, Sep 15, 2014 at 9:55 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> I've installed guix 0.7 and its emacs package (and updated with "guix
>>> pull" and "guix package -u"). When I start emacs I get the following
>>> message:
>>>
>>> Gtk-Message: Failed to load module "canberra-gtk-module"
>>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
>>> will not be saved or shared with other applications.
>>
>> It looks like a mere warning, not a fatal error, right?
>>
>
> Correct, it is not a fatal error.
>
>> FWIW I don’t see it on the whole Guix system here.
>>
>>> I'm on Debian 7.6 with the packages libcanberra-gtk-module and
>>> libcanberra-gtk3-module. I've noticed that guix provides a libcanberra
>>> package. Should I install that one as well? If yes, shouldn't the
>>> emacs package install it automatically? Is it possible to make emacs
>>> find the system installed libcanberra library?
>>
>> Using the host distro’s libcanberra would likely fail in unexpected
>> ways.
>>
>> Perhaps the solution would be to add libcanberra as an input to the
>> ‘emacs’ package, in emacs.scm. Would you like to try that?
>>
>
> I will try out.
>
> Regards,
> Fede
Currently the libcanberra package does not build. It can't find the source:
starting download of
`/gnu/store/n9g0vd6hdka11s7zp3lbqkvyiw99hwzb-libcanberra-0.30.tar.xz'
from `http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz'...
ERROR: download failed
"http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz"
404 "Not Found"
failed to download
"/gnu/store/n9g0vd6hdka11s7zp3lbqkvyiw99hwzb-libcanberra-0.30.tar.xz"
from "http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz"
Regards,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-16 20:04 ` Federico Beffa
@ 2014-09-17 9:11 ` Ludovic Courtès
2014-09-17 16:57 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-17 9:11 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> Currently the libcanberra package does not build. It can't find the source:
>
> starting download of
> `/gnu/store/n9g0vd6hdka11s7zp3lbqkvyiw99hwzb-libcanberra-0.30.tar.xz'
> from `http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz'...
> ERROR: download failed
> "http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz"
> 404 "Not Found"
Should be fixed now.
Note that enabling substitutes hides the problem, because hydra.gnu.org
has a cached copy.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-17 9:11 ` Ludovic Courtès
@ 2014-09-17 16:57 ` Federico Beffa
2014-09-18 12:01 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-17 16:57 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Wed, Sep 17, 2014 at 11:11 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> Currently the libcanberra package does not build. It can't find the source:
>>
>> starting download of
>> `/gnu/store/n9g0vd6hdka11s7zp3lbqkvyiw99hwzb-libcanberra-0.30.tar.xz'
>> from `http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz'...
>> ERROR: download failed
>> "http://0pointer.de/lennart/projects/libcanberra/libcanberra-0.30.tar.xz"
>> 404 "Not Found"
>
> Should be fixed now.
>
> Note that enabling substitutes hides the problem, because hydra.gnu.org
> has a cached copy.
>
Actually I have the hydra.gnu.org substitute active, but for some
reason guix didn't want to download from there.
It's now working. Thanks!
Regarding the libcanberra message. I've added it as input to emacs,
but got the same message. Then I noticed that the emacs recipe
specifies gtk+-2, but the libcanberra one specifies gtk+ which
defaults to v3 (I think). So I've changed the version in the emacs
recipe to v3, but I still get the message.
This is the test recipe that I built:
(use-modules (guix) (gnu) (srfi srfi-1)
(guix packages)
(guix download))
(let ((emacs (car (find-packages-by-name "emacs")))
(libcanberra (car (find-packages-by-name "libcanberra")))
(gtk+ (car (find-packages-by-name "gtk+"))))
(package
(inherit emacs)
(name "emacs-canberra")
(version "24.3")
(source (origin
(method url-fetch)
(uri "mirror://gnu/emacs/emacs-24.3.tar.xz")
(sha256
(base32
"1385qzs3bsa52s5rcncbrkxlydkw0ajzrvfxgv8rws5fx512kakh"))
(patches (list (search-patch
"/home/beffa/src/guix/git/guix/gnu/packages/patches/emacs-configure-sh.patch")))))
(inputs
(alist-cons "gtk+" (list gtk+)
(alist-delete "gtk+"
(alist-cons "libcanberra" (list libcanberra)
(package-inputs emacs)))))))
Then I built it with
guix build -e '(load "emacs-canberra.scm")'
Using strace I have the impression that emacs is still looking for
gtk-2, but currently I do not see where this could be coming from.
Regards,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-17 16:57 ` Federico Beffa
@ 2014-09-18 12:01 ` Ludovic Courtès
2014-09-18 18:37 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-18 12:01 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> This is the test recipe that I built:
>
> (use-modules (guix) (gnu) (srfi srfi-1)
> (guix packages)
> (guix download))
>
> (let ((emacs (car (find-packages-by-name "emacs")))
> (libcanberra (car (find-packages-by-name "libcanberra")))
> (gtk+ (car (find-packages-by-name "gtk+"))))
> (package
> (inherit emacs)
> (name "emacs-canberra")
> (version "24.3")
> (source (origin
> (method url-fetch)
> (uri "mirror://gnu/emacs/emacs-24.3.tar.xz")
> (sha256
> (base32
> "1385qzs3bsa52s5rcncbrkxlydkw0ajzrvfxgv8rws5fx512kakh"))
> (patches (list (search-patch
> "/home/beffa/src/guix/git/guix/gnu/packages/patches/emacs-configure-sh.patch")))))
No need for ‘search-path’ here. since the absolute file name is given.
> (inputs
> (alist-cons "gtk+" (list gtk+)
> (alist-delete "gtk+"
> (alist-cons "libcanberra" (list libcanberra)
> (package-inputs emacs)))))))
I put it in the REPL, and then used ‘package-transitive-inputs’ to see
if there was any GTK+ left:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (let ((emacs (car (find-packages-by-name "emacs")))
(libcanberra (car (find-packages-by-name "libcanberra")))
(gtk+ (car (find-packages-by-name "gtk+"))))
(package
[...]
$7 = #<package emacs-canberra-24.3 gnu/packages/emacs.scm:52 43d6210>
scheme@(guile-user)> (filter (match-lambda
((label (? package? p) . _)
(string=? "gtk+" (package-name p))))
(package-transitive-inputs $7))
$8 = (("gtk+" #<package gtk+-2.24.21 gnu/packages/gtk.scm:342 32a8e70>))
--8<---------------cut here---------------end--------------->8---
There’s only one GTK+ here.
Could you try ‘ldd emacs’ on this Emacs, and see what it returns?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-18 12:01 ` Ludovic Courtès
@ 2014-09-18 18:37 ` Federico Beffa
2014-09-19 7:54 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-18 18:37 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 12523 bytes --]
On Thu, Sep 18, 2014 at 2:01 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> This is the test recipe that I built:
>>
>> (use-modules (guix) (gnu) (srfi srfi-1)
>> (guix packages)
>> (guix download))
>>
>> (let ((emacs (car (find-packages-by-name "emacs")))
>> (libcanberra (car (find-packages-by-name "libcanberra")))
>> (gtk+ (car (find-packages-by-name "gtk+"))))
>> (package
>> (inherit emacs)
>> (name "emacs-canberra")
>> (version "24.3")
>> (source (origin
>> (method url-fetch)
>> (uri "mirror://gnu/emacs/emacs-24.3.tar.xz")
>> (sha256
>> (base32
>> "1385qzs3bsa52s5rcncbrkxlydkw0ajzrvfxgv8rws5fx512kakh"))
>> (patches (list (search-patch
>> "/home/beffa/src/guix/git/guix/gnu/packages/patches/emacs-configure-sh.patch")))))
>
> No need for ‘search-path’ here. since the absolute file name is given.
>
>> (inputs
>> (alist-cons "gtk+" (list gtk+)
>> (alist-delete "gtk+"
>> (alist-cons "libcanberra" (list libcanberra)
>> (package-inputs emacs)))))))
>
> I put it in the REPL, and then used ‘package-transitive-inputs’ to see
> if there was any GTK+ left:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> (let ((emacs (car (find-packages-by-name "emacs")))
> (libcanberra (car (find-packages-by-name "libcanberra")))
> (gtk+ (car (find-packages-by-name "gtk+"))))
> (package
>
> [...]
>
> $7 = #<package emacs-canberra-24.3 gnu/packages/emacs.scm:52 43d6210>
> scheme@(guile-user)> (filter (match-lambda
> ((label (? package? p) . _)
> (string=? "gtk+" (package-name p))))
> (package-transitive-inputs $7))
> $8 = (("gtk+" #<package gtk+-2.24.21 gnu/packages/gtk.scm:342 32a8e70>))
> --8<---------------cut here---------------end--------------->8---
>
> There’s only one GTK+ here.
>
> Could you try ‘ldd emacs’ on this Emacs, and see what it returns?
>
> Thanks,
> Ludo’.
Yes, you are right. Yesterday I was messing around with the environment
variable GTK_MODULE. I guess that confused me. Having undefined it now I
only see reference to gtk-3:
$ ldd /gnu/store/cd8x9llkvfj29rwzd455a7pf0fq6kwnl-emacs-canberra-24.3/bin/emacs-24.3
linux-vdso.so.1 (0x00007fff4edff000)
libtiff.so.5 =>
/gnu/store/0y0p2pi4pnjxzfl1xzvd241wzd42zihl-libtiff-4.0.3/lib/libtiff.so.5
(0x00007f347ad0e000)
libjpeg.so.8 =>
/gnu/store/99p3ciijacdzay73rpsz3h68qv4rpf21-libjpeg-8d/lib/libjpeg.so.8
(0x00007f347aad4000)
libpng15.so.15 =>
/gnu/store/gq2yb0df0m15h417bpl5lqms7wr0f404-libpng-1.5.17/lib/libpng15.so.15
(0x00007f347a8ab000)
libz.so.1 =>
/gnu/store/k53im094qqjgg0yf0rfy9ci9xqs27lv7-zlib-1.2.7/lib/libz.so.1
(0x00007f347a693000)
libm.so.6 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libm.so.6
(0x00007f347a392000)
libgif.so.4 =>
/gnu/store/w4d0ivdg77s42qvnj6kwvaar8j8wilq6-giflib-4.2.3/lib/libgif.so.4
(0x00007f347a18a000)
libXpm.so.4 =>
/gnu/store/cqwjzl9ccsx2i9lya4q9q7gabbs8zfgm-libxpm-3.5.10/lib/libXpm.so.4
(0x00007f3479f79000)
libgtk-3.so.0 =>
/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
(0x00007f347987b000)
libgdk-3.so.0 =>
/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgdk-3.so.0
(0x00007f34795ea000)
libatk-1.0.so.0 =>
/gnu/store/fvslzymf14bk04c8dbqlza18b6b8ki9q-atk-2.10.0/lib/libatk-1.0.so.0
(0x00007f34793c8000)
libgio-2.0.so.0 =>
/gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgio-2.0.so.0
(0x00007f3479057000)
libpangocairo-1.0.so.0 =>
/gnu/store/blp52rm0zx4508kaplb46sc1bwxl2iad-pango-1.34.1/lib/libpangocairo-1.0.so.0
(0x00007f3478e4a000)
libgdk_pixbuf-2.0.so.0 =>
/gnu/store/9dx5hlknyi4pcxqdda0b299w46pcg5j1-gdk-pixbuf-2.28.2/lib/libgdk_pixbuf-2.0.so.0
(0x00007f3478c2a000)
libcairo-gobject.so.2 =>
/gnu/store/kcm3qfllrjlf0zy61854a8lj6p8bmspn-cairo-1.12.16/lib/libcairo-gobject.so.2
(0x00007f3478a22000)
libpango-1.0.so.0 =>
/gnu/store/blp52rm0zx4508kaplb46sc1bwxl2iad-pango-1.34.1/lib/libpango-1.0.so.0
(0x00007f34787d8000)
libcairo.so.2 =>
/gnu/store/kcm3qfllrjlf0zy61854a8lj6p8bmspn-cairo-1.12.16/lib/libcairo.so.2
(0x00007f34784d2000)
libgobject-2.0.so.0 =>
/gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
(0x00007f3478282000)
libglib-2.0.so.0 =>
/gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
(0x00007f3477f51000)
libSM.so.6 =>
/gnu/store/by18z1yihhp2ci8wi1aippd1i1850r3x-libsm-1.2.1/lib/libSM.so.6
(0x00007f3477d4a000)
libICE.so.6 =>
/gnu/store/8irn4rn8xzw7cwif368fx45g2k4gqsma-libice-1.0.8/lib/libICE.so.6
(0x00007f3477b2f000)
libX11.so.6 =>
/gnu/store/4n4xhxm150z7d0n7ki6mbr553hyvxp87-libx11-1.5.0/lib/libX11.so.6
(0x00007f34777f6000)
libXrender.so.1 =>
/gnu/store/0m3lgjilccpiw32vqi65k8b66zhdb6v5-libxrender-0.9.7/lib/libXrender.so.1
(0x00007f34775ed000)
libXft.so.2 =>
/gnu/store/s48isysmn3xxjd8va6hc5j6sb4g1amfi-libxft-2.3.1/lib/libXft.so.2
(0x00007f34773d8000)
libasound.so.2 =>
/gnu/store/vw3lq9z0p02zv24p8zmk0qsj6wxgb6ij-alsa-lib-1.0.27.1/lib/libasound.so.2
(0x00007f34770b4000)
librt.so.1 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/librt.so.1
(0x00007f3476eac000)
libdbus-1.so.3 =>
/gnu/store/80lyw961agzz0vpkwkccpzxri12yrc41-dbus-1.6.4/lib/libdbus-1.so.3
(0x00007f3476c66000)
libxml2.so.2 =>
/gnu/store/lavqwx6qi6nvlm5cj1h2rbw9yn63mdpp-libxml2-2.9.0/lib/libxml2.so.2
(0x00007f3476901000)
libncursesw.so.5 =>
/gnu/store/zncycfxkkgn6hsziw3wmpsdfabhdi3n8-ncurses-5.9/lib/libncursesw.so.5
(0x00007f347669f000)
libfreetype.so.6 =>
/gnu/store/rgrckir6k1zi8490z4sn52d9pzcqw872-freetype-2.4.11/lib/libfreetype.so.6
(0x00007f34763ff000)
libfontconfig.so.1 =>
/gnu/store/yi31nvrp18x0241zddyyg0m9wl8qglhn-fontconfig-2.10.93/lib/libfontconfig.so.1
(0x00007f34761c4000)
libgnutls.so.28 =>
/gnu/store/rpf0i00hnaql1qi1xchb7nkcfq8h0d84-gnutls-3.2.15/lib/libgnutls.so.28
(0x00007f3475ec1000)
libpthread.so.0 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libpthread.so.0
(0x00007f3475ca3000)
libc.so.6 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libc.so.6
(0x00007f34758fa000)
liblzma.so.5 =>
/gnu/store/ah9rclsxmnzg9xif7ws9d4bm82v4lr1l-xz-5.0.4/lib/liblzma.so.5
(0x00007f34756d8000)
libgcc_s.so.1 =>
/gnu/store/1qf4rsznfhvdis39jzdmx0dfjy2jwzgz-gcc-4.8.3-lib/lib/libgcc_s.so.1
(0x00007f34754c2000)
libxcb.so.1 =>
/gnu/store/wl8llszn3q574ijksab621fwv6b4sjsy-libxcb-1.8.1/lib/libxcb.so.1
(0x00007f34752a5000)
libXau.so.6 =>
/gnu/store/xpnyzjq3viyqvqrhsr4vg6gzips9r7sy-libxau-1.0.7/lib/libXau.so.6
(0x00007f34750a2000)
libXdmcp.so.6 =>
/gnu/store/fssqlvp8rbfxm4p02d7pczdi5aq4fxsr-libxdmcp-1.1.1/lib/libXdmcp.so.6
(0x00007f3474e9d000)
libdl.so.2 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libdl.so.2
(0x00007f3474c99000)
libXinerama.so.1 =>
/gnu/store/grh86nv12p1m4fnysmlf59k8x68c35rj-libxinerama-1.1.2/lib/libXinerama.so.1
(0x00007f3474a97000)
libharfbuzz.so.0 =>
/gnu/store/a8xlnnxhla612yiinlfpg79vvs01fhqs-harfbuzz-0.9.22/lib/libharfbuzz.so.0
(0x00007f3474847000)
libXi.so.6 =>
/gnu/store/yyhqn5fcxi28frn5ca4yk2afx4qcfa6z-libxi-1.6.1/lib/libXi.so.6
(0x00007f3474638000)
libpixman-1.so.0 =>
/gnu/store/dvrvjz8f24saqbv921mwdgfm5x4v1p5s-pixman-0.32.4/lib/libpixman-1.so.0
(0x00007f347438e000)
libxcb-shm.so.0 =>
/gnu/store/wl8llszn3q574ijksab621fwv6b4sjsy-libxcb-1.8.1/lib/libxcb-shm.so.0
(0x00007f347418c000)
libxcb-render.so.0 =>
/gnu/store/wl8llszn3q574ijksab621fwv6b4sjsy-libxcb-1.8.1/lib/libxcb-render.so.0
(0x00007f3473f83000)
libXext.so.6 =>
/gnu/store/ijal248zay4yzbzrjcvnfis9mc14h1ry-libxext-1.3.1/lib/libXext.so.6
(0x00007f3473d71000)
libatk-bridge-2.0.so.0 =>
/gnu/store/mpwapvwy6zwj4rj0jd0hlsvh6pljhb44-at-spi2-atk-2.10.0/lib/libatk-bridge-2.0.so.0
(0x00007f3473b46000)
libatspi.so.0 =>
/gnu/store/974vn9yjhpzibh8ci06gn7njka3c79di-at-spi2-core-2.10.0/lib/libatspi.so.0
(0x00007f3473919000)
libpangoft2-1.0.so.0 =>
/gnu/store/blp52rm0zx4508kaplb46sc1bwxl2iad-pango-1.34.1/lib/libpangoft2-1.0.so.0
(0x00007f3473705000)
libgthread-2.0.so.0 =>
/gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgthread-2.0.so.0
(0x00007f3473504000)
libexpat.so.1 =>
/gnu/store/y0fahbrfx871dijpb5w164y7r2zl6i5j-expat-2.1.0/lib/libexpat.so.1
(0x00007f34732db000)
libgmodule-2.0.so.0 =>
/gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgmodule-2.0.so.0
(0x00007f34730d8000)
libresolv.so.2 =>
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libresolv.so.2
(0x00007f3472ec1000)
libffi.so.6 =>
/gnu/store/5c94pmrv0x37qjn9qm5w9nphqz1r6l2v-libffi-3.0.13/lib/libffi.so.6
(0x00007f3472cb8000)
libuuid.so.1 =>
/gnu/store/jcxd13rx81h2hcjvf80c8iwpnvp65k3b-util-linux-2.21/lib/libuuid.so.1
(0x00007f3472ab4000)
/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/ld-linux-x86-64.so.2
(0x00007f347af80000)
libtasn1.so.6 =>
/gnu/store/52kdi2gmrl2ms92as0nsxbbkndqx07s4-libtasn1-4.1/lib/libtasn1.so.6
(0x00007f34728a2000)
libnettle.so.4 =>
/gnu/store/ybrsdvzzd9mwjkx01dcxlv1i6d1p5cd6-nettle-2.7.1/lib/libnettle.so.4
(0x00007f3472675000)
libhogweed.so.2 =>
/gnu/store/ybrsdvzzd9mwjkx01dcxlv1i6d1p5cd6-nettle-2.7.1/lib/libhogweed.so.2
(0x00007f3472447000)
libgmp.so.10 =>
/gnu/store/1sjpwj0hlazs8nhx50dhihx6nr9mskjq-gmp-6.0.0a/lib/libgmp.so.10
(0x00007f34721ba000)
In the mean time I've found out the existence of a simple test program
called canberra-gtk-play in the libcanberra package. With this I tested
that I can actually play a sound, but it gives the same message:
$ canberra-gtk-play -i phone-incoming-call
Gtk-Message: Failed to load module "canberra-gtk-module"
After playing somewhat with GTK_PATH I've found that if I set it like
shown below I do not get the warning message:
$ GTK_PATH="/home/beffa/.guix-profile/lib/gtk-3.0"
/gnu/store/cd8x9llkvfj29rwzd455a7pf0fq6kwnl-emacs-canberra-24.3/bin/emacs
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
$ GTK_PATH="/home/beffa/.guix-profile/lib/gtk-3.0" canberra-gtk-play
-i phone-incoming-call
However, with the official emacs package I still get it:
$ GTK_PATH="/home/beffa/.guix-profile/lib/gtk-2.0" emacs
Gtk-Message: Failed to load module "canberra-gtk-module"
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
$ GTK_PATH="/home/beffa/.guix-profile/lib/gtk-3.0" emacs
(emacs:7105): Gtk-WARNING **: GTK+ module
/home/beffa/.guix-profile/lib/gtk-3.0/modules/libcanberra-gtk-module.so
cannot be loaded.
GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same
process is not supported.
Gtk-Message: Failed to load module "canberra-gtk-module"
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
So, I've rebuilt emacs without libcanberra, but with gtk-3 with the
attached recipe and now the message is gone:
$ GTK_PATH=/home/beffa/.guix-profile/lib/gtk-3.0
/gnu/store/4y7ic831rbawm96qb1n4da19x9qlwk73-emacs-gtk3-24.3/bin/emacs
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
So my conclusion is:
Given that libcanberra is built with gtk-3 and emacs builds fine with
gtk-3, I would suggest to change gtk version in the emacs package
(I've also added --with-x-toolkit=gtk3 as flag to configure. Not sure
if this is really necessary).
In addition, it would be nice not to have to define GTK_PATH. I guess
that would require some modification to either libcanberra or the gtk
package.
On a side note, I built a couple of variants of emacs-canberra. After
a while I wanted to check which one is the most recent one with
$ ls -l /gnu/store/*emacs-canb*
and have found out that all files in the store have a time stamp of "1
Jan 1970". Why is guix not producing the expected time stamps?
Regards,
Fede
[-- Attachment #2: emacs-gtk3.scm --]
[-- Type: text/x-scheme, Size: 1176 bytes --]
(use-modules (guix) (gnu) (srfi srfi-1)
(guix packages)
(guix download))
(let ((emacs (car (find-packages-by-name "emacs")))
(gtk+ (car (find-packages-by-name "gtk+"))))
(package
(inherit emacs)
(name "emacs-gtk3")
(version "24.3")
(source (origin
(method url-fetch)
(uri "mirror://gnu/emacs/emacs-24.3.tar.xz")
(sha256
(base32
"1385qzs3bsa52s5rcncbrkxlydkw0ajzrvfxgv8rws5fx512kakh"))
(patches (list "/home/beffa/src/guix/git/guix/gnu/packages/patches/emacs-configure-sh.patch"))))
(arguments
'(#:configure-flags
(list (string-append "--with-crt-dir=" (assoc-ref %build-inputs "libc")
"/lib")
"--with-x=yes"
"--with-x-toolkit=gtk3")
#:phases (alist-cons-before
'configure 'fix-/bin/pwd
(lambda _
;; Use `pwd', not `/bin/pwd'.
(substitute* (find-files "." "^Makefile\\.in$")
(("/bin/pwd")
"pwd")))
%standard-phases)))
(inputs
(alist-cons "gtk+" (list gtk+)
(alist-delete "gtk+" (package-inputs emacs))))))
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-18 18:37 ` Federico Beffa
@ 2014-09-19 7:54 ` Ludovic Courtès
2014-09-19 17:13 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-19 7:54 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> Yes, you are right. Yesterday I was messing around with the environment
> variable GTK_MODULE. I guess that confused me. Having undefined it now I
> only see reference to gtk-3:
Good.
> In the mean time I've found out the existence of a simple test program
> called canberra-gtk-play in the libcanberra package. With this I tested
> that I can actually play a sound, but it gives the same message:
>
> $ canberra-gtk-play -i phone-incoming-call
> Gtk-Message: Failed to load module "canberra-gtk-module"
Here, on the stand-alone system, it simply fails with:
--8<---------------cut here---------------start------------->8---
$ /gnu/store/nlm81g8hgsw7d01la14zjycjcgamn4qp-libcanberra-0.30/bin/canberra-gtk-play -i phone-incoming-call
Failed to play sound: File or data not found
--8<---------------cut here---------------end--------------->8---
Do you know where those audio samples normally come from? We seem to
miss that package.
I tried gnubg and pavucontrol, which both use libcanberra, but none of
them tries to load canberra-gtk-module.so. Could it be something that
appears in your machine’s /etc/gtk config files or something like that?
(As you can see I don’t know much about these GTK+ things.)
> So, I've rebuilt emacs without libcanberra, but with gtk-3 with the
> attached recipe and now the message is gone:
>
> $ GTK_PATH=/home/beffa/.guix-profile/lib/gtk-3.0
> /gnu/store/4y7ic831rbawm96qb1n4da19x9qlwk73-emacs-gtk3-24.3/bin/emacs
> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
> will not be saved or shared with other applications.
OK.
> So my conclusion is:
>
> Given that libcanberra is built with gtk-3 and emacs builds fine with
> gtk-3, I would suggest to change gtk version in the emacs package
> (I've also added --with-x-toolkit=gtk3 as flag to configure. Not sure
> if this is really necessary).
Emacs switched back to GTK+ 2 in commit 8b0275b6, but I forgot why.
Andreas, do you remember the reason?
Otherwise, I have nothing against upgrading Emacs to GTK+ 3.
> In addition, it would be nice not to have to define GTK_PATH. I guess
> that would require some modification to either libcanberra or the gtk
> package.
Sure, we’ll see what it takes exactly.
> On a side note, I built a couple of variants of emacs-canberra. After
> a while I wanted to check which one is the most recent one with
>
> $ ls -l /gnu/store/*emacs-canb*
>
> and have found out that all files in the store have a time stamp of "1
> Jan 1970". Why is guix not producing the expected time stamps?
This is done on purpose, to maximize the chances to obtain reproducible
behavior, and bit-identical builds.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-19 7:54 ` Ludovic Courtès
@ 2014-09-19 17:13 ` Federico Beffa
2014-09-20 13:20 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-19 17:13 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
ludo@gnu.org (Ludovic Courtès) writes:
>> In the mean time I've found out the existence of a simple test program
>> called canberra-gtk-play in the libcanberra package. With this I tested
>> that I can actually play a sound, but it gives the same message:
>>
>> $ canberra-gtk-play -i phone-incoming-call
>> Gtk-Message: Failed to load module "canberra-gtk-module"
>
> Here, on the stand-alone system, it simply fails with:
>
> $ /gnu/store/nlm81g8hgsw7d01la14zjycjcgamn4qp-libcanberra-0.30/bin/canberra-gtk-play -i phone-incoming-call
> Failed to play sound: File or data not found
>
> Do you know where those audio samples normally come from? We seem to
> miss that package.
>
On Debian the sound file is located here:
/usr/share/sounds/freedesktop/stereo/phone-incoming-call.oga
and is provided by a package called "sound-theme-freedesktop":
https://packages.debian.org/unstable/main/sound-theme-freedesktop
By the way, I'm using PulseAudio, but the current libcanberra package
has no support for this option. Therefore, despite the fact that I'm
using an external audio interface, the sound produced by
canberra-gtk-play goes to the built-in speakers of my PC.
I see that in guix there is a package for pulseaudio. Any particular
reason for not enabling this sound framework option in libcanberra?
Regards,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-19 17:13 ` Federico Beffa
@ 2014-09-20 13:20 ` Ludovic Courtès
2014-09-20 19:57 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-20 13:20 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> and is provided by a package called "sound-theme-freedesktop":
> https://packages.debian.org/unstable/main/sound-theme-freedesktop
OK, I’ve added that package.
> By the way, I'm using PulseAudio, but the current libcanberra package
> has no support for this option. Therefore, despite the fact that I'm
> using an external audio interface, the sound produced by
> canberra-gtk-play goes to the built-in speakers of my PC.
Fixed in 571a031.
And commit 0a9e9a6 switches Emacs to GTK+ 3.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-20 13:20 ` Ludovic Courtès
@ 2014-09-20 19:57 ` Federico Beffa
2014-09-20 20:28 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-20 19:57 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Sat, Sep 20, 2014 at 3:20 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> By the way, I'm using PulseAudio, but the current libcanberra package
>> has no support for this option. Therefore, despite the fact that I'm
>> using an external audio interface, the sound produced by
>> canberra-gtk-play goes to the built-in speakers of my PC.
>
> Fixed in 571a031.
>
Thanks! I now get sound from my external sound card.
> And commit 0a9e9a6 switches Emacs to GTK+ 3.
>
Unfortunately, I've found that if in a REPL buffer I select the Geiser menu:
Geiser -> Add to load path ...
emacs crashes :-(
So, maybe we should stick with gtk-2.
Sorry,
Fede
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-20 19:57 ` Federico Beffa
@ 2014-09-20 20:28 ` Ludovic Courtès
2014-09-20 22:02 ` Federico Beffa
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-20 20:28 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> Unfortunately, I've found that if in a REPL buffer I select the Geiser menu:
> Geiser -> Add to load path ...
> emacs crashes :-(
Could it be that it ends up dlopening something from the host distro?
Like gtk-module-foo.so? Could you get a backtrace with gdb?
I tried and everything seems to work well for me on the full Guix system.
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: emacs package
2014-09-20 20:28 ` Ludovic Courtès
@ 2014-09-20 22:02 ` Federico Beffa
2014-09-22 7:38 ` GSettings schemas Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2014-09-20 22:02 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Sat, Sep 20, 2014 at 10:28 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> Unfortunately, I've found that if in a REPL buffer I select the Geiser menu:
>> Geiser -> Add to load path ...
>> emacs crashes :-(
>
> Could it be that it ends up dlopening something from the host distro?
> Like gtk-module-foo.so? Could you get a backtrace with gdb?
I'm not familiar with gdb. Attached is what I captured with it after reading the
first few pages of the manual. I don't think it is using the distribution libs.
Let me know if I can capture more pieces of information.
Regards,
Fede
[-- Attachment #2: emacs-bt.log --]
[-- Type: text/x-log, Size: 5923 bytes --]
$ gdb emacs
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from emacs...(no debugging symbols found)...done.
(gdb) run
Starting program: /gnu/store/cyagv84azvl8rxawb93xli3ckqfc24s7-profile/bin/emacs
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19/lib/libthread_db.so.1".
Gtk-Message: Failed to load module "canberra-gtk-module"
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
[New Thread 0x7fffe69d3700 (LWP 33184)]
[New Thread 0x7fffe61d2700 (LWP 33185)]
[New Thread 0x7fffdffff700 (LWP 33186)]
[New Thread 0x7fffe59d1700 (LWP 33187)]
(emacs:33176): GLib-GIO-ERROR **: attempting to create schema 'org.gtk.Settings.FileChooser' without a path
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff4dfd0ba in g_logv () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff4dfd0ba in g_logv () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
#1 0x00007ffff4dfd212 in g_log () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
#2 0x00007ffff5f6af54 in g_settings_constructed () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgio-2.0.so.0
#3 0x00007ffff50f433a in g_object_new_internal () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#4 0x00007ffff50f6444 in g_object_new_valist () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#5 0x00007ffff50f6834 in g_object_new () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#6 0x00007ffff6830e9c in _gtk_file_chooser_get_settings_for_widget () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
#7 0x00007ffff6828130 in gtk_file_chooser_default_get_default_size () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
#8 0x00007ffff682eda4 in file_chooser_widget_default_size_changed () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
#9 0x00007ffff50ef3c8 in g_closure_invoke () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#10 0x00007ffff5100c9d in signal_emit_unlocked_R () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#11 0x00007ffff5108932 in g_signal_emit_valist () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#12 0x00007ffff510907d in g_signal_emit_by_name () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#13 0x00007ffff50ef3c8 in g_closure_invoke () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#14 0x00007ffff5100c9d in signal_emit_unlocked_R () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#15 0x00007ffff5108932 in g_signal_emit_valist () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#16 0x00007ffff510907d in g_signal_emit_by_name () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#17 0x00007ffff682d2a1 in gtk_file_chooser_default_set_property () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
#18 0x00007ffff50f7673 in g_object_set_property () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#19 0x00007ffff50f7673 in g_object_set_property () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#20 0x00007ffff50f44c5 in g_object_new_internal () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#21 0x00007ffff50f6444 in g_object_new_valist () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
#22 0x00007ffff50f6834 in g_object_new () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#23 0x00007ffff682f255 in gtk_file_chooser_dialog_new () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
#24 0x00000000004cc010 in xg_get_file_with_chooser ()
#25 0x00000000004d00ea in xg_get_file_name ()
#26 0x00000000004bd3f9 in Fx_file_dialog ()
#27 0x000000000054ce2e in Ffuncall ()
#28 0x000000000058126b in exec_byte_code ()
#29 0x000000000054ccfb in Ffuncall ()
#30 0x000000000058126b in exec_byte_code ()
#31 0x000000000054ccfb in Ffuncall ()
#32 0x000000000051265e in Fread_file_name ()
#33 0x0000000000549799 in Fcall_interactively ()
#34 0x000000000054ce5c in Ffuncall ()
#35 0x000000000054e794 in call3 ()
#36 0x00000000004ea1d9 in command_loop_1 ()
#37 0x000000000054b413 in internal_condition_case ()
#38 0x00000000004dba4e in command_loop_2 ()
#39 0x000000000054b2ee in internal_catch ()
#40 0x00000000004e00e7 in recursive_edit_1 ()
#41 0x00000000004e03e4 in Frecursive_edit ()
#42 0x00000000004171a5 in main ()
(gdb)
^ permalink raw reply [flat|nested] 3+ messages in thread
* GSettings schemas
2014-09-20 22:02 ` Federico Beffa
@ 2014-09-22 7:38 ` Ludovic Courtès
2014-09-23 18:39 ` Mark H Weaver
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2014-09-22 7:38 UTC (permalink / raw)
To: Federico Beffa; +Cc: guix-devel
Federico Beffa <beffa@ieee.org> skribis:
> (emacs:33176): GLib-GIO-ERROR **: attempting to create schema 'org.gtk.Settings.FileChooser' without a path
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff4dfd0ba in g_logv () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
> (gdb) bt
> #0 0x00007ffff4dfd0ba in g_logv () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
> #1 0x00007ffff4dfd212 in g_log () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
> #2 0x00007ffff5f6af54 in g_settings_constructed () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgio-2.0.so.0
> #3 0x00007ffff50f433a in g_object_new_internal () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
> #4 0x00007ffff50f6444 in g_object_new_valist () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
> #5 0x00007ffff50f6834 in g_object_new () from /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
> #6 0x00007ffff6830e9c in _gtk_file_chooser_get_settings_for_widget () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
> #7 0x00007ffff6828130 in gtk_file_chooser_default_get_default_size () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
> #8 0x00007ffff682eda4 in file_chooser_widget_default_size_changed () from /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
[...]
> #24 0x00000000004cc010 in xg_get_file_with_chooser ()
> #25 0x00000000004d00ea in xg_get_file_name ()
> #26 0x00000000004bd3f9 in Fx_file_dialog ()
I see, I can reproduce it by clicking on the “open file” icon.
> I've found that setting the environment variable GSETTINGS_SCHEMA_DIR
> solves the problem.
>
> $ GSETTINGS_SCHEMA_DIR=/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/share/glib-2.0/schemas emacs
>
> Can the schema location be fixed at configure/compile time?
We could use ‘wrap-program’ to set that variable for Emacs, but we need
to address that problem more generally.
This is actually a longstanding issue:
http://lists.gnu.org/archive/html/guix-devel/2013-10/msg00171.html
http://lists.gnu.org/archive/html/guix-devel/2013-10/msg00024.html
http://lists.gnu.org/archive/html/guix-devel/2013-11/msg00019.html
I would introduce a ‘glib-build-system’ that would have a post-install
phase to recompile the schemas visible to the package being built, and
wrap the binaries so GSETTINGS_SCHEMA_DIR refers to them.
I think that makes for a good project for this week-end’s hackathon.
Any volunteer? :-)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GSettings schemas
2014-09-22 7:38 ` GSettings schemas Ludovic Courtès
@ 2014-09-23 18:39 ` Mark H Weaver
0 siblings, 0 replies; 3+ messages in thread
From: Mark H Weaver @ 2014-09-23 18:39 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, Federico Beffa
ludo@gnu.org (Ludovic Courtès) writes:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> I've found that setting the environment variable GSETTINGS_SCHEMA_DIR
>> solves the problem.
>>
>> $ GSETTINGS_SCHEMA_DIR=/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/share/glib-2.0/schemas emacs
>>
>> Can the schema location be fixed at configure/compile time?
>
> We could use ‘wrap-program’ to set that variable for Emacs, but we need
> to address that problem more generally.
This 'wrap-program' strategy of setting environment variables before
running a program has problems. In this case, it means that every
program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value.
Along the same lines, I've noticed that when running WindowMaker, all of
the programs within my X session include a WindowMaker-specific
directory at the front of PATH.
It would be good to find another solution.
Mark
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-02-11 22:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-11 22:29 GSettings schemas Fabian Harfert
-- strict thread matches above, loose matches on Subject: below --
2014-09-13 13:13 emacs package Federico Beffa
2014-09-15 7:55 ` Ludovic Courtès
2014-09-16 7:38 ` Federico Beffa
2014-09-16 20:04 ` Federico Beffa
2014-09-17 9:11 ` Ludovic Courtès
2014-09-17 16:57 ` Federico Beffa
2014-09-18 12:01 ` Ludovic Courtès
2014-09-18 18:37 ` Federico Beffa
2014-09-19 7:54 ` Ludovic Courtès
2014-09-19 17:13 ` Federico Beffa
2014-09-20 13:20 ` Ludovic Courtès
2014-09-20 19:57 ` Federico Beffa
2014-09-20 20:28 ` Ludovic Courtès
2014-09-20 22:02 ` Federico Beffa
2014-09-22 7:38 ` GSettings schemas Ludovic Courtès
2014-09-23 18:39 ` Mark H Weaver
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.