Launchpad has imported 24 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=132608.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2006-08-18T20:52:12+00:00 Ungerklaus wrote:
Version: 0.19 #3100 (using KDE 3.5.2, Kubuntu Package
4:3.5.2-0ubuntu18.1 dapper)
Compiler: Target: i486-linux-gnu
OS:Linux (i686) release 2.6.15-26-686
When connecting to the irc.netgamers.org network the network join
command does not work. The reply to the issued commands is "not
registered". I guess the command is sent to early during the connection.
This is really sad because there seems no way to autoidentify to this
network, as their bot useses a uncommon syntax (/msg
p...@cservice.netgamers.org LOGIN nick passwd), also to cloack a "/mode
nick +x" is required.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/0
On 2006-08-26T20:12:35+00:00 Eike Hein wrote:
Rename for clarity.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/1
On 2006-08-26T21:52:37+00:00 Ungerklaus wrote:
The problem seems that the command is not parsed but directly sent to
the server. So /msg wont work, but PRIVMSG ... will do. The
documentation should be fixed, it clearly states "/msg " as examle, the
server response then is unknown command.
So it is not a timing issue but maybe a documentation / not parsed
issue.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/2
On 2006-08-26T22:12:50+00:00 Eike Hein wrote:
I rewrote "Commands" in SVN a couple of months ago - it does parse now.
The timing issue exists regardless in a number of situations, though, so
I chose to make this the bug for it.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/3
On 2006-08-27T14:09:59+00:00 Ungerklaus wrote:
I just noticed that the problem especially exists when a nickname is
already in use. The auto commands are sent before the alternate
nickname.
P.S. I am using 0.19 #3100, wich is the latest available for Kubuntu.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/4
On 2007-01-27T02:01:11+00:00 Eike Hein wrote:
Rename to serve as meta-bug.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/5
On 2007-01-27T02:01:28+00:00 Eike Hein wrote:
*** Bug 140696 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/6
On 2007-04-16T00:28:27+00:00 Eike Hein wrote:
*** Bug 144279 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/7
On 2007-07-20T20:25:13+00:00 Robert Buchholz wrote:
The same goes for auto-join. It should only be run after fully
identified to services, which is not the case right now.
On freenode, the following happens:
== Main window ==
[Notice] -NickServ- This nickname is owned by someone else
[Notice] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY
[Notice] -NickServ- Password accepted - you are now recognized
[Notice] -kornbluth.freenode.net- NickServ set your hostname to
"gentoo/developer/rbu"
== Channel window ==
--> You have joined the channel #gentoo-dev (n=r...@i59f773b4.versanet.de).
while it should be
--> You have joined the channel #gentoo-dev (n=rbu@gentoo/developer/rbu).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/189446/comments/8
On 2007-07-20T23:48:38+00:00 Eike Hein wrote:
For the record: The reason we're not currently doing this isn't because
we're lazy or because we're stupid, but because it's non-trivial, or
rather because the only "solutions" are extremely unattractive.
Authentication on IRC is essentially unstandardized, despite multiple
efforts to correct that problem over the years (the latest of which is
IRC+, which we're involved with to some degree). There's no reliable
protocol by which to authenticate and wait for success or failure.
The first th
