gmane.emacs.jabber.bugs

[ emacs-jabber-Bugs-3527994 ] Problems with native gnutls

SourceForge.net — 2012-05-19T14:44:41

Bugs item #3527994, was opened at 2012-05-18 11:17
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3527994&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with native gnutls

Initial Comment:
Ever since

commit f54c1b54b308f38caac66ae567e5f64f6adc631c
Author: Magnus Henoch <legoscia< at >users.sourceforge.net>
Date:   Tue May 15 22:39:43 2012 +0100

    Support native GnuTLS for STARTTLS
    [..]

I've found myself unable to connect to lavabit.com using starttls. Here's what I found in my message buffer:

gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.
gnutls.el: (err=[-110] The TLS connection was non-properly terminated.) boot: (:priority NORMAL :hostname lavabit.com :loglevel 0 :min-prime-bits nil :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :verify-hostname-error t :callbacks nil)
gnutls.c: [0] (Emacs) fatal error: The specified session has been invalidated for some reason. [100 times]
ME< at >lavabit.com/nil: connection lost: `connection broken by remote peer
'

(where i replaced my username with ME)

Here's the relevant part of my config:

(setq jabber-account-list '(("ME< at >lavabit.com"
     (:password . "PASSWORD")
     (:network-server . "lavabit.com")
     (:connection-type . starttls)
     (:port . 5222)))

----------------------------------------------------------------------

Date: 2012-05-19 07:44

Message:
After

commit 1dca591d17cf084e6d870f55898e9343926f8bb8
Author: Magnus Henoch <magnus.henoch< at >gmail.com>
Date:   Sat May 19 15:01:05 2012 +0100

    Fix reporting of STARTTLS negotiation errors [..]

My message buffer looks like this:

Sat May 19 16:40:07 2012: Starting jabber-connection
Sat May 19 16:40:07 2012: jabber-connection enters :connecting
Sat May 19 16:40:07 2012: Found enter function for :connecting: #[(fsm
state-data) "\306\307\"\310!\306\311\"\306\312\"\306\313\"


$\210-\314D\207" [state-data connection-type connect-function server
network-server port plist-get :connection-type jabber-get-connect-function
:server :network-server :port nil fsm] 5]
Sat May 19 16:40:07 2012: Using data from enter function
Sat May 19 16:40:07 2012: Sent :connected to jabber-connection in state
:connecting
Sat May 19 16:40:07 2012: jabber-connection enters :connected
Sat May 19 16:40:07 2012: Found enter function for :connected: #[(fsm
state-data) "\303!\210\304
\305D\207" [fsm *jabber-connected* state-data jabber-send-stream-header t
nil] 2]
Sat May 19 16:40:07 2012: Using data from enter function
Sat May 19 16:40:07 2012: Sent :filter to jabber-connection in state
:connected
Sat May 19 16:40:07 2012: Sent :stream-start to jabber-connection in state
:connected
Sat May 19 16:40:08 2012: Sent :filter to jabber-connection in state
:connected
Sat May 19 16:40:08 2012: Sent :stanza to jabber-connection in state
:connected
Sat May 19 16:40:08 2012: jabber-connection enters :starttls
Sat May 19 16:40:08 2012: Found enter function for :starttls: #[(fsm
state-data) "\302!\210\303D\207" [fsm state-data jabber-starttls-initiate
nil] 2]
Sat May 19 16:40:08 2012: Using data from enter function
Sat May 19 16:40:08 2012: Sent :filter to jabber-connection in state
:starttls
Sat May 19 16:40:08 2012: Sent :stanza to jabber-connection in state
:starttls
Sat May 19 16:40:08 2012: jabber-connection enters nil
Sat May 19 16:40:08 2012: Found enter function for nil: #[(fsm state-data)
"\306\307\"\310!\203\"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3527994&group_id=88346

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[ emacs-jabber-Bugs-3527994 ] Problems with native gnutls

SourceForge.net — 2012-05-18T18:17:42

Bugs item #3527994, was opened at 2012-05-18 11:17
Message generated for change (Tracker Item Submitted) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3527994&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with native gnutls

Initial Comment:
Ever since

commit f54c1b54b308f38caac66ae567e5f64f6adc631c
Author: Magnus Henoch <legoscia< at >users.sourceforge.net>
Date:   Tue May 15 22:39:43 2012 +0100

    Support native GnuTLS for STARTTLS
    [..]

I've found myself unable to connect to lavabit.com using starttls. Here's what I found in my message buffer:

gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.
gnutls.el: (err=[-110] The TLS connection was non-properly terminated.) boot: (:priority NORMAL :hostname lavabit.com :loglevel 0 :min-prime-bits nil :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :verify-hostname-error t :callbacks nil)
gnutls.c: [0] (Emacs) fatal error: The specified session has been invalidated for some reason. [100 times]
ME< at >lavabit.com/nil: connection lost: `connection broken by remote peer
'

