emacs package

emacs package

[Federico Beffa]

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

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Federico Beffa]

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

Re: emacs package

[Federico Beffa]

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

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Federico Beffa]

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

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Federico Beffa]

[-- 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))))))

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Andreas Enge]

On Fri, Sep 19, 2014 at 09:54:18AM +0200, Ludovic Courtès wrote:
> Emacs switched back to GTK+ 2 in commit 8b0275b6, but I forgot why.
> Andreas, do you remember the reason?

This was the moment when I added gtk+-3, so all packages previously compiled
with gtk+ = gtk+-2 were now compiled with gtk+ = gtk+-3. I reverted a bunch
of packages to gtk+-2 since apparently there were build problems (which could
simply mean missing an appropriate configure flag, which I did not check).

So if emacs plays well with gtk+-3, it would be a good idea to upgrade.

Andreas

Re: emacs package

[Federico Beffa]

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

Re: emacs package

[Andreas Enge]

On Fri, Sep 19, 2014 at 07:13:26PM +0200, Federico Beffa wrote:
> I see that in guix there is a package for pulseaudio. Any particular
> reason for not enabling this sound framework option in libcanberra?

Probably none, except that the pulseaudio package was added after libcanberra.
So please feel free to create, test and submit a patch.

Andreas

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Federico Beffa]

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

Re: emacs package

[Ludovic Courtès]

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’.

Re: emacs package

[Federico Beffa]

[-- 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) 

Re: emacs package

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

ludo@gnu.org (Ludovic Courtès) skribis:

> And commit 0a9e9a6 switches Emacs to GTK+ 3.

Mark noted that GTK+ 3 fails to build on mips, because Xorg fails to
build.  Could you check whether the attached patch works around the
problem?  (Feel free to apply if it does.)

Thanks,
Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: the patch --]
[-- Type: text/x-patch, Size: 1193 bytes --]

From 9b85537591c1b859fb8bb5f155b200e56cdc42d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Sun, 21 Sep 2014 15:13:23 +0200
Subject: [PATCH] gnu: gtk+: Remove dependency on Xorg server on
 mips64el-linux.

Reported by Mark H. Weaver.

* gnu/packages/gtk.scm (gtk+)[native-inputs]: Remove XORG-SERVER on
  mips64el-linux.
---
 gnu/packages/gtk.scm | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 0a6499d..0cbd55d 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -404,7 +404,13 @@ application suites.")
       ("pkg-config" ,pkg-config)
       ("gobject-introspection" ,gobject-introspection)
       ("python-wrapper" ,python-wrapper)
