On Mon, Sep 11, 2006 at 10:18:03PM +0200, Robert Millan wrote:
Thanks for the ellaboration. This sounds like a strange race, though. It
would require the user to launch the client before the server has finished its
startup, which AFAICT can only be done from a shell that doesn't belong to
On Mon, Sep 11, 2006, Robert Millan wrote:
Thanks for the ellaboration. This sounds like a strange race, though. It
would require the user to launch the client before the server has finished its
startup, which AFAICT can only be done from a shell that doesn't belong to
this server session.
On Tue, Sep 12, 2006 at 10:23:15AM +0200, Loïc Minier wrote:
On Mon, Sep 11, 2006, Robert Millan wrote:
Thanks for the ellaboration. This sounds like a strange race, though. It
would require the user to launch the client before the server has finished
its
startup, which AFAICT can only
On Tue, Sep 12, 2006, Robert Millan wrote:
My opinion is that whoever creates the environment variable which lists
the socket should make sure the socket is available before spreading
the news,
It did, and at that time the socket was present. It's just that the socket
is not there
On Tue, Sep 12, 2006 at 07:09:36PM +0200, Loïc Minier wrote:
On Tue, Sep 12, 2006, Robert Millan wrote:
My opinion is that whoever creates the environment variable which lists
the socket should make sure the socket is available before spreading
the news,
It did, and at that time the
reassign 385976 libice6
retitle 385976 SocketUNIXConnect shouldn't return TRANS_TRY_CONNECT_AGAIN when
the socket file doesn't exist
severity 385976 minor
stop
Hi,
On Sun, Sep 10, 2006, Robert Millan wrote:
Interesting... it turns out my shell's $SESSION_MANAGER is pointing to
a
On Mon, Sep 11, 2006 at 04:19:57PM +0200, Loïc Minier wrote:
reassign 385976 libice6
retitle 385976 SocketUNIXConnect shouldn't return TRANS_TRY_CONNECT_AGAIN
when the socket file doesn't exist
severity 385976 minor
stop
Hi,
On Sun, Sep 10, 2006, Robert Millan wrote:
Hi,
I made some tests on my system, and I don't experience any delay
*except* in a broken configuration.
(all tests are done from a GNOME session, I'm only hiding the session
manager)
1) normal GNOME use case with session,
SESSION_MANAGER=local/bee:/tmp/.ICE-unix/5243 gcalctool
=
On Sun, Sep 10, 2006 at 10:34:24PM +0200, Loïc Minier wrote:
4) very broken SESSION_MANAGER (bad value),
SESSION_MANAGER=local/bee:/tmp/.ICE-unix/0 gcalctool
= DELAY, tries to connect and fail
Could you please report the value of SESSION_MANAGER? (env | grep
SESSION_MANAGER)
Package: gcalctool
Version: 5.8.20-1
Severity: normal
Each time gcalctool starts on my system it sleeps for ~4s, with
apparently no purpose (I can't imagine anything that would justify this
for a lightweight program like this one). Here's a backtrace:
(gdb) bt
#0 0x2b8010380e22 in
On Mon, Sep 04, 2006 at 04:52:53PM +0200, Loïc Minier wrote:
Hi,
On Mon, Sep 04, 2006, Robert Millan wrote:
Each time gcalctool starts on my system it sleeps for ~4s, with
apparently no purpose (I can't imagine anything that would justify this
for a lightweight program like this
Hi,
On Mon, Sep 04, 2006, Robert Millan wrote:
Each time gcalctool starts on my system it sleeps for ~4s, with
apparently no purpose (I can't imagine anything that would justify this
for a lightweight program like this one). Here's a backtrace:
#4 0x2b800f2e76d3 in
12 matches
Mail list logo