(where i replaced my username with ME)

Here's the relevant part of my config:

(setq jabber-account-list '(("ME< at >lavabit.com"
     (:password . "PASSWORD")
     (:network-server . "lavabit.com")
     (:connection-type . starttls)
     (:port . 5222)))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3527994&group_id=88346

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[ emacs-jabber-Feature Requests-3518686 ] Use emacs 24 builtinsupport for GnuTLS

SourceForge.net — 2012-05-15T21:48:32

Feature Requests item #3518686, was opened at 2012-04-17 00:39
Message generated for change (Settings changed) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586353&aid=3518686&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Git
Status: Open
Priority: 5
Private: No
Submitted By: Kai Tetzlaff (kate21)
Summary: Use emacs 24 builtin support for GnuTLS

Initial Comment:
SSL/TLS connections are currently established using external programs (gnutls-cli, starrtls) which does not work very well in Windows. Emacs 24 supports direct use of the GnuTLS as a shared library. It would be great if (optional) support for this could be added to jabber.el.

----------------------------------------------------------------------

Date: 2012-05-15 14:48

Message:
Just committed a change that tries to do this. Let me know how it works :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586353&aid=3518686&group_id=88346

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[ emacs-jabber-Feature Requests-3518686 ] Use emacs 24 builtinsupport for GnuTLS

SourceForge.net — 2012-04-17T07:39:34

Feature Requests item #3518686, was opened at 2012-04-17 00:39
Message generated for change (Tracker Item Submitted) made by kate21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586353&aid=3518686&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Git
Status: Open
Priority: 5
Private: No
Submitted By: Kai Tetzlaff (kate21)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use emacs 24 builtin support for GnuTLS

Initial Comment:
SSL/TLS connections are currently established using external programs (gnutls-cli, starrtls) which does not work very well in Windows. Emacs 24 supports direct use of the GnuTLS as a shared library. It would be great if (optional) support for this could be added to jabber.el.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586353&aid=3518686&group_id=88346

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

[ emacs-jabber-Bugs-3515650 ] dist-lzma is deprecated and makesautomake-1.11.4 fail

SourceForge.net — 2012-04-12T16:07:59

Bugs item #3515650, was opened at 2012-04-07 01:47
Message generated for change (Comment added) made by evg_krsk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3515650&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Private: No
Submitted By: Elias Pipping (pipping)
Summary: dist-lzma is deprecated and makes automake-1.11.4 fail

Initial Comment:
I'm attaching a patch that replaces dist-lzma with dist-xz.

Without that patch:

% autoreconf; echo $?
configure.ac:23: warning: macro `AM_GCONF_SOURCE_2' not found in library
configure.ac:3: lzma compression is deprecated; use `dist-xz' or `dist-lzip' instead
autoreconf-2.68: automake failed with exit status: 1
1
%

With that patch:

