emacs on 13.1

When I run the SuSE-provided emacs I get messages such as

** (emacs-gtk:29360): WARNING **: Couldn’t connect to accessibility bus: Failed to connect to socket /tmp/dbus-f4RYmGbWR4: Connection refused
Activating service name=‘org.gtk.vfs.Daemon’
Successfully activated service ‘org.gtk.vfs.Daemon’
Activating service name=‘org.gnome.GConf’
Successfully activated service ‘org.gnome.GConf’

(emacs-gtk:29360): Pango-WARNING **: /usr/lib/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory
crontab: installing new crontab
A connection to the bus can’t be made
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

whch do not happen with my self-built emacs. What is this about?

As ever I run without Gnome or KDE, using fvwm as Window manager. The example above was while ssh’ed in from a similar system.

On 2014-03-04, jpff <jpff@no-mx.forums.opensuse.org> wrote:
>
> When I run the SuSE-provided emacs I get messages such as
>
<SNIP>
> whch do not happen with my self-built emacs. What is this about?
>
> As ever I run without Gnome or KDE, using fvwm as Window manager. The
> example above was while ssh’ed in from a similar system.

I run emacs from openSUSE 13.1 KDE with no problems. With your those GTK errors, my first suggestion is to check…


sh-4.2$ which emacs

…actually maps to /usr/bin/emacs. If it does, can you run emacs from a virtual terminal?

yes which emacs is /usr/bin/emacs

I can run emacs from an xterm but I get these irritating warnings.
Does not happen when I build emacs from sources.

I repeat I am not running gnome nor kde – no icons and no micros**t lookalikes as I have been goinf for 30 years

I installed 13.1 on my server system last week and am seeing similar issues. I confirmed that which emacs gives /usr/bin/emacs so I’m using the standard emacs provided with 13.1.

I normally connect to the server using:

ssh -f -X -Y <servername> /usr/bin/xterm -bg \#ddffdd

When I then start emacs in the xterm window, it gives the following output before the emacs window pops up:

Activating service name='org.gtk.vfs.Daemon'
Successfully activated service 'org.gtk.vfs.Daemon'
Activating service name='org.gnome.GConf'
Successfully activated service 'org.gnome.GConf'

and when I close emacs I get:

A connection to the bus can't be made
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

Needless to say I never got these messages when I was running OpenSUSE 12.2 or 12.3 and connecting in the same way.

I always run the command:

for f in $(dbus-launch); do echo $f; export $f; done

before I start emacs or any other dbus using application (some of them won’t even work without it.)

On 2014-03-29 13:36, egrivel498 wrote:
>
> I installed 13.1 on my server system last week and am seeing similar
> issues. I confirmed that which emacs gives /usr/bin/emacs so I’m
> using the standard emacs provided with 13.1.

I have an old laptop with LXDE installed. I just installed emacs to try
this out, and yes, I do get several messages in the terminal, but the
program itself works fine. This is typical of many applications when
used via ssh, possibly because they are now designed to integrate with
powerful and complex desktops such as gnome and kde.


cer@AmonLanc:~> emacs p

** (emacs-gtk:11470): WARNING **: Couldn't connect to accessibility bus:
Failed to connect to socket /tmp/dbus-3hoaMf2FTs: Connection refused
Activating service name='org.gtk.vfs.Daemon'
Successfully activated service 'org.gtk.vfs.Daemon'
Activating service name='org.gnome.GConf'
Successfully activated service 'org.gnome.GConf'

A connection to the bus can't be made
g_dbus_connection_real_closed: Remote peer vanished with error:
Underlying GIOStream returned 0 bytes on an async read
(g-io-error-quark, 0). Exiting.
cer@AmonLanc:~>
cer@AmonLanc:~>

I installed:


emacs-x11-24.3-6.10.1.i586                    2014-03-29T15:25:29 CET
emacs-24.3-6.10.1.i586                        2014-03-29T15:25:19 CET
etags-24.3-6.10.1.i586                        2014-03-29T15:24:50 CET
emacs-info-24.3-6.10.1.noarch                 2014-03-29T15:24:49 CET
libm17n0-1.6.4-2.1.2.i586                     2014-03-29T15:24:47 CET
libotf0-0.9.13-2.1.2.i586                     2014-03-29T15:24:45 CET
m17n-db-1.6.4-2.1.2.noarch                    2014-03-29T15:22:39 CET

Now I will instead “xemacs” instead (removing all the above first). It
wanted these packages:


xemacs-21.5.34-2.1.4.i586                     Sat Mar 29 15:45:02 2014
ctags-5.8-2.1.2.i586                          Sat Mar 29 15:44:55 2014
xemacs-info-21.5.34-2.1.4.noarch              Sat Mar 29 15:44:51 2014
fwnn-1.1.1a022-29.1.4.i586                    Sat Mar 29 15:44:49 2014
xemacs-packages-info-20130822-2.1.4.noarch    Sat Mar 29 15:44:47 2014
xemacs-packages-20130822-2.1.4.noarch         Sat Mar 29 15:44:40 2014
fwnncom-1.1.1a022-29.1.4.i586                 Sat Mar 29 15:44:21 2014
canna-libs-3.7p3-229.1.3.i586                 Sat Mar 29 15:44:18 2014

It works silently:


cer@AmonLanc:~> xemacs p
Warning: Missing charsets in String to FontSet conversion
cer@AmonLanc:~>

But the interface is very “old style”.

And now I removed all of that, I’m not going to use any emacs in that
machine :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I tried this, and it does seem to help. My question is, why? And why is this necessary when I remote into the machine (the problem doesn’t seem to appear when I directly log into the system)?

Eric

That’s because a dbus session is already running for every process started from your desktop login:

markgray@quad:~> set |grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-JJxJ8kRa7M,guid=318d71555c8df0a0e30a15a1532459f0
KONSOLE_DBUS_SERVICE=:1.48
KONSOLE_DBUS_SESSION=/Sessions/15
markgray@quad:~>