| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=69311
|
|
|
|
|
|
| |
Among other effects, this makes GLIB_VERSION_MIN_REQUIRED effective.
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
|
|
|
| |
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
|
|
|
|
| |
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49600
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
I can't find any coherent specification for this type of channel name
(which appear to start with ! and contain five upper-case or numeric
chars). All the RFCs just reference other RFCs but it seems to be
something to do with safe channels. Anyway... let's not blow up if
someone actually tries to use one of these with less than five
characters after the bang!
|
|
|
|
|
|
| |
For some reason, we were strduping the channel name needlessly in
_channel_normalize_func()
Also, we forgot to free the bodies returned from idle_text_encode_and_split()
|
|
|
|
| |
I think this is clearer; it makes the loop's conditions more obvious.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
others
Bip has a nasty habit of sending backlog activity from a fictional '-bip' user.
Unfortunately, a nick with a leading '-' character is illegal according to the
IRC RFCs, but we have to accept it since people appear to be using it in the
wild.
This patch adds a flag to the nick validation script that specifies whether we
should use strict mode or lenient mode. We use strict mode for validating local
nicknames, and lenient mode for validating remote nicknames.
|
|\
| |
| |
| |
| | |
Conflicts:
tests/twisted/Makefile.am
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we were allowing the nick to consist of any unicode alpha or digit
characters, but the IRC spec (RFC2812 section 2.3.1) is very explicit about
which characters are valid for a nick, and it's only ascii chars.
In addition, we weren't disallowing '-' as the first character of a nickname as
required by the IRC spec.
Added a few additional tests for valid and invalid nicks
|
| |
| |
| |
| |
| |
| |
| | |
Add a filter for the 'account' param of the RequestConnection method so that it
can check if the passed nickname is valid for an IRC nick and reject it if not.
Previously, telepathy-idle happily accepted invalid nicknames and then didn't
provide any decent feedback about what was wrong when the 'login' failed.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could perhaps be a slightly controversial change. The reason that the bug
happened was that telepathy-idle's room handle repository normalizer function
had some special code to make joining chatrooms more user-friendly. Basically,
if the user specified a chatroom 'foo', it would assume you meant '#foo' and
automatically prepend the '#' character.
The way the parser currently works is that when we get in a privmsg, we try to
parse the 'destination' of the privmsg as both a contact and a room. The way we
determine if it's a valid room or not is by calling tp_handle_ensure(room_repo,
...) (and same for determining valid contacts). Unfortunately, because of the
automatic #-prepending this means that a single privmsg destination can be both
a valid contact and a valid channel name, so if the user is in a channel with
the same name as their nick (but without the leading #), the privmsg will be
handled by both the IMFactory and the MUCFactory
|
| |
|
|
|
|
| |
20080115205329-9db4d-6a57ff858a5ce98ae86074e81f3be814e05d6bd3.gz
|
|
|
|
|
|
| |
have whitespace in between
20071227220208-9db4d-2e018ea7b69ed08e7f17c909b2fa47470c4081e0.gz
|
|
|
|
|
|
| |
statements
20071227203300-9db4d-47a1011afb9c3cd20b58f249b756744115b0b181.gz
|
|
|
|
| |
20071227201813-9db4d-818203d16e295aa5bd678dd62cccffd76c836f17.gz
|
|
|
|
| |
20071227201423-9db4d-9747ce7d1faa02cd80ab78daeec4d2abad6af37f.gz
|
|
|
|
| |
20070510101223-9db4d-a50c3ddec233076d28fd9bce763f4d1e5ee59281.gz
|
|
|
|
| |
20070426095746-9db4d-ab40051022f1632a4fcf45d693e9954c92ea4471.gz
|
|
|
|
| |
20070410214915-9db4d-1fcb3dcb0f4873f0fba7ec08f32b32a110463dd3.gz
|
|
|
|
|
|
| |
lose MUC though)
20070410212647-9db4d-797a9f937dd925a75ffc5e7c1f4c73e703e599ea.gz
|
|
|
|
| |
20070405180531-9db4d-a38a8379863a578a13288c31cf62518761ab47d1.gz
|
|
|
|
| |
20070331184618-9db4d-266d19b78932da09df53b3b21dc8b9d8ee328e7e.gz
|
|
|
|
| |
20070329110457-9db4d-3b2383fb5f7978a015c2ef8f03ba212466d7dda1.gz
|
|
|
|
| |
20070329100802-9db4d-14c99284f6798e076ac351561bc6eeccac09d951.gz
|
|
|
|
| |
20070328152136-9db4d-4b0c241a38a6cab149f9af00bd5b243f39644048.gz
|
|
|
|
|
|
| |
a segfault
20070322172541-9db4d-8257aef413ac2393f9b8c034fd8d46af70efbbef.gz
|
|
|
|
| |
20070204223035-9db4d-eb01a394b0a783b0647d11c1a33d4dc8d15e1c7a.gz
|
|
|
|
| |
20070131212013-9db4d-99121c1bfd2ddc080836012d11bfde0710ee811b.gz
|
|
20070129154736-9db4d-be80727a61507e6581870228122d0d2a7c12995e.gz
|