% autoreconf; echo $?
configure.ac:23: warning: macro `AM_GCONF_SOURCE_2' not found in library
0
%

----------------------------------------------------------------------

Date: 2012-04-12 09:07

Message:
Applied, thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3515650&group_id=88346

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[ emacs-jabber-Bugs-3515650 ] dist-lzma is deprecated and makesautomake-1.11.4 fail

SourceForge.net — 2012-04-07T08:47:19

Bugs item #3515650, was opened at 2012-04-07 01:47
Message generated for change (Tracker Item Submitted) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3515650&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Nobody/Anonymous (nobody)
Summary: dist-lzma is deprecated and makes automake-1.11.4 fail

Initial Comment:
I'm attaching a patch that replaces dist-lzma with dist-xz.

Without that patch:

% autoreconf; echo $?
configure.ac:23: warning: macro `AM_GCONF_SOURCE_2' not found in library
configure.ac:3: lzma compression is deprecated; use `dist-xz' or `dist-lzip' instead
autoreconf-2.68: automake failed with exit status: 1
1
%

With that patch:

% autoreconf; echo $?
configure.ac:23: warning: macro `AM_GCONF_SOURCE_2' not found in library
0
%

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3515650&group_id=88346

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-03-23T06:36:58

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by evg_krsk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-03-22 23:36

Message:
2 lufu:
http://emacs-jabber.git.sourceforge.net/git/gitweb.cgi?p=emacs-jabber/emacs-jabber;a=patch;h=7c3e8e98ce458539efe2dd30b3051fbbed06cd01

----------------------------------------------------------------------

Comment By: Lukas Fuernkranz (lufu)
Date: 2012-03-21 09:49

Message:
I'm affected as well by this annoyance, however I don't get where I can
download the patch and how to apply it... tia and sorry for the silly
question.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-06 12:43

Message:
This change isn't in 0.8.91, right?

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-06 12:41

Message:
That appears to fix it, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-06 10:09

Message:
Right, that's the behaviour you'd get from ejabberd with mod_disco
disabled.

I just pushed a fix to git. Could you try it? It's a small change to
jabber-roster.el.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-03-21T16:49:48

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by lufu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Comment By: Lukas Fuernkranz (lufu)
Date: 2012-03-21 09:49

Message:
I'm affected as well by this annoyance, however I don't get where I can
download the patch and how to apply it... tia and sorry for the silly
question.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-06 12:43

Message:
This change isn't in 0.8.91, right?

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-06 12:41

Message:
That appears to fix it, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-06 10:09

Message:
Right, that's the behaviour you'd get from ejabberd with mod_disco
disabled.

I just pushed a fix to git. Could you try it? It's a small change to
jabber-roster.el.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-06T20:43:09

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-06 12:43

Message:
This change isn't in 0.8.91, right?

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-06 12:41

Message:
That appears to fix it, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-06 10:09

Message:
Right, that's the behaviour you'd get from ejabberd with mod_disco
disabled.

I just pushed a fix to git. Could you try it? It's a small change to
jabber-roster.el.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-06T20:41:12

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-06 12:41

Message:
That appears to fix it, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-06 10:09

Message:
Right, that's the behaviour you'd get from ejabberd with mod_disco
disabled.

I just pushed a fix to git. Could you try it? It's a small change to
jabber-roster.el.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3395895 ] emacs-jabber 0.8.90 breaks connectionsto lavabit.com

SourceForge.net — 2012-02-06T18:11:20

Bugs item #3395895, was opened at 2011-08-21 14:31
Message generated for change (Comment added) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: emacs-jabber 0.8.90 breaks connections to lavabit.com

Initial Comment:
Using a googlemail account of the form

(setq jabber-account-list '(("user< at >googlemail.com"
     (:password . "password")
     (:network-server . "talk.google.com")
     (:connection-type . ssl))))

works for me with emacs-jabber 0.8.90. Using a lavabit.com account of the form


(setq jabber-account-list '(("user< at >lavabit.com"
     (:password . "password.")
     (:network-server . "lavabit.com")
     (:connection-type . ssl)
     (:port . 5223))))

does not. It did with 0.8.0, though. Here's what happens:

Opening TLS connection to `lavabit.com'...
Opening TLS connection with `gnutls-cli -p 5223 lavabit.com'...done
Opening TLS connection to `lavabit.com'...done
user< at >lavabit.com/nil: connection lost: `Unexpected stanza (features ((xmlns . http://etherx.jabber.org/streams) (xmlns:stream . http://etherx.jabber.org/streams)) (compression ((xmlns . http://jabber.org/features/compress)) (method nil zlib)) (address ((xmlns . http://affinix.com/jabber/address)) 91.65.137.66) (auth ((xmlns . http://jabber.org/features/iq-auth))))'


----------------------------------------------------------------------

Date: 2012-02-06 10:11

Message:
Both the original problem and the test failure should be solved in 0.8.91.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2011-12-21 15:28

Message:
Well, the good news is that my lavabit account continues to work.

There's a test failure, though:

romeo< at >montague.net/nil: connection lost: `Unexpected stanza
(stream:features nil (mechanisms ((xmlns .
urn:ietf:params:xml:ns:xmpp-sasl)) (mechanism nil DIGEST-MD5)) (bind
((xmlns . urn:ietf:params:xml:ns:xmpp-bind))) (session ((xmlns .
urn:ietf:params:xml:ns:xmpp-session))))'
Timeout
FAIL: nick-change-fail.el

