<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to bugs</title><link>https://sourceforge.net/p/dancer/bugs/</link><description>Recent changes to bugs</description><atom:link href="https://sourceforge.net/p/dancer/bugs/feed.rss" rel="self"/><language>en</language><lastBuildDate>Thu, 31 Mar 2005 17:42:19 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/dancer/bugs/feed.rss" rel="self" type="application/rss+xml"/><item><title>OnKick does not handle kicks from servers</title><link>https://sourceforge.net/p/dancer/bugs/13/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;OnKick() in server.c expects its from argument to be of&lt;br /&gt;
the form nick!userhost. When a kick is issued from a&lt;br /&gt;
server[1] it however does not have this form, leading&lt;br /&gt;
to a message like this in the log:&lt;/p&gt;
&lt;p&gt;DEBUG Parse error in OnKick(from =&lt;br /&gt;
"euroserv.fr.quakenet.org", line = "#channel bot :Net&lt;br /&gt;
Rider") (snapshot: netstuff.c line 595)&lt;/p&gt;
&lt;p&gt;Furthermore Dancer does not process the kick thus&lt;br /&gt;
failing to rejoin the channel.&lt;/p&gt;
&lt;p&gt;[1] Like in this case, Quakenet servers kick users&lt;br /&gt;
during netjoin that joined a channel on a split server&lt;br /&gt;
that is password protected on the other side of the&lt;br /&gt;
split from that channel.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Elmar Hoffmann</dc:creator><pubDate>Thu, 31 Mar 2005 17:42:19 -0000</pubDate><guid>https://sourceforge.net40ca393fc7aac26f191617331129cce754051822</guid></item><item><title>Users can excess flood dancer with SAY</title><link>https://sourceforge.net/p/dancer/bugs/12/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;It's possible that users with access to the SAY command&lt;br /&gt;
(possible other commands, too, not checked yet) will&lt;br /&gt;
excess flood the dancer.&lt;br /&gt;
Messages to the clients will be put i the message queue&lt;br /&gt;
where the dancer will prevent itself from being excess&lt;br /&gt;
flooded. But messages to the channel sent with the SAY&lt;br /&gt;
command are sent immideately to the server, without&lt;br /&gt;
flood check.&lt;br /&gt;
So if a user fills up the message queue to keep dancer&lt;br /&gt;
busy sending messages to the server and sends enough&lt;br /&gt;
SAY commands the dancer will be kicked off by the server.&lt;/p&gt;
&lt;p&gt;It was tested on 2004-05-09 with the latest CVS checkout.&lt;/p&gt;
&lt;p&gt;cu [charly]&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">K. Rosenegger</dc:creator><pubDate>Sun, 09 May 2004 03:30:38 -0000</pubDate><guid>https://sourceforge.netfc86c14b2ef68b797b2bf918e414b5da1190c662</guid></item><item><title>Does not compile on gcc 3.3.3</title><link>https://sourceforge.net/p/dancer/bugs/11/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Dancer 4.16 does NOT compile under gcc 3.3.3, meanwhile&lt;br /&gt;
it compiles flawlessly on gcc 2.95.4.&lt;/p&gt;
&lt;p&gt;Configured with: FreeBSD/i386 system compiler&lt;br /&gt;
Thread model: posix&lt;br /&gt;
gcc version 3.3.3 [FreeBSD] 20031106&lt;br /&gt;
FreeBSD 5.2-RELEASE&lt;/p&gt;
&lt;p&gt;GNU ld version 2.13.2 [FreeBSD] 2002-11-27&lt;/p&gt;
&lt;p&gt;alex@kronos ~/dancer-4.16/src 528$ make&lt;br /&gt;
gcc -DHAVE_CONFIG_H  -c command.c&lt;br /&gt;
command.c:4313:36: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4313:36: pasting "topitem" and "*" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4313:36: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4313:36: pasting "topitem" and ")" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4340:35: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4340:35: pasting "topitem" and "*" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4340:35: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4340:35: pasting "topitem" and ")" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4374:35: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4374:35: pasting "topitem" and "*" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4374:35: pasting "(" and "topitem" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
command.c:4374:35: pasting "topitem" and ")" does not&lt;br /&gt;
give a valid preprocessing token&lt;br /&gt;
*** Error code 1&lt;/p&gt;
&lt;p&gt;Stop in /usr/home/alex/dancer-4.16/src.&lt;br /&gt;
alex@kronos ~/dancer-4.16/src 529$ &lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Mon, 19 Jan 2004 05:02:26 -0000</pubDate><guid>https://sourceforge.netf75b073cc1ecddabd0d2eff96590c1c66b962234</guid></item><item><title>Tailing ,, causes commands to loop</title><link>https://sourceforge.net/p/dancer/bugs/10/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;A flaw in Dancer's parse code means that trailing&lt;br /&gt;
commas repeats the leading command for each comma. This&lt;br /&gt;
is probably a bug in the code that parses:&lt;/p&gt;
&lt;p&gt;/msg bot command option1,option2&lt;/p&gt;
&lt;p&gt;Will fix for 4.17 which is our Real Soon Now.&lt;/p&gt;&lt;/div&gt;</description><pubDate>Mon, 27 Oct 2003 20:41:35 -0000</pubDate><guid>https://sourceforge.net841e0d495fcc3df4a63b7c391585ced16698cbf3</guid></item><item><title>DNSspam detector</title><link>https://sourceforge.net/p/dancer/bugs/9/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;People have expressed interest in a DNS spam &lt;br /&gt;
detector. It would be optional and would analyse&lt;br /&gt;
hostpatterns on every join, kicking/banning on&lt;br /&gt;
policy violation.&lt;/p&gt;&lt;/div&gt;</description><pubDate>Wed, 16 Apr 2003 08:46:58 -0000</pubDate><guid>https://sourceforge.net8cf8a2f2d98f2c517bf2550dbcac5bd24e18f9de</guid></item><item><title>Nicname identify to nickserv</title><link>https://sourceforge.net/p/dancer/bugs/8/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I Have a problem with identifying to nickserv.&lt;br /&gt;
I installed dancer for win32 and I tried the dancer.fplconf&lt;br /&gt;
connect: &amp;amp;quot;&amp;amp;quot; Do(&amp;amp;quot;privmsg nickserv identify PASSWD&amp;amp;quot;);&lt;br /&gt;
and tried the dancer.config&lt;br /&gt;
nickpassw = PASSWD&lt;/p&gt;
&lt;p&gt;but nothing helps&lt;br /&gt;
all I can do is connect and then with my owner&lt;br /&gt;
/msg MYBOT do privmsg nickserv identify PASSWD&lt;/p&gt;
&lt;p&gt;but can I automize it? like FPL or config&lt;br /&gt;
did I do something wrong? or is it a bug?&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Thu, 24 Oct 2002 00:08:54 -0000</pubDate><guid>https://sourceforge.net092bda61528174664de362983322378efee7365b</guid></item><item><title>hostisp does not work</title><link>https://sourceforge.net/p/dancer/bugs/7/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I can vaguely recollect a verbal bugreport given to me&lt;br /&gt;
a long time ago about the hostisp not working in the&lt;br /&gt;
sense that hostisp's were site-banned even though they&lt;br /&gt;
were listed.&lt;/p&gt;
&lt;p&gt;This also need to be found and fixed prior to 4.17&lt;/p&gt;&lt;/div&gt;</description><pubDate>Mon, 12 Aug 2002 22:54:32 -0000</pubDate><guid>https://sourceforge.net09b8afb95ba84a42004da69ff20ed87769823535</guid></item><item><title>Signal handler needs work</title><link>https://sourceforge.net/p/dancer/bugs/6/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Parts of the signal handler uses non-reentrant system&lt;br /&gt;
calls which causes Dancer to loop inside the handler on&lt;br /&gt;
segfaults. Perhaps removing the gdb interaction is in&lt;br /&gt;
order.&lt;/p&gt;
&lt;p&gt;This is also required before 4.17 can hit the street.&lt;/p&gt;&lt;/div&gt;</description><pubDate>Mon, 12 Aug 2002 19:50:18 -0000</pubDate><guid>https://sourceforge.nete36e2739fc8c4d48a706e7f5d5686dcbae5244f4</guid></item><item><title>trio needs updating</title><link>https://sourceforge.net/p/dancer/bugs/5/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;The trio package needs to be synced with the latest&lt;br /&gt;
release,&lt;br /&gt;
prior to rolling Dancer 4.17 -- Elmar has already&lt;br /&gt;
determined tthat trio 1.62 is NOT a drop-in replacement&lt;br /&gt;
for the completely outdated version we have in our tree.&lt;/p&gt;&lt;/div&gt;</description><pubDate>Mon, 12 Aug 2002 19:48:49 -0000</pubDate><guid>https://sourceforge.netc5a49e9d9668e109f7cc3564940e644ff08143a3</guid></item><item><title>Flawed uppercase and colour checks.</title><link>https://sourceforge.net/p/dancer/bugs/4/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;If colour kicks are disabled but uppercase kicks are&lt;br /&gt;
enabled,&lt;br /&gt;
Dancer does not kick uppercase violators when the&lt;br /&gt;
uppercase &lt;br /&gt;
messages appear in colour.&lt;/p&gt;
&lt;p&gt;Reason unknown.&lt;/p&gt;&lt;/div&gt;</description><pubDate>Sat, 27 Oct 2001 19:53:54 -0000</pubDate><guid>https://sourceforge.net2fb33cd0ae7ed7d31daada2d7ccb5d0554c33a23</guid></item></channel></rss>