-      ("xorg-server" ,xorg-server)))
+
+      ;; FIXME: The Xorg server is needed to run the tests, but it currently
+      ;; fails to build on mips64el, so remove it in the meantime.
+      ,@(if (string=? (or (%current-target-system) (%current-system))
+                      "mips64el-linux")
+            '()
+            `(("xorg-server" ,xorg-server)))))
    (arguments
     `(#:phases
       (alist-replace
-- 
1.8.4

Re: emacs package

[Federico Beffa]

On Sun, Sep 21, 2014 at 3:28 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> And commit 0a9e9a6 switches Emacs to GTK+ 3.
>
> Mark noted that GTK+ 3 fails to build on mips, because Xorg fails to
> build.  Could you check whether the attached patch works around the
> problem?  (Feel free to apply if it does.)
>

From this discussion
http://comments.gmane.org/gmane.comp.gnome.glade.devel/2302

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?

Regards,
Fede

GSettings schemas

[Ludovic Courtès]

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’.

Re: GSettings schemas

[Mark H Weaver]

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

wrap-program

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> 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.

I think whether using ‘wrap-program’ is a good strategy has to be
evaluated on a case-by-case basis.

In some cases it’s OK, in others (like wmaker), it’s not so nice.

In cases like wmaker, another solution would be to patch the source code
to execute directly the right binaries, without changing PATH.  The
downside is that it’s often less convenient to do.

Thanks,
Ludo’.

Re: wrap-program

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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.
>
> I think whether using ‘wrap-program’ is a good strategy has to be
> evaluated on a case-by-case basis.
>
> In some cases it’s OK, in others (like wmaker), it’s not so nice.
>
> In cases like wmaker, another solution would be to patch the source code
> to execute directly the right binaries, without changing PATH.  The
> downside is that it’s often less convenient to do.

I've looked some more into the problems I've found with the emacs
package:

1. GSettings schemas: More than schemas compilation, the problem is that
the schemas are by default expected to be in $datadir/glib-2.0/schemas
(with $datadir usually being /usr/share).  In spite of this, other
directories can be specified with the help of the environment variable
$XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
of future application installations, we may want to define

XDG_DATA_DIRS="$HOME/.guix-profile/share/:$XDG_DATA_DIRS".

If the variable $XDG_DATA_DIRS is not specified, it defaults to
/usr/local/share/:/usr/share/.

https://developer.gnome.org/gio/stable/ch32s06.html
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in
locations specified by

   a. $GTK_PATH,

   b. $libdir/gtk-3.0/modules, with $libdir being the one specified at
   gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib.

Option a. is inconvenient because that variable is used by both,
gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one
version to find incompatible libraries.

Option b. is more attractive.  Again, at compile time we do not know the
location of future modules installations: Take emacs: it looks in the
gtk+-3.0 directory $libdir/gtk-3.0/modules.  However, it is looking for
a module installed by libcanberra which is not even an input to the
emacs package.  For this reason we should probably define

GTK_EXE_PREFIX="$HOME/.guix-profile"

https://developer.gnome.org/gtk3/3.10/gtk-running.html
Note: the documentation at this site mentions the directory .gtk-3.0 in
$HOME.  However, strace on emacs and the README in the gtk-3.10.1 source
says that this path is no longer used.

Setting the above two variables eliminates both problems (libcanberra
and schemas not found) in the emacs package.  We could probably define
the above variables with 'wrap-program'.  In "guix on distro"
installations this would avoid having guix libraries interfere with a
non guix program.  On the other side, in a guix program launched from
within another guix program, this should be harmless.

We may just want to check that: (i) paths defined in environment
variables are not duplicated by 'wrap-program' definitions (wrap
launched by wrap) and (ii) if the variable is already defined (for "non
guix" reasons), we may want to append the existing value.

The only problem I see right now is if a program is launched by a user
which does not have $HOME/.guix-profile (like a service).  In that case
there could be a default profile.  This could also serve the second
purpose of providing initial default applications (like guix itself!) to
all users on "guix on distro" systems.  And on the gnu system, well,
there are system installed programs.

Regards,
Fede

Re: wrap-program

[Federico Beffa]

On Fri, Sep 26, 2014 at 10:09 PM, Federico Beffa <beffa@ieee.org> wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> 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.
>>
>> I think whether using ‘wrap-program’ is a good strategy has to be
>> evaluated on a case-by-case basis.
>>
>> In some cases it’s OK, in others (like wmaker), it’s not so nice.
>>
>> In cases like wmaker, another solution would be to patch the source code
>> to execute directly the right binaries, without changing PATH.  The
>> downside is that it’s often less convenient to do.
>
> I've looked some more into the problems I've found with the emacs
> package:
>
> 1. GSettings schemas: More than schemas compilation, the problem is that
> the schemas are by default expected to be in $datadir/glib-2.0/schemas
> (with $datadir usually being /usr/share).  In spite of this, other
> directories can be specified with the help of the environment variable
> $XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
> of future application installations, we may want to define
>
> XDG_DATA_DIRS="$HOME/.guix-profile/share/:$XDG_DATA_DIRS".
>
> If the variable $XDG_DATA_DIRS is not specified, it defaults to
> /usr/local/share/:/usr/share/.
>
> https://developer.gnome.org/gio/stable/ch32s06.html
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> 2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in
> locations specified by
>
>    a. $GTK_PATH,
>
>    b. $libdir/gtk-3.0/modules, with $libdir being the one specified at
>    gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib.
>
> Option a. is inconvenient because that variable is used by both,
> gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one
> version to find incompatible libraries.
>
> Option b. is more attractive.  Again, at compile time we do not know the
> location of future modules installations: Take emacs: it looks in the
> gtk+-3.0 directory $libdir/gtk-3.0/modules.  However, it is looking for
> a module installed by libcanberra which is not even an input to the
> emacs package.  For this reason we should probably define
>
> GTK_EXE_PREFIX="$HOME/.guix-profile"
>
> https://developer.gnome.org/gtk3/3.10/gtk-running.html
> Note: the documentation at this site mentions the directory .gtk-3.0 in
> $HOME.  However, strace on emacs and the README in the gtk-3.10.1 source
> says that this path is no longer used.
>
> Setting the above two variables eliminates both problems (libcanberra
> and schemas not found) in the emacs package.  We could probably define
> the above variables with 'wrap-program'.  In "guix on distro"
> installations this would avoid having guix libraries interfere with a
> non guix program.  On the other side, in a guix program launched from
> within another guix program, this should be harmless.
>
> We may just want to check that: (i) paths defined in environment
> variables are not duplicated by 'wrap-program' definitions (wrap
> launched by wrap) and (ii) if the variable is already defined (for "non
> guix" reasons), we may want to append the existing value.
>
> The only problem I see right now is if a program is launched by a user
> which does not have $HOME/.guix-profile (like a service).  In that case
> there could be a default profile.  This could also serve the second
> purpose of providing initial default applications (like guix itself!) to
> all users on "guix on distro" systems.  And on the gnu system, well,
> there are system installed programs.
>

I guess the above just breaks the functional approach to package
management...

So probably in the case of the emacs package we should just add
libcanberra to its inputs and set the full path in the environment
variables.

Fede

Re: wrap-program

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> 1. GSettings schemas: More than schemas compilation, the problem is that
> the schemas are by default expected to be in $datadir/glib-2.0/schemas
> (with $datadir usually being /usr/share).  In spite of this, other
> directories can be specified with the help of the environment variable
> $XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
> of future application installations, we may want to define

Right, that’s one of the reasons why the ‘glib’ package defines it as
its search path (see glib.scm.)

> 2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in
> locations specified by
>
>    a. $GTK_PATH,
>
>    b. $libdir/gtk-3.0/modules, with $libdir being the one specified at
>    gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib.
>
> Option a. is inconvenient because that variable is used by both,
> gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one
> version to find incompatible libraries.
>
> Option b. is more attractive.  Again, at compile time we do not know the
> location of future modules installations: Take emacs: it looks in the
> gtk+-3.0 directory $libdir/gtk-3.0/modules.  However, it is looking for
> a module installed by libcanberra which is not even an input to the
> emacs package.  For this reason we should probably define
>
> GTK_EXE_PREFIX="$HOME/.guix-profile"

That would be easy and could be defined in /etc/profile on the
standalone system.

However that would force users to install GTK+ in their profile so that
the modules it comes with are found, right?  This would be inconvenient.

> We may just want to check that: (i) paths defined in environment
> variables are not duplicated by 'wrap-program' definitions (wrap
> launched by wrap) and (ii) if the variable is already defined (for "non
> guix" reasons), we may want to append the existing value.

Yes, this is the preferred solution, I think (and I think it’s this case
it’s OK to have these two variables leak in sub-processes, as discussed
with Mark.)  However, we’d like to factorize the extra phase that does
the wrapping, so we don’t repeat it for each and every program.

> The only problem I see right now is if a program is launched by a user
> which does not have $HOME/.guix-profile (like a service).  In that case
> there could be a default profile.

I think these are mostly GUIs, unlikely to be launched by a service.

> This could also serve the second purpose of providing initial default
> applications (like guix itself!) to all users on "guix on distro"
> systems.

Hmm what do you mean?

Thanks,
Ludo’.

Re: wrap-program

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

> Federico Beffa <beffa@ieee.org> skribis:
>
>> 1. GSettings schemas: More than schemas compilation, the problem is that
>> the schemas are by default expected to be in $datadir/glib-2.0/schemas
>> (with $datadir usually being /usr/share).  In spite of this, other
>> directories can be specified with the help of the environment variable
>> $XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
>> of future application installations, we may want to define
>
> Right, that’s one of the reasons why the ‘glib’ package defines it as
> its search path (see glib.scm.)
>

I'm not sure I understand. Take emacs: the package does not have glib as
an input. However, it does have gtk+, which defines schemas in its own
tree ".../gtk+-3.10.1/share/glib-2.0/schemas" (and gtk+ is not an input
to glib). Therefore, having $XDG_DATA_DIRS in the glib package does not
help emacs. The emacs packge needs its own $XDG_DATA_DIRS pointing to
the gtk+ schemas.

>>
>> GTK_EXE_PREFIX="$HOME/.guix-profile"
>
> That would be easy and could be defined in /etc/profile on the
> standalone system.
>
> However that would force users to install GTK+ in their profile so that
> the modules it comes with are found, right?  This would be inconvenient.
>

Yes, so we should probably define $GTK_EXE_PREFIX in the emacs package
with the full path (/gnu/store/...) and not $HOME/.... And given that
the gtk+ module is provided by libcanberra, the latter should be an
input to emacs as well.

> Yes, this is the preferred solution, I think (and I think it’s this case
> it’s OK to have these two variables leak in sub-processes, as discussed
> with Mark.)  However, we’d like to factorize the extra phase that does
> the wrapping, so we don’t repeat it for each and every program.
>

Since I'm new to glib schemas and gtk modules, I'm trying to
understand the correct broadest approach before doing anything.

> I think these are mostly GUIs, unlikely to be launched by a service.
>

I was thinking about windows managers and desktops. Not sure they really
need this.

>> This could also serve the second purpose of providing initial default
>> applications (like guix itself!) to all users on "guix on distro"
>> systems.
>
> Hmm what do you mean?
>

I was thinking about a convenient mechanism for providing packages
visible to all users of a system.

Regards,
Fede

Re: wrap-program

[Andreas Enge]

Hello,

I am only now catching up with the discussion. So far, I do not understand
why we need a wrapper. Would it not be enough to add the environment variables
$XDG_DATA_DIRS etc. to the search paths of the programs, in the same way as
perl or python modules incite the user to define the corresponding environment
variables pointing to a subdirectory of .guix-profile?

For instance, I have the following in my .bashrc:
export PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages:$HOME/.guix-profile/lib/python3.3/site-packages

And I already have
export XDG_DATA_DIRS=$HOME/.guix-profile/share
This one was just good to have and, if I remember correctly, not suggested
when installing some package, but it could be added to the packages needing it.

Andreas

Re: wrap-program

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> I am only now catching up with the discussion. So far, I do not understand
> why we need a wrapper. Would it not be enough to add the environment variables
> $XDG_DATA_DIRS etc. to the search paths of the programs, in the same way as
> perl or python modules incite the user to define the corresponding environment
> variables pointing to a subdirectory of .guix-profile?

There are several things to consider.  First, it’s better if things work
out of the box.

Second, sometimes, we may want to trade dynamicity for reproducibility
(and “referential transparency.”)  In the case of GTK+ plug-ins, if we
force GTK_EXE_PREFIX in a wrapper, then we make sure the application is
using the “right” plug-ins, at the cost of making the system more
static.  For schemas, having XDG_DATA_DIRS defined in a wrapper would
just make sure that the application actually works (otherwise it could
end up using the wrong schemas, I suppose.)

My 2¢,
Ludo’.