And the error looks like it's related.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2011-12-21 14:44

Message:
Finally got time to do it the proper way :)

Could you try the change I just pushed to Git? I believe it should work
with both Google Talk and lavabit.com.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2011-08-21 23:34

Message:
That makes it work again for me, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2011-08-21 16:04

Message:
Right, I think I see what's going on.  The <stream:features> element has an
xmlns attribute for the stream prefix, so the namespace tree walker removes
the stream: prefix from the element, which confuses other parts of
jabber-core.

Could you try the attached patch?  I'll try to get a nicer version into the
tree during the coming week.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-06T18:09:57

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-06 10:09

Message:
Right, that's the behaviour you'd get from ejabberd with mod_disco
disabled.

I just pushed a fix to git. Could you try it? It's a small change to
jabber-roster.el.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-05T12:38:57

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-05 04:38

Message:
(since i didn't get a mail that notified me of the attachment i just added,
i'm making it explicit here)

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-05T12:37:09

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-05 04:37

Message:
they don't seem too eager to tell anyone anything.

there's a good chance they're running ejabberd, though.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-05T09:57:15

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-05 01:57

Message:
Right, I found the problem. In jabber-roster-ret-action-at-point, we try to
DTRT, i.e. open a chat buffer if the roster item is a contact and a
groupchat buffer if the roster item is a chatroom. Normally, jabber.el will
refuse to open a groupchat buffer if the JID is not a chatroom (as
determined by disco), but your contact's server returns a
feature-not-implemented error in response to the disco info request. Since
at least one MUC server actually does that (ejabberd's mod_irc), jabber.el
will give it the benefit of the doubt and open a groupchat buffer
anyway...

So... the right answer is probably to make RET in a roster buffer open a
groupchat only if the JID actually says it's a groupchat, disabling the
feature-not-implemented hack for this case, so you'd have to join
non-compliant rooms with an explicit M-x jabber-muc-join.

Out of interest, could you check what server this is? I.e. M-x
jabber-get-version or M-x jabber-get-disco-info on HIS_HOST.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-03T17:51:58

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-03 09:51

Message:
I replaced the:
 * name and host of that contact with HIS_NAME< at >HIS_HOST,
 * my name and host with MY_NAME< at >MY_HOST, and
 * my IP with MY_IP
 * my password with PASSWORD
in the log. I also stripped all messages related to other contacts. The
result is attached;

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-03T16:39:44

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Comment added) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

Date: 2012-02-03 08:39

Message:
Sounds like an incoming message is incorrectly treated as a groupchat
message. Could you set jabber-debug-log-xml to t and paste messages from
that contact here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

[ emacs-jabber-Bugs-3483380 ] groupchat buffer keeps popping up

SourceForge.net — 2012-02-02T22:36:38

Bugs item #3483380, was opened at 2012-02-02 14:36
Message generated for change (Tracker Item Submitted) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Nobody/Anonymous (nobody)
Summary: groupchat buffer keeps popping up

Initial Comment:
With the current git HEAD, for at least one of my jabber contacts, an unrequested group chat buffer will appear almost immediately after I open a regular buffer for that contact. if i close the groupchat buffer, it will not reappear as long as the regular buffer stays open. If I delete the regular buffer and open create it anew, the groupchat buffer reappears, too. The problem is reproducible for that contact. version 0.8.0 does not have it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3483380&group_id=88346

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

[ emacs-jabber-Bugs-3395895 ] emacs-jabber 0.8.90 breaks connectionsto lavabit.com

SourceForge.net — 2011-12-21T23:28:30

Bugs item #3395895, was opened at 2011-08-21 14:31
Message generated for change (Comment added) made by pipping
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Assigned to: Magnus Henoch (legoscia)
Summary: emacs-jabber 0.8.90 breaks connections to lavabit.com

Initial Comment:
Using a googlemail account of the form

(setq jabber-account-list '(("user< at >googlemail.com"
     (:password . "password")
     (:network-server . "talk.google.com")
     (:connection-type . ssl))))

works for me with emacs-jabber 0.8.90. Using a lavabit.com account of the form


(setq jabber-account-list '(("user< at >lavabit.com"
     (:password . "password.")
     (:network-server . "lavabit.com")
     (:connection-type . ssl)
     (:port . 5223))))

does not. It did with 0.8.0, though. Here's what happens:

Opening TLS connection to `lavabit.com'...
Opening TLS connection with `gnutls-cli -p 5223 lavabit.com'...done
Opening TLS connection to `lavabit.com'...done
user< at >lavabit.com/nil: connection lost: `Unexpected stanza (features ((xmlns . http://etherx.jabber.org/streams) (xmlns:stream . http://etherx.jabber.org/streams)) (compression ((xmlns . http://jabber.org/features/compress)) (method nil zlib)) (address ((xmlns . http://affinix.com/jabber/address)) 91.65.137.66) (auth ((xmlns . http://jabber.org/features/iq-auth))))'


----------------------------------------------------------------------

Date: 2011-12-21 15:28

Message:
Well, the good news is that my lavabit account continues to work.

There's a test failure, though:

romeo< at >montague.net/nil: connection lost: `Unexpected stanza
(stream:features nil (mechanisms ((xmlns .
urn:ietf:params:xml:ns:xmpp-sasl)) (mechanism nil DIGEST-MD5)) (bind
((xmlns . urn:ietf:params:xml:ns:xmpp-bind))) (session ((xmlns .
urn:ietf:params:xml:ns:xmpp-session))))'
Timeout
FAIL: nick-change-fail.el

And the error looks like it's related.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2011-12-21 14:44

Message:
Finally got time to do it the proper way :)

Could you try the change I just pushed to Git? I believe it should work
with both Google Talk and lavabit.com.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2011-08-21 23:34

Message:
That makes it work again for me, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2011-08-21 16:04

Message:
Right, I think I see what's going on.  The <stream:features> element has an
xmlns attribute for the stream prefix, so the namespace tree walker removes
the stream: prefix from the element, which confuses other parts of
jabber-core.

Could you try the attached patch?  I'll try to get a nicer version into the
tree during the coming week.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

[ emacs-jabber-Bugs-3395895 ] emacs-jabber 0.8.90 breaks connectionsto lavabit.com

SourceForge.net — 2011-12-21T22:44:26

Bugs item #3395895, was opened at 2011-08-21 14:31
Message generated for change (Comment added) made by legoscia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elias Pipping (pipping)
Summary: emacs-jabber 0.8.90 breaks connections to lavabit.com

Initial Comment:
Using a googlemail account of the form

(setq jabber-account-list '(("user< at >googlemail.com"
     (:password . "password")
     (:network-server . "talk.google.com")
     (:connection-type . ssl))))

works for me with emacs-jabber 0.8.90. Using a lavabit.com account of the form


(setq jabber-account-list '(("user< at >lavabit.com"
     (:password . "password.")
     (:network-server . "lavabit.com")
     (:connection-type . ssl)
     (:port . 5223))))

does not. It did with 0.8.0, though. Here's what happens:

Opening TLS connection to `lavabit.com'...
Opening TLS connection with `gnutls-cli -p 5223 lavabit.com'...done
Opening TLS connection to `lavabit.com'...done
user< at >lavabit.com/nil: connection lost: `Unexpected stanza (features ((xmlns . http://etherx.jabber.org/streams) (xmlns:stream . http://etherx.jabber.org/streams)) (compression ((xmlns . http://jabber.org/features/compress)) (method nil zlib)) (address ((xmlns . http://affinix.com/jabber/address)) 91.65.137.66) (auth ((xmlns . http://jabber.org/features/iq-auth))))'


----------------------------------------------------------------------

Date: 2011-12-21 14:44

Message:
Finally got time to do it the proper way :)

Could you try the change I just pushed to Git? I believe it should work
with both Google Talk and lavabit.com.

----------------------------------------------------------------------

Comment By: Elias Pipping (pipping)
Date: 2011-08-21 23:34

Message:
That makes it work again for me, thanks.

----------------------------------------------------------------------

Comment By: Magnus Henoch (legoscia)
Date: 2011-08-21 16:04

Message:
Right, I think I see what's going on.  The <stream:features> element has an
xmlns attribute for the stream prefix, so the namespace tree walker removes
the stream: prefix from the element, which confuses other parts of
jabber-core.

Could you try the attached patch?  I'll try to get a nicer version into the
tree during the coming week.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3395895&group_id=88346

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

[ emacs-jabber-Bugs-3173458 ] jabber connection fails randomly

SourceForge.net — 2011-12-07T17:55:31

Bugs item #3173458, was opened at 2011-02-05 04:59
Message generated for change (Comment added) made by nze
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3173458&group_id=88346

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Connectivity
Group: v0.8
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: jabber connection fails randomly

Initial Comment:
Initial connection to jabber server (jabber.ru) fails with this message:

Opening STARTTLS connection to `jabber.ru:5222'...done
Authentication succeeded
m1st< at >jabber.ru/emacs: connection lost: `exited abnormally with code 1

or

Opening STARTTLS connection to `jabber.ru:5222'...done
m1st< at >jabber.ru/nil: connection lost: `exited abnormally with code 1
'
STARTTLS negotiation failed: ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
 [2 times]
STARTTLS negotiation failed

----------------------------------------------------------------------

Comment By: pgh (nze)
Date: 2011-12-07 09:55

Message:
Is jabber.el actually still being actively developed?

I can only connect to my prosody server after giving it like 15 tries:

Opening STARTTLS connection to `example.org:5222'...done
jabber-xml-resolve-namespace-prefixes: Unknown prefix in stream:features [2
times]
Authentication succeeded
jabber-xml-resolve-namespace-prefixes: Unknown prefix in stream:error
user< at >example.org/nil: connection lost: `finished
'


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2011-02-08 06:34

Message:
Disabling SASL seems to circumvent the problem, but I'm still uncertain of
the cause.

----------------------------------------------------------------------

Comment By: Alexey Lebedev (alexeylebedev)
Date: 2011-02-05 05:21

Message:
Followup:

STARTTLS and Legacy SSL connection fails almost every time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=586350&aid=3173458&group_id=88346

------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/