rename -> *.git

[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2006.txt

From ron2k.za at gmail.com  Sat Jan  7 08:29:19 2006
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Sat Jan  7 08:29:36 2006
Subject: [IRCServices Coding] Some points for 5.1
Message-ID: <debb3bc0601070829j79ac2dcctef93bfbb8782d274@mail.gmail.com>

Firstly, congratulations to Andy for getting the first version of 5.1
released. Sorry to hear that you're quitting Services development
though.

There are a few issues with 5.1 that I'd like to mention:

- I enabled encryption for the first time when using 5.1, and dumped
the XML output to file immediately afterwards to see the results
(after saving the databases, obviously). I noticed that all the
channel founder passwords had "cipher=md5" included in the XML tag,
even when the passwords were still unencrypted. (The nickname
passwords appear to be fine though.) If you want me to, I can
privately send you the XML file so you can see what I'm talking about
- it's not very big (only 3 nicks and 10 channels).

- Is there any way that news items can be included in the XML dump? I
don't know about the rest of the users out there, but I personally
find it very annoying having to manually re-enter them after restoring
corrupt databases, transferring my data between versions 5.0 and 5.1,
etc.

- I can understand your reasons for removing support for the channel
owner mode, but I think that there might be some controversy over this
one. Would it be possible for third party module coders to add support
for this mode? (For the record, the aforementioned module coder won't
be me; I don't know any C :P)

Once again, thanks for the release.
From achurch at achurch.org  Mon Jan  9 13:00:36 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan  8 20:02:42 2006
Subject: [IRCServices Coding] Services 5.1a1, aka the Database Eater
Message-ID: <43c1e03a.16457@msgid.achurch.org>

     Services 5.1a1 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

72931718d616e2abee6000bd7f5fec5b  ircservices-5.1a1.tar.gz
0ec44134fd4808601baa4781ba3c2436  ircservices-5.1a1.diff.gz
e3d6e1d89e30b497c92aa44e8455ecb6  ircservices-5.1a1-1.i386.rpm
a95bc2330830639e5001cfab4a44dbba  ircservices_5.1a1-1_i386.deb

The mirrors should have it shortly.

     I've finally finished implementing the new database format, and it's
included in this version as the new database/standard module.  I said it
before, but I'll say it again since it's particularly relevant to this
release:  BACK UP YOUR DATA because alpha versions (particularly this one)
may eat it!

     I've also made the new database module the default in the example
ircservices.conf file, so if you use that as is then your old data won't
get loaded at all.  Instructions for converting from the old database
format to the new one can be found in the "Upgrading" section of the
manual.

     (And no, I'm not ignoring mail on this list. (:  I just wanted to get
this done first.)

Changes in version 5.1a1
------------------------
2006/01/09	Finished implementing the database/standard module, and
		    made it the default in the example configuration file.
2006/01/08	Removed no-longer-needed new_suspendinfo() and
		    free_suspendinfo() functions.
2006/01/08	Moved SuspendInfo structure directly into NickGroupInfo and
		    ChannelInfo structures rather than using pointers.
2006/01/07	Added ACCLEV_MAX and ACCLEV_MIN constants to explicitly
		    define ChanServ access levels, rather than relying on
		    ACCLEV_FOUNDER and ACCLEV_INVALID.
2006/01/04	Fixed a bug in writing generic database tables.
2006/01/04	Fixed a bug in the Unreal protocol module causing user
		    fakehost masks to get set to the user's mode string.
2005/11/23	Added support for writing generic tables (using the new
		    database format) in the database/version4 module.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sun Jan 15 13:57:41 2006
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 14 21:01:38 2006
Subject: [IRCServices Coding] Some points for 5.1
In-Reply-To: <debb3bc0601070829j79ac2dcctef93bfbb8782d274@mail.gmail.com>
Message-ID: <43c9d729.65444@msgid.achurch.org>

>- I enabled encryption for the first time when using 5.1, and dumped
>the XML output to file immediately afterwards to see the results
>(after saving the databases, obviously). I noticed that all the
>channel founder passwords had "cipher=md5" included in the XML tag,
>even when the passwords were still unencrypted. (The nickname
>passwords appear to be fine though.) If you want me to, I can
>privately send you the XML file so you can see what I'm talking about
>- it's not very big (only 3 nicks and 10 channels).

     I'll take a look into this, thanks for the report.

>- Is there any way that news items can be included in the XML dump? I
>don't know about the rest of the users out there, but I personally
>find it very annoying having to manually re-enter them after restoring
>corrupt databases, transferring my data between versions 5.0 and 5.1,
>etc.

     I did not initially include news items because I couldn't think of a
case where they'd be handy; since you give some here, I'll look into adding
them.

>- I can understand your reasons for removing support for the channel
>owner mode, but I think that there might be some controversy over this
>one. Would it be possible for third party module coders to add support
>for this mode? (For the record, the aforementioned module coder won't
>be me; I don't know any C :P)

     Yes, the necessary callbacks and exported functions are present (or
should be, anyway, and I can fix things if not).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sun Jan 15 14:03:09 2006
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 14 21:04:14 2006
Subject: [IRCServices Coding] MS IGNORE
In-Reply-To: <43B516F0.7030900@gmail.com>
Message-ID: <43c9d7c9.65461@msgid.achurch.org>

     Yes, that seems like the natural behavior for nickname entries.  I'll
look into implementing it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hi,
>
>This should possibly have gone to -general, but regardless.
>
>MS IGNORE, if used on a nick target *should* ignore all memos from that 
>account to a target, which it probably does. However, it does not appear 
>to ignore memos from a linked nickname or something, as it seems to have 
>gone through...
>
>-MemoServ- Ignore list:
>-MemoServ-     igor
>
>-MemoServ- Memo 2 from pingout (Dec 29 23:47:39 2005 UTC).  To delete, 
>type: /msg MemoServ DEL 2
>
>I can't confirm this was a linked nick, and I probably should RTFS to 
>check first, but please excuse me being naughty as I'm in a little of a 
>hurry. Naturally, IGNORE on a u@h would eliminate this problem.
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From Craig at frostycoolslug.com  Sat Jan 14 21:04:32 2006
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sat Jan 14 21:07:17 2006
Subject: [IRCServices Coding] Some points for 5.1
In-Reply-To: <43c9d729.65444@msgid.achurch.org>
References: <43c9d729.65444@msgid.achurch.org>
Message-ID: <43C9D7E0.6020105@frostycoolslug.com>

>> - I can understand your reasons for removing support for the channel
>> owner mode, but I think that there might be some controversy over this
>> one. Would it be possible for third party module coders to add support
>> for this mode? (For the record, the aforementioned module coder won't
>> be me; I don't know any C :P)
> 
>      Yes, the necessary callbacks and exported functions are present (or
> should be, anyway, and I can fix things if not).
> 

As a note, if this module is still required when 5.1 reaches beta, i'll
look into how easy it would be to add it in (Given the 5.0 module API, i
can't see it being too much of a problem :))

--
Craig McLure
InspIRCd Developer
Network Administrator of the ChatSpike IRC Network

From achurch at achurch.org  Sun Jan 15 18:14:05 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan 15 01:14:18 2006
Subject: [IRCServices Coding] Channel password encryption issue
Message-ID: <43ca1261.77040@msgid.achurch.org>

     To the reporter of the issue with channel password cipher strings
being saved incorrectly in the XML file:  Did you set the EncryptionType
directive before saving your data at least once with 5.1?  5.0 and earlier
don't save the encryption type, so 5.1 has no way to know the proper cipher
and just defaults to the EncryptionType setting.  I'm unable to reproduce
the problem using databases saved under 5.1.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From ron2k.za at gmail.com  Sun Jan 15 01:30:15 2006
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Sun Jan 15 01:30:24 2006
Subject: [IRCServices Coding] Channel password encryption issue
In-Reply-To: <43ca1261.77040@msgid.achurch.org>
References: <43ca1261.77040@msgid.achurch.org>
Message-ID: <debb3bc0601150130w4dbfb7bfwf0927d20a97ecc07@mail.gmail.com>

> Did you set the EncryptionType directive before saving your data at
> least once with 5.1?

I imported the data from 5.0, then enabled encryption. As I've got a
30 minute interval between database saves, most likely it didn't save
before encryption was enabled.

> 5.0 and earlier don't save the encryption type, so 5.1 has no way
> to know the proper cipher and just defaults to the EncryptionType
> setting.

Makes sense.
From achurch at achurch.org  Sun Jan 15 19:55:36 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan 15 03:13:30 2006
Subject: [IRCServices Coding] Services 5.1a2 released
Message-ID: <43ca2e54.23226@msgid.achurch.org>

     Services 5.1a2 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

1d94d32ad72e289e824ef45d5c097a26  ircservices-5.1a2.tar.gz
ac48437b8640c73be4025366a8f97545  ircservices-5.1a2.diff.gz
12853ad85b3f0753a7cbdac56bbc2c3f  ircservices-5.1a2-1.i386.rpm
aa8a090a903b1d91f1ae2183816db4a2  ircservices_5.1a2-1_i386.deb

The mirrors should have it shortly.

     This is just a quick release to get out a few additional changes
I've made, and fix a bug causing the version4 database to lose all your
channels--though I prefer to think of that as an incentive to switch to
the new database format. ;)  The big thing to note is that some of the
databases have changed names, so if you've switched to the
database/standard module, you'll need to rename files as follows:

nickgroup-access.sdb -> nick-access.sdb
nickgroup-ajoin.sdb  -> nick-autojoin.sdb
nickgroup-ignore.sdb -> memo-ignore.sdb
nickgroup-memo.sdb   -> memo.sdb

     I should also mention that I've finished everything on my personal
to-do list for 5.1, except for writing the technical design manual (sigh,
there go the next few months of my life); there are still a number of
items in the TODO file in the distribution, but considering also that
that file is rather old, I'm going to leave those for future developers
unless there's a particular desire for something to be included in 5.1.
In other words, if you want to see something in 5.1, now's the time to
ask!

Changes in version 5.1a2
------------------------
2006/01/15	Fixed a bug in loading the ChanServ database in the
		    database/version4 module.
2006/01/15	The misc/xml-import module now allows news items to be
		    imported via the ImportNews configuration directive.
		    Suggested by Kieron Thwaites <ron2k.za@gmail.com>
2006/01/15	MemoServ IGNORE now ignores memos from nicknames linked to
		    nickname (but not wildcard) entries on the ignore list.
		    Suggested by Robin Burchell <surreal.w00t@gmail.com>
2006/01/15	Renamed ChannelInfo CI_* flags to CF_* for consistency with
		    other structures' flags.
2006/01/09	Moved the access, autojoin, memo, and ignore databases to
		    their respective modules, and changed the database
		    names to "nick-access", "nick-autojoin", "memo", and
		    "memo-ignore" respectively.
2006/01/09	Changed DBTable.insert() to not return a value.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.Ru  Mon Jan 16 01:40:37 2006
From: V.Ovsyannikov at kr.Ru (Vitaliy Ovsyannikov)
Date: Mon Jan 16 01:42:11 2006
Subject: [IRCServices Coding] Sending privmsg/notice
Message-ID: <153056079.20060116164037@kr.Ru>

Hello, ircservices-coding.

  I want to send privmsg/notice to all online Opers. How I can
get list of users who have mode +o enabled? (in separate module I
mean)

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Mon Jan 16 20:15:06 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jan 16 03:36:05 2006
Subject: [IRCServices Coding] Sending privmsg/notice
In-Reply-To: <153056079.20060116164037@kr.Ru>
Message-ID: <43cb851b.33162@msgid.achurch.org>

>  I want to send privmsg/notice to all online Opers. How I can
>get list of users who have mode +o enabled? (in separate module I
>mean)

     Iterate through the user list with first_user() and next_user(), and
use is_oper() to check whether the user is an oper or not.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Mon Jan 16 03:44:17 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 16 03:45:54 2006
Subject: [IRCServices Coding] xml-import
Message-ID: <933438702.20060116184417@kr.ru>

Hello, ircservices-coding.

  I have exported db from 5.0.55 with httpd/dbaccess and xml-export modules.
Now, I want to import the data to 5.1a2. How? I have enabled
xml-import module, but dbaccess doesn't provide any import links on
http.

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From ron2k.za at gmail.com  Mon Jan 16 06:05:50 2006
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Mon Jan 16 06:05:59 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <933438702.20060116184417@kr.ru>
References: <933438702.20060116184417@kr.ru>
Message-ID: <debb3bc0601160605g5c7f8f6dvaaab83f37407631@mail.gmail.com>

You need to to add the -import parameter with the XML file name when
starting Services.
From V.Ovsyannikov at kr.ru  Mon Jan 16 19:17:14 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 16 19:18:48 2006
Subject: [IRCServices Coding] nicks/chans multilingual support
Message-ID: <1871671893.20060117101714@kr.ru>

Hello, ircservices-coding.

  Does 5.1 supports operations with non-english data such as localized
nicknames/channel names?

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From V.Ovsyannikov at kr.ru  Mon Jan 16 21:22:21 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 16 21:23:51 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <debb3bc0601160605g5c7f8f6dvaaab83f37407631@mail.gmail.com>
References: <933438702.20060116184417@kr.ru>
	<debb3bc0601160605g5c7f8f6dvaaab83f37407631@mail.gmail.com>
Message-ID: <1996813325.20060117122221@kr.ru>

Hello, IRC.

> You need to to add the -import parameter with the XML file name when
> starting Services.

I've got troubles! With database/standard:
All data is imported well, but services exited on segm. fault.
Here is backtrace from core file:

(gdb) bt
#0  0x281c061e in write_string (s=0xc <Address 0xc out of bounds>, f=0x82e2000) at modules/database/fileutil.c:398
#1  0x281bf951 in standard_save_table (table=0x282220bc) at modules/database/standard.c:734
#2  0x08050295 in save_all_dbtables () at databases.c:128
#3  0x080525f5 in init (ac=3, av=0xbfbfec00) at init.c:952
#4  0x08054d8d in main (ac=3, av=0xbfbfec00, envp=0xbfbfec10) at main.c:216

All .sdb files look good except whis one:
chan-access.sdb.new

I've deleted this file and run ircservices anyway and got segmentation
fault again. Backtrace:

#0  0x281f7cfd in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
102     modules/nickserv/util.c: No such file or directory.
        in modules/nickserv/util.c
(gdb) bt
#0  0x281f7cfd in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
#1  0x281beeb8 in standard_load_table (table=0x281fca48) at modules/database/standard.c:411
#2  0x0805019c in register_dbtable (table=0x281fca48) at databases.c:78
#3  0x281f5d76 in init_module () at modules/nickserv/main.c:2725
#4  0x0805813b in load_module (modulename=0x808e120 "nickserv/main") at modules.c:424
#5  0x080525a9 in init (ac=2, av=0xbfbfec28) at init.c:937
#6  0x08054d8d in main (ac=2, av=0xbfbfec28, envp=0xbfbfec34) at main.c:216

With database/version4:
services just imported the data and exited with message in
ircservices.log: Terminating, reason unknown
Starting it up says: (database/version4) Invalid format in chan.db
And services continue to work with no registered channels at all.

Nicknames are okay.
Please give me some ideas why channels importing doesn't work.
Thanks.

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Tue Jan 17 16:08:56 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jan 16 23:12:18 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <1996813325.20060117122221@kr.ru>
Message-ID: <43cc981f.70604@msgid.achurch.org>

     What version are you using?  If it's 5.1a2, please send me (privately)
the XML file so I can test for the problem here.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hello, IRC.
>
>> You need to to add the -import parameter with the XML file name when
>> starting Services.
>
>I've got troubles! With database/standard:
>All data is imported well, but services exited on segm. fault.
>Here is backtrace from core file:
>
>(gdb) bt
>#0  0x281c061e in write_string (s=0xc <Address 0xc out of bounds>, f=0x82e2000) at modules/database/fileutil.c:398
>#1  0x281bf951 in standard_save_table (table=0x282220bc) at modules/database/standard.c:734
>#2  0x08050295 in save_all_dbtables () at databases.c:128
>#3  0x080525f5 in init (ac=3, av=0xbfbfec00) at init.c:952
>#4  0x08054d8d in main (ac=3, av=0xbfbfec00, envp=0xbfbfec10) at main.c:216
>
>All .sdb files look good except whis one:
>chan-access.sdb.new
>
>I've deleted this file and run ircservices anyway and got segmentation
>fault again. Backtrace:
>
>#0  0x281f7cfd in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
>102     modules/nickserv/util.c: No such file or directory.
>        in modules/nickserv/util.c
>(gdb) bt
>#0  0x281f7cfd in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
>#1  0x281beeb8 in standard_load_table (table=0x281fca48) at modules/database/standard.c:411
>#2  0x0805019c in register_dbtable (table=0x281fca48) at databases.c:78
>#3  0x281f5d76 in init_module () at modules/nickserv/main.c:2725
>#4  0x0805813b in load_module (modulename=0x808e120 "nickserv/main") at modules.c:424
>#5  0x080525a9 in init (ac=2, av=0xbfbfec28) at init.c:937
>#6  0x08054d8d in main (ac=2, av=0xbfbfec28, envp=0xbfbfec34) at main.c:216
>
>With database/version4:
>services just imported the data and exited with message in
>ircservices.log: Terminating, reason unknown
>Starting it up says: (database/version4) Invalid format in chan.db
>And services continue to work with no registered channels at all.
>
>Nicknames are okay.
>Please give me some ideas why channels importing doesn't work.
>Thanks.
>
>-- 
>Sincerely,
>Vitaliy Ovsyannikov
>JSC Skala, Krasnoyarsk, Russia
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding

From achurch at achurch.org  Tue Jan 17 19:24:08 2006
From: achurch at achurch.org (Andrew Church)
Date: Tue Jan 17 02:28:53 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <1197115644.20060117145552@kr.ru>
Message-ID: <43ccc6df.74664@msgid.achurch.org>

     I've fixed the problem, thanks for the report.  I'll put out a new
release shortly.

     Also, your mail server is rejecting mail from me; please see
http://achurch.org/dnsbl.html .

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hello, Andrew.
>
>>      What version are you using?  If it's 5.1a2, please send me (privately)
>> the XML file so I can test for the problem here.
>
>Where is a wrong information about 5.1a2 in the previus letter. I've
>patched 5.1a1 incorrectly. But after recompiling from 5.1a2 src
>archive, I've found what importing with database/standard still crashes
>ircservices with segm. fault and there is the same backtrace sequence.
>
>Importing with database/version4 works well now.
>
>XML data is attached. Please don't share it :) Thanks.
>
>-- 
>Sincerely,
>Vitaliy Ovsyannikov
>JSC Skala, Krasnoyarsk, Russia
From V.Ovsyannikov at kr.ru  Tue Jan 17 02:45:43 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Tue Jan 17 02:47:13 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <43ccc6df.74664@msgid.achurch.org>
References: <1197115644.20060117145552@kr.ru>
	<43ccc6df.74664@msgid.achurch.org>
Message-ID: <1786329123.20060117174543@kr.ru>

Hello, IRC.

>      I've fixed the problem, thanks for the report.  I'll put out a new
> release shortly.

I'm glad to see it, thanks.

>      Also, your mail server is rejecting mail from me; please see
> http://achurch.org/dnsbl.html .

Actually, there are no DNSBL checks on my server. DNSBLs are very
incorrect in some cases. Your relay was rejected by my filters.
It was hostname regex filter:

# hostnames with repeating digits (5 digits or more)
/\d{5,}/                                        REJECT filter 01009
against your host p10218-ipbffx02hodogaya.kanagawa.ocn.ne.jp[60.39.233.218]

I recommend you to setup reverse DNS record in good style. ('achurch.org' for
example) Alot of servers are using such filters to determine sender
is in dynamic/dhcp pools. Please have it in your mind.

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Tue Jan 17 19:44:42 2006
From: achurch at achurch.org (Andrew Church)
Date: Tue Jan 17 02:47:18 2006
Subject: [IRCServices Coding] Services 5.1a3 released
Message-ID: <43cccb2d.16611@msgid.achurch.org>

     Services 5.1a3 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

55ea5e0fc4de975a7a8fc60cdc3e6b2b  ircservices-5.1a3.tar.gz
64f7ce1c59fe6ef09090bdd55f01f1fe  ircservices-5.1a3.diff.gz
fda21ce54ddcbf2b7e0e06ea3d5fb9b1  ircservices-5.1a3-1.i386.rpm
2ed13d366d9523f7612c47867953cc93  ircservices_5.1a3-1_i386.deb

The mirrors should have it shortly.

     This fixes the bug just reported with importing channel data into the
database/standard module (a silly oversight on my part), and gets rid of
some file mode cruft left over from many versions ago.  The still-very-
incomplete technical reference manual has also made its first appearance,
assuming my release script did what it was supposed to...

Changes in version 5.1a3
------------------------
2006/01/17	Fixed a bug in importing channel data when using the
		    database/standard module.  Reported by Vitaliy
		    Ovsyannikov <V.Ovsyannikov@kr.ru>
2006/01/17	The language and data file installation procedure no longer
		    sets the installed files' modes to owner-access-only;
		    the default file mode (as set with umask) is used.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Tue Jan 17 03:20:09 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Tue Jan 17 03:21:31 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <43ccc6df.74664@msgid.achurch.org>
References: <1197115644.20060117145552@kr.ru>
	<43ccc6df.74664@msgid.achurch.org>
Message-ID: <1947274381.20060117182009@kr.ru>

Hello, IRC.

>      I've fixed the problem, thanks for the report.  I'll put out a new
> release shortly.

It looks like services do import data w/o errors and exist. But it is
still crashing on second execution (without -import key):

#0  0x281f9209 in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
102             for (count = 0; seed[count] != 0; count++)
(gdb) bt
#0  0x281f9209 in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
#1  0x281beed0 in standard_load_table (table=0x281fed68) at modules/database/standard.c:411
#2  0x0805019c in register_dbtable (table=0x281fed68) at databases.c:78
#3  0x281f72d2 in init_module () at modules/nickserv/main.c:2443
#4  0x0805813b in load_module (modulename=0x808e120 "nickserv/main") at modules.c:424
#5  0x080525a9 in init (ac=2, av=0xbfbfec28) at init.c:937
#6  0x08054d8d in main (ac=2, av=0xbfbfec28, envp=0xbfbfec34) at main.c:216


-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Tue Jan 17 21:00:36 2006
From: achurch at achurch.org (Andrew Church)
Date: Tue Jan 17 04:00:54 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <1786329123.20060117174543@kr.ru>
Message-ID: <43ccdc6f.22515@msgid.achurch.org>

>I recommend you to setup reverse DNS record in good style. ('achurch.org' for
>example) Alot of servers are using such filters to determine sender
>is in dynamic/dhcp pools. Please have it in your mind.

     Unfortunately, my ISP doesn't allow its customers to set up their own
reverse DNS, so this isn't an option for me.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From olly at avansys.co.uk  Tue Jan 17 04:23:44 2006
From: olly at avansys.co.uk (Olly)
Date: Tue Jan 17 04:23:29 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <43ccdc6f.22515@msgid.achurch.org>
Message-ID: <5ad70eb6c9988b48bd525e260bf3bdd9@avansys.co.uk>

Off topic I know, but zoneedit.com allow their servers to be set up as
secondaries to your hidden primary. This puts your zone completely under
your control if you set the servers they give you as your registered DNS
servers. What's more it's free.
I've been doing this for years now and find it to be an excellent
solution. Especially if you have multiple ISPs.

-----Original Message-----
From: ircservices-coding-bounces@ircservices.esper.net
[mailto:ircservices-coding-bounces@ircservices.esper.net] On Behalf Of
Andrew Church
Sent: 17 January 2006 21:01
To: serv-coding
Subject: Re: Re[6]: [IRCServices Coding] xml-import

>I recommend you to setup reverse DNS record in good style. 
>('achurch.org' for
>example) Alot of servers are using such filters to determine sender is 
>in dynamic/dhcp pools. Please have it in your mind.

     Unfortunately, my ISP doesn't allow its customers to set up their
own reverse DNS, so this isn't an option for me.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding



From achurch at achurch.org  Tue Jan 17 21:33:13 2006
From: achurch at achurch.org (Andrew Church)
Date: Tue Jan 17 04:38:06 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <1947274381.20060117182009@kr.ru>
Message-ID: <43cce528.25124@msgid.achurch.org>

>>      I've fixed the problem, thanks for the report.  I'll put out a new
>> release shortly.
>
>It looks like services do import data w/o errors and exist. But it is
>still crashing on second execution (without -import key):
>
>#0  0x281f9209 in new_nickgroupinfo (seed=0x10 <Address 0x10 out of bounds>) at modules/nickserv/util.c:102
>102             for (count = 0; seed[count] != 0; count++)

     Okay, I'm stupid again.  Try this patch:

Index: modules/nickserv/main.c
===================================================================
RCS file: /var/local/cvsroot/ircservices/modules/nickserv/main.c,v
retrieving revision 2.226
diff -u -r2.226 main.c
--- modules/nickserv/main.c	9 Jan 2006 10:19:58 -0000	2.226
+++ modules/nickserv/main.c	17 Jan 2006 12:37:28 -0000
@@ -372,6 +372,11 @@
     strbcpy(ngi->nicks[ngi->mainnick], (const char *)value);
 }
 
+static void *db_new_nickgroup(void)
+{
+    return new_nickgroupinfo(NULL);
+}
+
 static void insert_nickgroup(void *record)
 {
     NickGroupInfo *ngi = add_nickgroupinfo(record);
@@ -435,7 +440,7 @@
 };
 static DBTable nickgroup_dbtable = {
     .name    = "nickgroup",
-    .newrec  = (void *)new_nickgroupinfo,
+    .newrec  = db_new_nickgroup,
     .freerec = (void *)free_nickgroupinfo,
     .insert  = insert_nickgroup,
     .first   = (void *)first_nickgroupinfo,

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From quension at mac.com  Tue Jan 17 12:07:31 2006
From: quension at mac.com (Trevor Talbot)
Date: Tue Jan 17 12:07:44 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <5ad70eb6c9988b48bd525e260bf3bdd9@avansys.co.uk>
Message-ID: <E45CC114-8794-11DA-878D-0003938D6866@mac.com>

On Tuesday, Jan 17, 2006, at 04:23 US/Pacific, Olly wrote:

> Off topic I know, but zoneedit.com allow their servers to be set up as 
> secondaries to your hidden primary. This puts your zone completely 
> under your control if you set the servers they give you as your 
> registered DNS servers. What's more it's free.

That only works for forward DNS on domains you own.  Reverse requires 
delegation from the ISP, since they own the zone responsible for your 
IPs.

-- Quension

> -----Original Message-----

>> I recommend you to setup reverse DNS record in good style.
>> ('achurch.org' for
>> example) Alot of servers are using such filters to determine sender is
>> in dynamic/dhcp pools. Please have it in your mind.
>
>      Unfortunately, my ISP doesn't allow its customers to set up their
> own reverse DNS, so this isn't an option for me.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/

From olly at avansys.co.uk  Tue Jan 17 14:43:57 2006
From: olly at avansys.co.uk (Olly)
Date: Tue Jan 17 14:43:43 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <E45CC114-8794-11DA-878D-0003938D6866@mac.com>
Message-ID: <f84be0e515607541817102e9fcbe1241@avansys.co.uk>

I stand corrected I had forgotten that had made that arrangement with my
ISP. 

-----Original Message-----
From: ircservices-coding-bounces@ircservices.esper.net
[mailto:ircservices-coding-bounces@ircservices.esper.net] On Behalf Of
Trevor Talbot
Sent: 17 January 2006 20:08
To: IRC Services Coding Mailing List
Subject: Re: Re[6]: [IRCServices Coding] xml-import

On Tuesday, Jan 17, 2006, at 04:23 US/Pacific, Olly wrote:

> Off topic I know, but zoneedit.com allow their servers to be set up as

> secondaries to your hidden primary. This puts your zone completely 
> under your control if you set the servers they give you as your 
> registered DNS servers. What's more it's free.

That only works for forward DNS on domains you own.  Reverse requires
delegation from the ISP, since they own the zone responsible for your
IPs.

-- Quension

> -----Original Message-----

>> I recommend you to setup reverse DNS record in good style.
>> ('achurch.org' for
>> example) Alot of servers are using such filters to determine sender 
>> is in dynamic/dhcp pools. Please have it in your mind.
>
>      Unfortunately, my ISP doesn't allow its customers to set up their

> own reverse DNS, so this isn't an option for me.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/

------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding



From V.Ovsyannikov at kr.ru  Tue Jan 17 19:39:52 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Tue Jan 17 19:41:13 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <43cce528.25124@msgid.achurch.org>
References: <1947274381.20060117182009@kr.ru>
	<43cce528.25124@msgid.achurch.org>
Message-ID: <39064945.20060118103952@kr.ru>

Hello, IRC.

>      Okay, I'm stupid again.  Try this patch:
>Index: modules/nickserv/main.c

Patched. Result:

[Jan 18 10:32:16 2006] PANIC! signal 11, buffer = :irc.kr.ru SJOIN 0 #quake3 +tnr  :SleepeR
[Jan 18 10:32:16 2006] Services terminating: Segmentation fault: 11
[Jan 18 10:32:16 2006] FATAL: Caught signal 5 (Trace/BPT trap: 5) while shutting down

(Last message caused by gdb)

# gdb ./ircservices
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) r
Starting program: /usr/local/ircd/services/sbin/ircservices
Initialization successful, starting IRC Services.

Program exited normally.


-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From V.Ovsyannikov at kr.ru  Tue Jan 17 23:15:10 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Tue Jan 17 23:16:27 2006
Subject: [IRCServices Coding] CHAN DROP bug in current (5.1a3)
Message-ID: <501556076.20060118141510@kr.ru>

Hello, IRC.

5.1a3 falls down on ChanServ's DROP cmd:

PANIC! buffer = :gravis|wrk PRIVMSG ChanServ@services.xxx :drop #topics
Services terminating: Segmentation fault: 11

There is no core dump, so I can't backtrace it.

DB module: database/version4

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From V.Ovsyannikov at kr.ru  Wed Jan 18 19:30:36 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Wed Jan 18 19:30:58 2006
Subject: [IRCServices Coding] crashes on PRIVMSG
In-Reply-To: <501556076.20060118141510@kr.ru>
References: <501556076.20060118141510@kr.ru>
Message-ID: <1952550932.20060119103036@kr.ru>

Hello, IRC.

I have tested 5.1a3 for some period of time in the production irc-network.
As result of this test, I found what 5.1a3 is very unstable. Here are
some log messages about:

PANIC! signal 11, buffer = :Fire PRIVMSG chanserv :drop #|5|eLeMeNt
Services terminating: Segmentation fault: 11

PANIC! signal 11, buffer = :ElviS1 PRIVMSG NickServ@services.xxx :set secure on
Services terminating: Segmentation fault: 11

PANIC! signal 11, buffer = :BanderA PRIVMSG NickServ :set language 1
Services terminating: Segmentation fault: 11


-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From ron2k.za at gmail.com  Thu Jan 19 11:25:05 2006
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Thu Jan 19 11:25:17 2006
Subject: [IRCServices Coding] crashes on PRIVMSG
In-Reply-To: <1952550932.20060119103036@kr.ru>
References: <501556076.20060118141510@kr.ru> <1952550932.20060119103036@kr.ru>
Message-ID: <debb3bc0601191125o1a15a3fcjcf89dfdbc25cb1f@mail.gmail.com>

Got backtraces for those?
From achurch at achurch.org  Fri Jan 20 12:44:41 2006
From: achurch at achurch.org (Andrew Church)
Date: Thu Jan 19 19:47:10 2006
Subject: [IRCServices Coding] nicks/chans multilingual support
In-Reply-To: <1871671893.20060117101714@kr.ru>
Message-ID: <43d05d35.06352@msgid.achurch.org>

>  Does 5.1 supports operations with non-english data such as localized
>nicknames/channel names?

     Not currently, but I'm planning to look into this and add such support
if it's feasible.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Fri Jan 20 12:45:33 2006
From: achurch at achurch.org (Andrew Church)
Date: Thu Jan 19 19:47:28 2006
Subject: [IRCServices Coding] xml-import
In-Reply-To: <39064945.20060118103952@kr.ru>
Message-ID: <43d05d49.06362@msgid.achurch.org>

>[Jan 18 10:32:16 2006] PANIC! signal 11, buffer = :irc.kr.ru SJOIN 0 #quake3 +tnr  :SleepeR
[...]
>(gdb) r
>Starting program: /usr/local/ircd/services/sbin/ircservices
>Initialization successful, starting IRC Services.
>
>Program exited normally.

     You need to run Services with the -nofork option (also include -debug
for debugging purposes).  Use "r -nofork -debug" at the GDB prompt.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Thu Jan 19 22:23:07 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Thu Jan 19 22:23:10 2006
Subject: [IRCServices Coding] crashes on PRIVMSG
In-Reply-To: <debb3bc0601191125o1a15a3fcjcf89dfdbc25cb1f@mail.gmail.com>
References: <501556076.20060118141510@kr.ru> <1952550932.20060119103036@kr.ru>
	<debb3bc0601191125o1a15a3fcjcf89dfdbc25cb1f@mail.gmail.com>
Message-ID: <921856860.20060120132307@kr.ru>

Hello, IRC.

> Got backtraces for those?

nope
btw, if I run it under gdb, it says 'Programm exited normally'

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From xxx.coder at gmail.com  Thu Jan 19 23:12:28 2006
From: xxx.coder at gmail.com (ongeboren)
Date: Thu Jan 19 23:12:38 2006
Subject: [IRCServices Coding] crashes on PRIVMSG
In-Reply-To: <921856860.20060120132307@kr.ru>
References: <501556076.20060118141510@kr.ru> <1952550932.20060119103036@kr.ru>
	<debb3bc0601191125o1a15a3fcjcf89dfdbc25cb1f@mail.gmail.com>
	<921856860.20060120132307@kr.ru>
Message-ID: <ce6d53600601192312y3dfaf819ra42b1c2629341a32@mail.gmail.com>

If you run something with gdb, this something should not fork() or
with other words, it should run in the foreground. Here I quote Andrew
Church from his last email to the list, but from another thread:
"You need to run Services with the -nofork option (also include -debug
for debugging purposes).  Use "r -nofork -debug" at the GDB prompt."



On 1/20/06, Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru> wrote:
> Hello, IRC.
>
> > Got backtraces for those?
>
> nope
> btw, if I run it under gdb, it says 'Programm exited normally'
>
> --
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>


--
Evlogi Petrov - ongeboren@UniBG
From V.Ovsyannikov at kr.ru  Fri Jan 20 01:55:46 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Fri Jan 20 01:55:42 2006
Subject: [IRCServices Coding] crashes on PRIVMSG -  issue
Message-ID: <419158100.20060120165546@kr.ru>

Hello, IRC.

Notice: nicknames 'BUG' and 'icancrashit' aren't registered!
        ^^^^^^^^^                         ^^^^^^^^^^^^^^^^^

[Jan 20 16:48:26.419298 2006] debug: Received: :BUG PRIVMSG NickServ@services.xxx :set secure on

Program received signal SIGSEGV, Segmentation fault.
do_set_ns (u=0x84e4900) at modules/nickserv/set.c:70
70              ni->usecount++;

[Jan 20 16:39:13.914246 2006] debug: Received: :icancrashit PRIVMSG NickServ@services.xxx :set language 1

Program received signal SIGSEGV, Segmentation fault.
do_set_ns (u=0x8562700) at modules/nickserv/set.c:70
70              ni->usecount++;

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From surreal.w00t at gmail.com  Sat Jan 21 06:35:04 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 21 06:38:08 2006
Subject: [IRCServices Coding] crashes on PRIVMSG - issue
In-Reply-To: <419158100.20060120165546@kr.ru>
References: <419158100.20060120165546@kr.ru>
Message-ID: <b19eae4e0601210635n4342f7ffld1e5e024d72d29a1@mail.gmail.com>

At the gdb prompt, it might be nice if you could provide a 'bt full' output.

On 1/20/06, Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru> wrote:
> Hello, IRC.
>
> Notice: nicknames 'BUG' and 'icancrashit' aren't registered!
>         ^^^^^^^^^                         ^^^^^^^^^^^^^^^^^
>
> [Jan 20 16:48:26.419298 2006] debug: Received: :BUG PRIVMSG NickServ@services.xxx :set secure on
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x84e4900) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> [Jan 20 16:39:13.914246 2006] debug: Received: :icancrashit PRIVMSG NickServ@services.xxx :set language 1
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x8562700) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> --
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From surreal.w00t at gmail.com  Sat Jan 21 06:35:04 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 21 06:43:27 2006
Subject: [IRCServices Coding] crashes on PRIVMSG - issue
In-Reply-To: <419158100.20060120165546@kr.ru>
References: <419158100.20060120165546@kr.ru>
Message-ID: <b19eae4e0601210635n4342f7ffld1e5e024d72d29a1@mail.gmail.com>

At the gdb prompt, it might be nice if you could provide a 'bt full' output.

On 1/20/06, Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru> wrote:
> Hello, IRC.
>
> Notice: nicknames 'BUG' and 'icancrashit' aren't registered!
>         ^^^^^^^^^                         ^^^^^^^^^^^^^^^^^
>
> [Jan 20 16:48:26.419298 2006] debug: Received: :BUG PRIVMSG NickServ@services.xxx :set secure on
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x84e4900) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> [Jan 20 16:39:13.914246 2006] debug: Received: :icancrashit PRIVMSG NickServ@services.xxx :set language 1
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x8562700) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> --
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From surreal.w00t at gmail.com  Sat Jan 21 06:35:04 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 21 07:02:26 2006
Subject: [IRCServices Coding] crashes on PRIVMSG - issue
In-Reply-To: <419158100.20060120165546@kr.ru>
References: <419158100.20060120165546@kr.ru>
Message-ID: <b19eae4e0601210635n4342f7ffld1e5e024d72d29a1@mail.gmail.com>

At the gdb prompt, it might be nice if you could provide a 'bt full' output.

On 1/20/06, Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru> wrote:
> Hello, IRC.
>
> Notice: nicknames 'BUG' and 'icancrashit' aren't registered!
>         ^^^^^^^^^                         ^^^^^^^^^^^^^^^^^
>
> [Jan 20 16:48:26.419298 2006] debug: Received: :BUG PRIVMSG NickServ@services.xxx :set secure on
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x84e4900) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> [Jan 20 16:39:13.914246 2006] debug: Received: :icancrashit PRIVMSG NickServ@services.xxx :set language 1
>
> Program received signal SIGSEGV, Segmentation fault.
> do_set_ns (u=0x8562700) at modules/nickserv/set.c:70
> 70              ni->usecount++;
>
> --
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From achurch at achurch.org  Sun Jan 22 16:06:16 2006
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 21 23:29:18 2006
Subject: [IRCServices Coding] crashes on PRIVMSG -  issue
In-Reply-To: <419158100.20060120165546@kr.ru>
Message-ID: <43d33442.46014@msgid.achurch.org>

     Fixed, thanks for the report.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hello, IRC.
>
>Notice: nicknames 'BUG' and 'icancrashit' aren't registered!
>        ^^^^^^^^^                         ^^^^^^^^^^^^^^^^^
>
>[Jan 20 16:48:26.419298 2006] debug: Received: :BUG PRIVMSG NickServ@services.xxx :set secure on
>
>Program received signal SIGSEGV, Segmentation fault.
>do_set_ns (u=0x84e4900) at modules/nickserv/set.c:70
>70              ni->usecount++;
>
>[Jan 20 16:39:13.914246 2006] debug: Received: :icancrashit PRIVMSG NickServ@services.xxx :set language 1
>
>Program received signal SIGSEGV, Segmentation fault.
>do_set_ns (u=0x8562700) at modules/nickserv/set.c:70
>70              ni->usecount++;
>
>-- 
>Sincerely,
>Vitaliy Ovsyannikov
>JSC Skala, Krasnoyarsk, Russia
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From achurch at achurch.org  Sun Jan 22 18:53:26 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan 22 02:02:46 2006
Subject: [IRCServices Coding] Services 5.1a4 released
Message-ID: <43d3583a.20704@msgid.achurch.org>

     Services 5.1a4 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

30a8b32b6167c3b8b0406fd90a7379fd  ircservices-5.1a4.tar.gz
2c80ba77d467c92e0adf8c45ec8555a2  ircservices-5.1a4.diff.gz
9aeddd3c19b9218d79c3ff1c84c84e53  ircservices-5.1a4-1.i386.rpm
de096972a124b74fa2bc27b82560f217  ircservices_5.1a4-1_i386.deb

The mirrors should have it shortly.

     Experimental support for the ircd-ratbox IRC server has been added;
testing and bug reports are appreciated.  The convert-db tool has also been
updated for recent releases of other IRC service programs, and to take
advantage of new features introduced in Services 5.1.

Changes in version 5.1a4
------------------------
2006/01/22	Added experimental support for the ircd-ratbox IRC server.
2006/01/22	Fixed crash on NickServ SET/UNSET from unregistered nicks.
		    Reported by Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru>
2006/01/22	Fixed bug causing Services operators in Sirv databases to
		    be imported with Services administrator privileges.
2006/01/22	Overlong IRCS channel names are now handled more robustly
		    in convert-db.
2006/01/22	Added support to the PTlink database importer for SQline
		    and SXline databases.
2006/01/21	The PTlink database importer now imports temporary
		    (unauthenticated) E-mail addresses.
2006/01/21	Updated HybServ database importer for more recent versions
		    of HybServ.
2006/01/20	Fixed bugs in importing channel greetings and the VOPALL
		    setting from Cygnus databases.
2006/01/20	The Cygnus database importer now imports temporary
		    (unauthenticated) E-mail addresses and channel memo
		    levels.
2006/01/18	Moved the contents of the KnownBugs file into the user's
		    manual as Appendix D.
2006/01/18	Removed the (now meaningless) -no-dir-check option to the
		    configure script.
2006/01/17	Fixed a bug in loading the nickgroup database using the
		    database/standard module.  Reported by Vitaliy
		    Ovsyannikov <V.Ovsyannikov@kr.ru>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From Craig at frostycoolslug.com  Sun Jan 22 02:07:10 2006
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sun Jan 22 02:07:20 2006
Subject: [IRCServices Coding] 5.1 Suggestion: Aliases.
Message-ID: <43D3594E.5050308@frostycoolslug.com>

On chatspike, i've modified a few files for 'convieniance' purposes, 
adding things like id -> handle_identify and what not, what would be 
nice, if it were possible to configure some of these in the 
configuration file, rather than having to modifying the core :)

Great work so far :)

--
Craig

From achurch at achurch.org  Sun Jan 22 20:21:01 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan 22 03:30:11 2006
Subject: [IRCServices Coding] 5.1 Suggestion: Aliases.
In-Reply-To: <43D3594E.5050308@frostycoolslug.com>
Message-ID: <43d36cb8.21015@msgid.achurch.org>

>On chatspike, i've modified a few files for 'convieniance' purposes, 
>adding things like id -> handle_identify and what not, what would be 
>nice, if it were possible to configure some of these in the 
>configuration file, rather than having to modifying the core :)

     You could just make a module with something like

extern char *s_NickServ;
int do_privmsg(const char *source, const char *target, char *buf)
{
    if (irc_stricmp(target, s_NickServ) == 0
     && stricmp(buf, "ID", 2)
     && isspace(buf[2]
    ) {
        memmove(buf+8, buf+2, strlen(buf+8));
        memcpy(buf, "IDENTIFY", 8);
    }
    return 0;
}
int init_module()
{
    // ...
    add_callback_pri(NULL, "m_privmsg", do_privmsg, CBPRI_MAX); // called first
    // ...
}

which is rather kludgey in that it relies on `buf' being writeable and
having room for 6 more bytes (which should always be true), but it doesn't
require modifying the core.  I'll think about a more general solution,
though.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From Craig at frostycoolslug.com  Sun Jan 22 03:40:42 2006
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sun Jan 22 03:40:46 2006
Subject: [IRCServices Coding] 5.1 Suggestion: Aliases.
In-Reply-To: <43d36cb8.21015@msgid.achurch.org>
References: <43d36cb8.21015@msgid.achurch.org>
Message-ID: <43D36F3A.2070809@frostycoolslug.com>

I understand that it could be done as a module, and it was in
consideration when i added it in, but in all fairness, it was a choice
between coding, testing, debugging, etc of a module, vs. a one liner
into the nickserv command table. Time was an issue as well, which was
why i made the core choice.

Glad you're thinking about it though :)

Andrew Church wrote:
>> On chatspike, i've modified a few files for 'convieniance' purposes, 
>> adding things like id -> handle_identify and what not, what would be 
>> nice, if it were possible to configure some of these in the 
>> configuration file, rather than having to modifying the core :)
> 
>      You could just make a module with something like
> 
> extern char *s_NickServ;
> int do_privmsg(const char *source, const char *target, char *buf)
> {
>     if (irc_stricmp(target, s_NickServ) == 0
>      && stricmp(buf, "ID", 2)
>      && isspace(buf[2]
>     ) {
>         memmove(buf+8, buf+2, strlen(buf+8));
>         memcpy(buf, "IDENTIFY", 8);
>     }
>     return 0;
> }
> int init_module()
> {
>     // ...
>     add_callback_pri(NULL, "m_privmsg", do_privmsg, CBPRI_MAX); // called first
>     // ...
> }
> 
> which is rather kludgey in that it relies on `buf' being writeable and
> having room for 6 more bytes (which should always be true), but it doesn't
> require modifying the core.  I'll think about a more general solution,
> though.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

From achurch at achurch.org  Sun Jan 22 21:09:29 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Jan 22 04:16:02 2006
Subject: [IRCServices Coding] Nick/channel names in non-ASCII character sets
Message-ID: <43d3777b.21143@msgid.achurch.org>

     There have been a couple of requests for Services to handle nicknames
and channel names in non-English (non-ASCII) character sets.  However, I
went and took a look at a couple of IRC servers (Unreal, Hybrid) that are
supposed to have multiple charset support, and both seem to handle case
translation (upper/lower case) the same way as other IRC servers do.
(I also saw that hybrid-ru does case translation of non-ASCII characters,
but as it's not a general algorithm it's better dealt with by a separate
protocol module, which I'll look into separately if there's a need for it.)

     Is there anyone who uses non-ASCII character sets with Services, and
if so, what problems (if any) have you had that are not ircd-related?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Sun Jan 22 20:29:50 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Sun Jan 22 20:29:43 2006
Subject: [IRCServices Coding] Nick/channel names in non-ASCII character
	sets
In-Reply-To: <43d3777b.21143@msgid.achurch.org>
References: <43d3777b.21143@msgid.achurch.org>
Message-ID: <1514886823.20060123112950@kr.ru>

Hello, IRC.

>      There have been a couple of requests for Services to handle nicknames
> and channel names in non-English (non-ASCII) character sets.  However, I
> went and took a look at a couple of IRC servers (Unreal, Hybrid) that are
> supposed to have multiple charset support, and both seem to handle case
> translation (upper/lower case) the same way as other IRC servers do.
> (I also saw that hybrid-ru does case translation of non-ASCII characters,
> but as it's not a general algorithm it's better dealt with by a separate
> protocol module, which I'll look into separately if there's a need for it.)

>     Is there anyone who uses non-ASCII character sets with Services, and
>if so, what problems (if any) have you had that are not ircd-related?

I'm using ircd-ru (bahamut clone).
Here are the main features I'm configured:

 - DISALLOWED using nicknames that contains latin alphabet characters as
   well as national alphabet ones withing the server

 - DISALLOWED using nicknames that have words which contains latin alphabet
   characters as well as national alphabet ones withing the server

 - DISABLED hashing and comparison of non-ASCII nicknames and channel names using base
   codepage specific lower and upper tables (case insensitive)

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From V.Ovsyannikov at kr.ru  Mon Jan 23 00:14:48 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 23 00:14:19 2006
Subject: [IRCServices Coding] Services 5.1a4 released
In-Reply-To: <43d3583a.20704@msgid.achurch.org>
References: <43d3583a.20704@msgid.achurch.org>
Message-ID: <408967878.20060123151448@kr.ru>

Hello, IRC.

On 23 ?????? 2006 ?., 1:53:26:
>      Services 5.1a4 has been released, and can be downloaded from:

One more critical bug has been discovered:


[Jan 22 00:57:53.965318 2006] debug: Received: :Pascal PRIVMSG
ChanServ@services.xxx :drop #niibatsa

Program received signal SIGSEGV, Segmentation fault.
0x28175200 in strcmp () from /lib/libc.so.6


Channel #niibatsa is registered.

# uname -srm
FreeBSD 6.0-STABLE i386


-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From V.Ovsyannikov at kr.ru  Mon Jan 23 00:18:33 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 23 00:18:02 2006
Subject: [IRCServices Coding] Services 5.1a4 released
In-Reply-To: <408967878.20060123151448@kr.ru>
References: <43d3583a.20704@msgid.achurch.org> <408967878.20060123151448@kr.ru>
Message-ID: <1146416218.20060123151833@kr.ru>

Hello, Vitaliy.

> One more critical bug has been discovered:

Here is backtrace:
#0  0x28175200 in strcmp () from /lib/libc.so.6
#1  0x08050475 in default_check_password (plaintext=0x82ce300 "",
    password=0x82ce300 "") at encrypt.c:72
#2  0x28217f92 in do_drop (u=0x82ce300) at modules/chanserv/main.c:1212
#3  0x28216814 in chanserv (source=0xbfbfe9a0 "unreg",
    target=0xbfbfe768 "ChanServ", buf=0xbfbfe783 "drop")
    at modules/chanserv/main.c:608



-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Mon Jan 23 18:20:06 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jan 23 01:20:32 2006
Subject: [IRCServices Coding] Services 5.1a4 released
In-Reply-To: <408967878.20060123151448@kr.ru>
Message-ID: <43d49fd8.22711@msgid.achurch.org>

>>      Services 5.1a4 has been released, and can be downloaded from:
>
>One more critical bug has been discovered:
>
>
>[Jan 22 00:57:53.965318 2006] debug: Received: :Pascal PRIVMSG
>ChanServ@services.xxx :drop #niibatsa
>
>Program received signal SIGSEGV, Segmentation fault.

     Fixed, thanks for the report.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Mon Jan 23 01:57:49 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 23 01:57:44 2006
Subject: [IRCServices Coding] Services 5.1a4 released
In-Reply-To: <43d49fd8.22711@msgid.achurch.org>
References: <408967878.20060123151448@kr.ru> <43d49fd8.22711@msgid.achurch.org>
Message-ID: <3310332414.20060123165749@kr.ru>

Hello, IRC.

>>[Jan 22 00:57:53.965318 2006] debug: Received: :Pascal PRIVMSG
>>ChanServ@services.xxx :drop #niibatsa
>>
>>Program received signal SIGSEGV, Segmentation fault.

>      Fixed, thanks for the report.

Andrew, be good, post the patch please ;)

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From achurch at achurch.org  Tue Jan 24 02:04:04 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jan 23 09:04:12 2006
Subject: [IRCServices Coding] Services 5.1a4 released
In-Reply-To: <3310332414.20060123165749@kr.ru>
Message-ID: <43d50c84.77310@msgid.achurch.org>

>>>Program received signal SIGSEGV, Segmentation fault.
>
>>      Fixed, thanks for the report.
>
>Andrew, be good, post the patch please ;)

     I'll do you one better and put out a new release. ;)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Jan 24 02:04:13 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jan 23 09:07:08 2006
Subject: [IRCServices Coding] Services 5.1a5 released
Message-ID: <43d50d35.03057@msgid.achurch.org>

     Services 5.1a5 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

54be1dab8e905223cb3621bac8d3c4f9  ircservices-5.1a5.tar.gz
d44c9d865a1492ad6097c525a2514114  ircservices-5.1a5.diff.gz
a623a1fd6a08562dfe4848d136841683  ircservices-5.1a5-1.i386.rpm
b754e7b8d43d22d0b6ee3712fea6b50d  ircservices_5.1a5-1_i386.deb

The mirrors should have it shortly.

     Experimental support for the InspIRCd IRC server has been added;
testing and bug reports are appreciated.  A crash in ChanServ DROP and a
bug causing SET MLOCK to report errors have also been fixed.

Changes in version 5.1a5
------------------------
2006/01/24	Fixed bug causing ChanServ SET MLOCK with extra parameters
		    (like +l NNN) to return a syntax error.
2006/01/23	Added experimental support for the InspIRCd IRC server.
		    Suggested by Craig Edwards <brain@winbot.co.uk>
2006/01/23	Removed misc.c's dependencies on other core symbols, and
		    changed convert-db to link misc.o in rather than
		    redefine strscpy().
2006/01/23	Fixed ChanServ DROP crash.  Reported by Vitaliy Ovsyannikov
		    <V.Ovsyannikov@kr.ru>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Thu Jan 26 21:54:00 2006
From: achurch at achurch.org (Andrew Church)
Date: Thu Jan 26 04:54:37 2006
Subject: [IRCServices Coding] Services 5.1a6 released
Message-ID: <43d8c670.11302@msgid.achurch.org>

     Services 5.1a6 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

eb785d31b835796b26a25cd97d101767  ircservices-5.1a6.tar.gz
88c9c8b39575fc3b85c7019b12510309  ircservices-5.1a6.diff.gz
0f1284896cb3fa5ecef987a601aa6505  ircservices-5.1a6-1.i386.rpm
b9121f03e014b01d543ea6cbd36edca4  ircservices_5.1a6-1_i386.deb

The mirrors should have it shortly.

     Lots of changes in this release, including command aliases for
Nick/Chan/MemoServ, support for Unreal NICKCHARS, and several bug fixes.
Mommy, can I go to sleep now?

Changes in version 5.1a6
------------------------
2006/01/26	Added command aliases for NickServ, ChanServ, and MemoServ
		    via the NSAlias, CSAlias, and MSAlias configuration
		    directives.
2006/01/26	Added support for 2-byte characters in valid_nick() and
		    valid_chan().
2006/01/26	Added support for the Unreal NICKCHARS protocol setting.
2006/01/26	Fixed nickname and channel name validity checking (which
		    was broken for a few protocols).
2006/01/26	valid_nick() now defaults to the reference ircd's rules for
		    nickname grammar rather than RFC 1459.
2006/01/26	Fixed bug causing databases with load-only fields to be
		    written incorrectly.
2006/01/26	Invalid channel names are now automatically removed from
		    the autojoin list on identify.
2006/01/26	Fixed memory leak on corrupt channel autokick database.
2006/01/26	Fixed bug in Hybrid and Ratbox protocol modules causing
		    forced nickname changing to break.
2006/01/25	Moved the contents of the TODO file into section 11 of the
		    technical reference manual.
2006/01/25	Fixed bug causing nick authentication reason to get lost on
		    XML import and export.
2006/01/25	Eliminated SuspendInfo structure (fields flattened into
		    NickGroupInfo and ChannelInfo).
2006/01/25	Fixed bug causing database/standard load routine to break
		    on out-of-order fields.
2006/01/24	Fixed minor bug in handling of InspIRCd SETNAME.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Mon Jan 30 04:31:29 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Jan 30 04:31:22 2006
Subject: [IRCServices Coding] patch for GuestNickPrefix (5.1a5)
Message-ID: <1899483336.20060130193129@kr.ru>

Hello, IRC.

  I've made patch to allow nickserv to change user's nicknames to
original_nickXXXXX instead of GuestXXXXX. Just insert %s into
GuestNickPrefix value in ircservices.conf. %s will be overwritten
by the user's nickname.

patch is attached
Andrew, please check it and merge with src if you want.
(it's for 5.1a5)

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guestprefix.patch
Type: application/octet-stream
Size: 4716 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060130/8ff322c9/guestprefix.obj
From surreal.w00t at gmail.com  Mon Jan 30 06:32:52 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Jan 30 06:33:37 2006
Subject: [IRCServices Coding] patch for GuestNickPrefix (5.1a5)
In-Reply-To: <1899483336.20060130193129@kr.ru>
References: <1899483336.20060130193129@kr.ru>
Message-ID: <b19eae4e0601300632q12bbfcb1j4838facbb65f0ef9@mail.gmail.com>

An interesting idea, but I'd leave it as-is personally so I can
channel-ban Guest* ;p.

On 1/30/06, Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru> wrote:
> Hello, IRC.
>
>   I've made patch to allow nickserv to change user's nicknames to
> original_nickXXXXX instead of GuestXXXXX. Just insert %s into
> GuestNickPrefix value in ircservices.conf. %s will be overwritten
> by the user's nickname.
>
> patch is attached
> Andrew, please check it and merge with src if you want.
> (it's for 5.1a5)
>
> --
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>
>
From stratus at blazeirc.net  Tue Feb 14 20:29:43 2006
From: stratus at blazeirc.net (Jim Stratus)
Date: Tue Feb 14 20:30:01 2006
Subject: [IRCServices Coding] Channel Co-Founder
Message-ID: <004201c631e8$71d75930$7cdb7286@noteryan>

I would really like to see the Channel Co-Founder option re-implemented with 
the XOP mode, like cfounder or something, so that co-founders can set 
channel settings just like the founder and manage the SOP's list.

This was around during SirvNet, and I really liked that option.

Jim Stratus
BlazeIRC Network
www.blazeirc.net 

From achurch at achurch.org  Wed Feb 15 13:33:46 2006
From: achurch at achurch.org (Andrew Church)
Date: Tue Feb 14 20:34:30 2006
Subject: [IRCServices Coding] Channel Co-Founder
In-Reply-To: <004201c631e8$71d75930$7cdb7286@noteryan>
Message-ID: <43f2af4c.35102@msgid.achurch.org>

>I would really like to see the Channel Co-Founder option re-implemented with 
>the XOP mode, like cfounder or something, so that co-founders can set 
>channel settings just like the founder and manage the SOP's list.

     SirvNet was derived from IRC Services, not the other way around.  I
have no plans to implement such a feature.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Mon Mar 13 21:49:23 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Mon Mar 13 21:49:08 2006
Subject: [IRCServices Coding] 5.1a5 new bug
In-Reply-To: <43f2af4c.35102@msgid.achurch.org>
References: <004201c631e8$71d75930$7cdb7286@noteryan>
	<43f2af4c.35102@msgid.achurch.org>
Message-ID: <1748027620.20060314124923@kr.ru>

Hello, IRC.

FreeBSD 6.0-stable

[Mar 13 22:12:21.999580 2006] debug: Received: :keNT PRIVMSG ChanServ@services.irc :AKICK #skala view
[Mar 13 22:12:21.999746 2006] debug: Sent: :ChanServ NOTICE keNT :Autokick list for #skala:

Program received signal SIGSEGV, Segmentation fault.
0x281817e9 in __vfprintf () from /lib/libc.so.6
#0  0x281817e9 in __vfprintf () from /lib/libc.so.6
#1  0x281123f8 in vsnprintf () from /lib/libc.so.6
#2  0x0804ef9b in my_vsnprintf (buf=0xbfbfc9f0 "", len=4096,
    fmt=0x81b956d "    %s (by %s on %s; last used %s)\n        %s",
    args=0xbfbfda1c "\001") at compat.c:52
#3  0x08058fe4 in notice_lang (source=0x834edc0 "ChanServ", dest=0x856aa00,
    message=482) at send.c:266
#4  0x2823075a in do_akick (u=0x856aa00) at modules/chanserv/autokick.c:215
#5  0x2822a824 in chanserv (source=0xbfbfe9c0 "keNT",
    target=0xbfbfe788 "ChanServ", buf=0xbfbfe7a5 "AKICK")
    at modules/chanserv/main.c:608
#6  0x080574f8 in _call_callback_5 (module=0x0, id=-1077950456,
    arg1=0xbfbfe9c0, arg2=0xbfbfe788, arg3=0xbfbfe7a5, arg4=0x0, arg5=0x0)
    at modules.c:819
#7  0x080555d3 in m_privmsg (source=0xbfbfe9c0 "keNT", ac=2, av=0x8543c80)
    at messages.c:256
#8  0x08058a5e in process () at process.c:141
#9  0x0805bae4 in do_callback (s=0x8090100, cb=0x8054c24 <readline_callback>,
    param=0x3d) at sockets.c:1439
#10 0x0805c5bc in check_sockets () at sockets.c:771
#11 0x08054f84 in main (ac=3, av=0xbfbfec40, envp=0xbfbfec50) at main.c:321
#12 0x0804c71e in _start ()


-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From surreal.w00t at gmail.com  Thu Mar 16 12:19:48 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Mar 16 12:21:51 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
Message-ID: <4419C864.9090309@gmail.com>

Hi,

I've seen this happen once or twice, but was never able to reproduce it 
- last night it got a little major, so I thought I'd better send it on 
to the list.

It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
floods. Sometimes, ChanServ wakes up after a while - yesterday this 
wasn't the case...

[04:32:59] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)
[04:33:01] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)
[04:33:04] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)

...

[05:09:41] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)
[05:09:43] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)
[05:09:45] * You were kicked from #helpers by ChanServ (You are not 
permitted to be on this channel.)
[05:09:46] #helpers unable to join channel (address is banned)


That ban being a +b Guest*!*@* set by someone else on the channel.

IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
5.0.55, with some modules, but no core tweaks.

If anyone else has ideas, because this one has me a little stumped...

Thanks,
w00t.
From admin at vonitsanet.gr  Thu Mar 16 16:21:49 2006
From: admin at vonitsanet.gr (Dionisios K.)
Date: Thu Mar 16 16:22:22 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
References: <4419C864.9090309@gmail.com>
Message-ID: <000c01c64958$c9fd2cc0$0100000a@server>

I have seen it too but i'm unable to reproduce it.

----- Original Message ----- 
From: "Robin Burchell" <surreal.w00t@gmail.com>
To: <ircservices-coding@ircservices.esper.net>
Sent: Thursday, March 16, 2006 10:19 PM
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw


> Hi,
> 
> I've seen this happen once or twice, but was never able to reproduce it 
> - last night it got a little major, so I thought I'd better send it on 
> to the list.
> 
> It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
> doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
> floods. Sometimes, ChanServ wakes up after a while - yesterday this 
> wasn't the case...
> 
> [04:32:59] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [04:33:01] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [04:33:04] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> 
> ...
> 
> [05:09:41] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:43] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:45] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:46] #helpers unable to join channel (address is banned)
> 
> 
> That ban being a +b Guest*!*@* set by someone else on the channel.
> 
> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
> 5.0.55, with some modules, but no core tweaks.
> 
> If anyone else has ideas, because this one has me a little stumped...
> 
> Thanks,
> w00t.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From lordbergee at comcast.net  Thu Mar 16 18:09:34 2006
From: lordbergee at comcast.net (Bergee)
Date: Thu Mar 16 18:09:55 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <000c01c64958$c9fd2cc0$0100000a@server>
References: <4419C864.9090309@gmail.com>
	<000c01c64958$c9fd2cc0$0100000a@server>
Message-ID: <441A1A5E.7080506@comcast.net>

	For what it's worth, I've had users report this to me as well but I 
have had no luck in reproducing it.  I should add that I don't remember 
it happening lately -- but it was quite rare to begin with so that may 
not mean anything.

Bergee

Dionisios K. wrote:
> I have seen it too but i'm unable to reproduce it.
> 
> ----- Original Message ----- From: "Robin Burchell" 
> <surreal.w00t@gmail.com>
> To: <ircservices-coding@ircservices.esper.net>
> Sent: Thursday, March 16, 2006 10:19 PM
> Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
> 
> 
>> Hi,
>>
>> I've seen this happen once or twice, but was never able to reproduce 
>> it - last night it got a little major, so I thought I'd better send it 
>> on to the list.
>>
>> It appears sometimes on a violation of AKICK or SET RESTRICTED, 
>> ChanServ doesn't add a +b to the channel, leading to fun endless 
>> JOIN/KICK floods. Sometimes, ChanServ wakes up after a while - 
>> yesterday this wasn't the case...
>>
>> [04:32:59] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [04:33:01] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [04:33:04] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>>
>> ...
>>
>> [05:09:41] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:43] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:45] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:46] #helpers unable to join channel (address is banned)
>>
>>
>> That ban being a +b Guest*!*@* set by someone else on the channel.
>>
>> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
>> 5.0.55, with some modules, but no core tweaks.
>>
>> If anyone else has ideas, because this one has me a little stumped...
>>
>> Thanks,
>> w00t.
From surreal.w00t at gmail.com  Thu Mar 16 20:10:13 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Mar 16 20:10:20 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <441A1A5E.7080506@comcast.net>
References: <4419C864.9090309@gmail.com>
	<000c01c64958$c9fd2cc0$0100000a@server> <441A1A5E.7080506@comcast.net>
Message-ID: <b19eae4e0603162010t74ebc82ct378d879a42f091d0@mail.gmail.com>

Yeah, agreed. It doesn't happen often (though admittedly I don't get
AKICKed or forget to identify fairly often -- this one happened while
I was asleep) -- but I guess I see this happen every few months or so.

On 3/17/06, Bergee <lordbergee@comcast.net> wrote:
>         For what it's worth, I've had users report this to me as well but I
> have had no luck in reproducing it.  I should add that I don't remember
> it happening lately -- but it was quite rare to begin with so that may
> not mean anything.
>
> Bergee
>
> Dionisios K. wrote:
> > I have seen it too but i'm unable to reproduce it.
From xxx.coder at gmail.com  Fri Mar 17 02:15:51 2006
From: xxx.coder at gmail.com (ongeboren)
Date: Fri Mar 17 02:16:00 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <4419C864.9090309@gmail.com>
References: <4419C864.9090309@gmail.com>
Message-ID: <ce6d53600603170215s5bdcaaaaq6a4c813fc1fe0fdd@mail.gmail.com>

No idea how ircservices are doing it (as they do not join channels)..
but if the channel is just recreated on join, kicking the only person
will destroy the channel and all associated bans (at least on hybserv
based ircds, /me never used unreal).

On 3/16/06, Robin Burchell <surreal.w00t@gmail.com> wrote:
> Hi,
>
> I've seen this happen once or twice, but was never able to reproduce it
> - last night it got a little major, so I thought I'd better send it on
> to the list.
>
> It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ
> doesn't add a +b to the channel, leading to fun endless JOIN/KICK
> floods. Sometimes, ChanServ wakes up after a while - yesterday this
> wasn't the case...
>
> [04:32:59] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
> [04:33:01] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
> [04:33:04] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
>
> ...
>
> [05:09:41] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
> [05:09:43] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
> [05:09:45] * You were kicked from #helpers by ChanServ (You are not
> permitted to be on this channel.)
> [05:09:46] #helpers unable to join channel (address is banned)
>
>
> That ban being a +b Guest*!*@* set by someone else on the channel.
>
> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at
> 5.0.55, with some modules, but no core tweaks.
>
> If anyone else has ideas, because this one has me a little stumped...
>
> Thanks,
> w00t.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>


--
Evlogi Petrov - ongeboren@UniBG
From phan70m at gmail.com  Fri Mar 17 07:13:38 2006
From: phan70m at gmail.com (Anton Wolkov)
Date: Fri Mar 17 07:13:54 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <ce6d53600603170215s5bdcaaaaq6a4c813fc1fe0fdd@mail.gmail.com>
References: <4419C864.9090309@gmail.com>
	<ce6d53600603170215s5bdcaaaaq6a4c813fc1fe0fdd@mail.gmail.com>
Message-ID: <d50f59a00603170713n32a3ccf4qf7590527985e7507@mail.gmail.com>

i actually done my homework on this one
it's a sync issue of unreal 3.2+
it sends bans and exceptions and invexes inside SJOIN in a very wierd format
and from time to time looses a leaf's settings. so as i get it it's only an
issue of miltiple leafs linked.
basicly there's another issue of service not being able to understand
extended ban ~c and extended ban ~r which are another reason why this might
happen.
~c:#channel*name should be check against all channel names the user is in
and ~r:real_n*ame should be check against the realname of the user having
all spaces replaced to _. other extended bans don't affect joining.

On 3/17/06, ongeboren <xxx.coder@gmail.com> wrote:
>
> No idea how ircservices are doing it (as they do not join channels)..
> but if the channel is just recreated on join, kicking the only person
> will destroy the channel and all associated bans (at least on hybserv
> based ircds, /me never used unreal).
>
> On 3/16/06, Robin Burchell <surreal.w00t@gmail.com> wrote:
> > Hi,
> >
> > I've seen this happen once or twice, but was never able to reproduce it
> > - last night it got a little major, so I thought I'd better send it on
> > to the list.
> >
> > It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ
> > doesn't add a +b to the channel, leading to fun endless JOIN/KICK
> > floods. Sometimes, ChanServ wakes up after a while - yesterday this
> > wasn't the case...
> >
> > [04:32:59] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> > [04:33:01] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> > [04:33:04] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> >
> > ...
> >
> > [05:09:41] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> > [05:09:43] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> > [05:09:45] * You were kicked from #helpers by ChanServ (You are not
> > permitted to be on this channel.)
> > [05:09:46] #helpers unable to join channel (address is banned)
> >
> >
> > That ban being a +b Guest*!*@* set by someone else on the channel.
> >
> > IRCd is Unreal (3.2.2b, for the terminally curious) - services are at
> > 5.0.55, with some modules, but no core tweaks.
> >
> > If anyone else has ideas, because this one has me a little stumped...
> >
> > Thanks,
> > w00t.
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> >
>
>
> --
> Evlogi Petrov - ongeboren@UniBG
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060317/e562d41b/attachment.html
From surreal.w00t at gmail.com  Fri Mar 17 21:32:33 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Fri Mar 17 21:34:05 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <ce6d53600603170215s5bdcaaaaq6a4c813fc1fe0fdd@mail.gmail.com>
References: <4419C864.9090309@gmail.com>
	<ce6d53600603170215s5bdcaaaaq6a4c813fc1fe0fdd@mail.gmail.com>
Message-ID: <441B9B71.5060006@gmail.com>

ongeboren wrote:
> No idea how ircservices are doing it (as they do not join channels)..
> but if the channel is just recreated on join, kicking the only person
> will destroy the channel and all associated bans (at least on hybserv
> based ircds, /me never used unreal).

Correct; but this is not the issue. This channel had ~10 other people on 
there, and I've seen it happen on larger.

From dnb at majestic-liaisons.com  Sat Mar 18 03:12:00 2006
From: dnb at majestic-liaisons.com (DeadNotBuried)
Date: Sat Mar 18 03:11:40 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <4419C864.9090309@gmail.com>
References: <4419C864.9090309@gmail.com>
Message-ID: <441BEB00.10507@majestic-liaisons.com>

I've seen this myself when services kicked someone on a channel akick 
list (set restricted off), after restarting services it did add the ban 
the next time the user joined. having only seen it once and nothing else 
out of the ordinary happening it seems impossible to reproduce at whim.

this was also on 5.0.55 stock standard no modules, using Unreal 3.2.3

DNB

Robin Burchell wrote:
> Hi,
> 
> I've seen this happen once or twice, but was never able to reproduce it 
> - last night it got a little major, so I thought I'd better send it on 
> to the list.
> 
> It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
> doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
> floods. Sometimes, ChanServ wakes up after a while - yesterday this 
> wasn't the case...
> 
> [04:32:59] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [04:33:01] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [04:33:04] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> 
> ...
> 
> [05:09:41] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:43] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:45] * You were kicked from #helpers by ChanServ (You are not 
> permitted to be on this channel.)
> [05:09:46] #helpers unable to join channel (address is banned)
> 
> 
> That ban being a +b Guest*!*@* set by someone else on the channel.
> 
> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
> 5.0.55, with some modules, but no core tweaks.
> 
> If anyone else has ideas, because this one has me a little stumped...
> 
> Thanks,
> w00t.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

From achurch at achurch.org  Sun Mar 19 17:19:37 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Mar 19 00:46:52 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <4419C864.9090309@gmail.com>
Message-ID: <441d1a6e.14045@msgid.achurch.org>

     The most likely possibility (on Services' side) is that the channel
in question has an extended exception that doesn't include a usermask,
such as c: or r:.  To be honest, I'm at a loss at what to do about these,
especially since Unreal allows modules to add further types; for 5.1 I'm
half-inclined to just forbid extended bans/exceptions entirely (by
clearing anything that users try to set), but I'd be interested in hearing
other ideas.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hi,
>
>I've seen this happen once or twice, but was never able to reproduce it 
>- last night it got a little major, so I thought I'd better send it on 
>to the list.
>
>It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
>doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
>floods. Sometimes, ChanServ wakes up after a while - yesterday this 
>wasn't the case...
>
>[04:32:59] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>[04:33:01] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>[04:33:04] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>
>...
>
>[05:09:41] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>[05:09:43] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>[05:09:45] * You were kicked from #helpers by ChanServ (You are not 
>permitted to be on this channel.)
>[05:09:46] #helpers unable to join channel (address is banned)
>
>
>That ban being a +b Guest*!*@* set by someone else on the channel.
>
>IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
>5.0.55, with some modules, but no core tweaks.
>
>If anyone else has ideas, because this one has me a little stumped...
>
>Thanks,
>w00t.
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From achurch at achurch.org  Sun Mar 19 17:47:59 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Mar 19 00:50:38 2006
Subject: Debug patch (Re: [IRCServices Coding] SET RESTRICTED,
	and possibly AKICK flaw)
In-Reply-To: <4419C864.9090309@gmail.com>
Message-ID: <441d1b58.14650@msgid.achurch.org>

     With regard to the AKICK issue, if someone could apply the patch below
to modules/chanserv/check.c and post the debug log messages generated when
the problem occurs, I'd appreciate it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

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

Index: modules/chanserv/check.c
===================================================================
RCS file: /var/local/cvsroot/ircservices/modules/chanserv/check.c,v
retrieving revision 2.59.2.8
diff -u -r2.59.2.8 check.c
--- modules/chanserv/check.c	8 Jan 2006 16:48:13 -0000	2.59.2.8
+++ modules/chanserv/check.c	19 Mar 2006 08:50:18 -0000
@@ -410,6 +410,8 @@
 	clear_channel(c, CLEAR_EXCEPTS, user);
     /* Apparently invites can get around bans, so check for ban first */
     if (!chan_has_ban(chan, mask)) {
+	module_log("[DEBUG] check_kick: adding ban [%s] to channel [%s]"
+		   " for nick [%s]", mask, chan, user->nick);
 	send_cmode_cmd(s_ChanServ, chan, "+b %s", mask);
 	if (c) {
 	    char *av[3];
@@ -418,6 +420,21 @@
 	    av[2] = mask;
 	    do_cmode(s_ChanServ, 3, av);
 	}
+    } else {
+	module_log("[DEBUG] check_kick: NOT adding ban [%s] to channel [%s]"
+		   " for user [%s]", mask, chan, user->nick);
+	module_log("[DEBUG]    ban list:");
+	if (c) {
+	    int i;
+	    ARRAY_FOREACH (i, c->bans)
+		module_log("[DEBUG]       %s", c->bans[i]);
+	}
+	module_log("[DEBUG]    exception list:");
+	if (c) {
+	    int i;
+	    ARRAY_FOREACH (i, c->excepts)
+		module_log("[DEBUG]       %s", c->bans[i]);
+	}
     }
     free(mask);
     send_channel_cmd(s_ChanServ, "KICK %s %s :%s", chan, user->nick, reason);
From dnb at majestic-liaisons.com  Sun Mar 19 00:55:23 2006
From: dnb at majestic-liaisons.com (DeadNotBuried)
Date: Sun Mar 19 00:54:44 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <441d1a6e.14045@msgid.achurch.org>
References: <441d1a6e.14045@msgid.achurch.org>
Message-ID: <441D1C7B.5060201@majestic-liaisons.com>

fyi : the only time i have seen this happen there were no normal or
extended bans at all placed on the channel at the time.

DNB

Andrew Church wrote:
>      The most likely possibility (on Services' side) is that the channel
> in question has an extended exception that doesn't include a usermask,
> such as c: or r:.  To be honest, I'm at a loss at what to do about these,
> especially since Unreal allows modules to add further types; for 5.1 I'm
> half-inclined to just forbid extended bans/exceptions entirely (by
> clearing anything that users try to set), but I'd be interested in hearing
> other ideas.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> 
>> Hi,
>>
>> I've seen this happen once or twice, but was never able to reproduce it 
>> - last night it got a little major, so I thought I'd better send it on 
>> to the list.
>>
>> It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
>> doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
>> floods. Sometimes, ChanServ wakes up after a while - yesterday this 
>> wasn't the case...
>>
>> [04:32:59] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [04:33:01] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [04:33:04] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>>
>> ...
>>
>> [05:09:41] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:43] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:45] * You were kicked from #helpers by ChanServ (You are not 
>> permitted to be on this channel.)
>> [05:09:46] #helpers unable to join channel (address is banned)
>>
>>
>> That ban being a +b Guest*!*@* set by someone else on the channel.
>>
>> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
>> 5.0.55, with some modules, but no core tweaks.
>>
>> If anyone else has ideas, because this one has me a little stumped...
>>
>> Thanks,
>> w00t.
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

From lordbergee at comcast.net  Sun Mar 19 05:49:57 2006
From: lordbergee at comcast.net (Bergee)
Date: Sun Mar 19 05:50:09 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <441D1C7B.5060201@majestic-liaisons.com>
References: <441d1a6e.14045@msgid.achurch.org>
	<441D1C7B.5060201@majestic-liaisons.com>
Message-ID: <441D6185.6090708@comcast.net>

	Indeed, I recall the channel that this happened on having no bans at
all.  Or well, the IRC server didn't think there were any...
	I'd also like to throw a note that it would be highly annoying to have
Services up and remove all extended bans that user's place.  I think
it's something that can pretty much be accepted that if one installs a
module that adds an extended ban -- it simply won't work with Services.
 I'd rather see support for the built in extended bans and simply ignore
other extended bans.  Or perhaps only do that when a configuration
option is set to ignore them so that an administrator must understand
the ramifications of doing so.  And if that isn't set, remove unknown
extended bans.  I don't feel like this is a "good solution" but I feel
like outright removing support for extended bans is a far worse one.

Bergee

DeadNotBuried wrote:
> fyi : the only time i have seen this happen there were no normal or
> extended bans at all placed on the channel at the time.
> 
> DNB
> 
> Andrew Church wrote:
>>      The most likely possibility (on Services' side) is that the channel
>> in question has an extended exception that doesn't include a usermask,
>> such as c: or r:.  To be honest, I'm at a loss at what to do about these,
>> especially since Unreal allows modules to add further types; for 5.1 I'm
>> half-inclined to just forbid extended bans/exceptions entirely (by
>> clearing anything that users try to set), but I'd be interested in hearing
>> other ideas.
>>
>>   --Andrew Church
>>     achurch@achurch.org
>>     http://achurch.org/
>>
>>> Hi,
>>>
>>> I've seen this happen once or twice, but was never able to reproduce it 
>>> - last night it got a little major, so I thought I'd better send it on 
>>> to the list.
>>>
>>> It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
>>> doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
>>> floods. Sometimes, ChanServ wakes up after a while - yesterday this 
>>> wasn't the case...
>>>
>>> [04:32:59] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>> [04:33:01] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>> [04:33:04] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>>
>>> ...
>>>
>>> [05:09:41] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>> [05:09:43] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>> [05:09:45] * You were kicked from #helpers by ChanServ (You are not 
>>> permitted to be on this channel.)
>>> [05:09:46] #helpers unable to join channel (address is banned)
>>>
>>>
>>> That ban being a +b Guest*!*@* set by someone else on the channel.
>>>
>>> IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
>>> 5.0.55, with some modules, but no core tweaks.
>>>
>>> If anyone else has ideas, because this one has me a little stumped...
>>>
>>> Thanks,
>>> w00t.
From surreal.w00t at gmail.com  Sun Mar 19 12:12:22 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sun Mar 19 12:14:02 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <441D1C7B.5060201@majestic-liaisons.com>
References: <441d1a6e.14045@msgid.achurch.org>
	<441D1C7B.5060201@majestic-liaisons.com>
Message-ID: <441DBB26.9010902@gmail.com>

Indeed, banlist:

#helpers guest*!*@* set by Ib (Fri Mar 17 05:10:52)
#helpers *!viroteck@*.AA6527E2.37EDBD53.IP set by ChanServ (Thu Mar 16
18:31:07)
#helpers *!Pete@*.6819D140.C57AC8D4.IP set by ChanServ (Thu Mar 16 13:35:25)
#helpers End of Channel Ban List

guest*!*@* being the one that matched me eventually. All standard bans.

DeadNotBuried wrote:
> fyi : the only time i have seen this happen there were no normal or
> extended bans at all placed on the channel at the time.
> 
> DNB
> 
> Andrew Church wrote:
> 
>>     The most likely possibility (on Services' side) is that the channel
>>in question has an extended exception that doesn't include a usermask,
>>such as c: or r:.  To be honest, I'm at a loss at what to do about these,
>>especially since Unreal allows modules to add further types; for 5.1 I'm
>>half-inclined to just forbid extended bans/exceptions entirely (by
>>clearing anything that users try to set), but I'd be interested in hearing
>>other ideas.
>>
>>  --Andrew Church
>>    achurch@achurch.org
>>    http://achurch.org/
>>
>>
>>>Hi,
>>>
>>>I've seen this happen once or twice, but was never able to reproduce it 
>>>- last night it got a little major, so I thought I'd better send it on 
>>>to the list.
>>>
>>>It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ 
>>>doesn't add a +b to the channel, leading to fun endless JOIN/KICK 
>>>floods. Sometimes, ChanServ wakes up after a while - yesterday this 
>>>wasn't the case...
>>>
>>>[04:32:59] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>[04:33:01] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>[04:33:04] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>
>>>...
>>>
>>>[05:09:41] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>[05:09:43] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>[05:09:45] * You were kicked from #helpers by ChanServ (You are not 
>>>permitted to be on this channel.)
>>>[05:09:46] #helpers unable to join channel (address is banned)
>>>
>>>
>>>That ban being a +b Guest*!*@* set by someone else on the channel.
>>>
>>>IRCd is Unreal (3.2.2b, for the terminally curious) - services are at 
>>>5.0.55, with some modules, but no core tweaks.
>>>
>>>If anyone else has ideas, because this one has me a little stumped...
>>>
>>>Thanks,
>>>w00t.
>>>------------------------------------------------------------------
>>>To unsubscribe or change your subscription options, visit:
>>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>>
> 
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 

From phan70m at gmail.com  Mon Mar 20 11:08:07 2006
From: phan70m at gmail.com (Anton Wolkov)
Date: Mon Mar 20 11:08:34 2006
Subject: [IRCServices Coding] SET RESTRICTED, and possibly AKICK flaw
In-Reply-To: <441d1a6e.14045@msgid.achurch.org>
References: <4419C864.9090309@gmail.com> <441d1a6e.14045@msgid.achurch.org>
Message-ID: <d50f59a00603201108s6a9be3c7n6f81199325a373b8@mail.gmail.com>

I believe services should work with default configuration, adding additional
extended bans is done via modules and with the exception of the regexp
ban/exception i've seen, almost none of them block join, thus i recommend
supporting the 2 defaults, channel and realname.

On 3/19/06, Andrew Church <achurch@achurch.org> wrote:
>
>      The most likely possibility (on Services' side) is that the channel
> in question has an extended exception that doesn't include a usermask,
> such as c: or r:.  To be honest, I'm at a loss at what to do about these,
> especially since Unreal allows modules to add further types; for 5.1 I'm
> half-inclined to just forbid extended bans/exceptions entirely (by
> clearing anything that users try to set), but I'd be interested in hearing
> other ideas.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
>
> >Hi,
> >
> >I've seen this happen once or twice, but was never able to reproduce it
> >- last night it got a little major, so I thought I'd better send it on
> >to the list.
> >
> >It appears sometimes on a violation of AKICK or SET RESTRICTED, ChanServ
> >doesn't add a +b to the channel, leading to fun endless JOIN/KICK
> >floods. Sometimes, ChanServ wakes up after a while - yesterday this
> >wasn't the case...
> >
> >[04:32:59] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >[04:33:01] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >[04:33:04] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >
> >...
> >
> >[05:09:41] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >[05:09:43] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >[05:09:45] * You were kicked from #helpers by ChanServ (You are not
> >permitted to be on this channel.)
> >[05:09:46] #helpers unable to join channel (address is banned)
> >
> >
> >That ban being a +b Guest*!*@* set by someone else on the channel.
> >
> >IRCd is Unreal (3.2.2b, for the terminally curious) - services are at
> >5.0.55, with some modules, but no core tweaks.
> >
> >If anyone else has ideas, because this one has me a little stumped...
> >
> >Thanks,
> >w00t.
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060320/1d4e2f10/attachment.htm
From achurch at achurch.org  Sun Mar 26 11:55:03 2006
From: achurch at achurch.org (Andrew Church)
Date: Sat Mar 25 18:57:02 2006
Subject: [IRCServices Coding] Re: GLOBOPS error on server and services
In-Reply-To: <44257E53.2080201@gmail.com>
Message-ID: <442602eb.24363@msgid.achurch.org>

[moved from the main list]

>The mismatched modules error.. I'm guessing you're using InspIRCd from 
>that error? - Load the `globops' module in your ircd configuration.

     While we're on this, what changes need to be made to the default
InspIRCD configuration to work with the Services module?  Is there any way
to detect the presence or absence of these modules to avoid disconnections
like this?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Sat Mar 25 20:01:57 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Mar 25 19:03:16 2006
Subject: [IRCServices Coding] Re: GLOBOPS error on server and services
In-Reply-To: <442602eb.24363@msgid.achurch.org>
References: <442602eb.24363@msgid.achurch.org>
Message-ID: <44261235.3060101@gmail.com>

Andrew Church wrote:
> [moved from the main list]
> 
> 
>>The mismatched modules error.. I'm guessing you're using InspIRCd from 
>>that error? - Load the `globops' module in your ircd configuration.
> 
> 
>      While we're on this, what changes need to be made to the default
> InspIRCD configuration to work with the Services module?  Is there any way
> to detect the presence or absence of these modules to avoid disconnections
> like this?
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


Yes, by looking at the CABAP message sent on connection you would be
able to error out if the IRCd didn't have the appropriate modules. See:

http://www.inspircd.org/wiki/InspIRCd_Spanning_Tree_%28Beta_6%29#CAPAB
From farklem at gmail.com  Tue Mar 28 09:11:55 2006
From: farklem at gmail.com (Jason farklem)
Date: Tue Mar 28 09:12:04 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
Message-ID: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>

I am working on a bunch of modules (all of which are going very well).  2 of
my modules need to be able to see all PMs sent to a channel (not just
messages that start with !).  I'm just wondering if there is a way to do
this within the module itself.  I am trying to avoid modding the ircservices
code.

I also wanted to thank the makers of ircservices, I think it provides the
best services for IRC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060328/bfeca37c/attachment.htm
From surreal.w00t at gmail.com  Tue Mar 28 10:16:21 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Tue Mar 28 09:17:41 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
In-Reply-To: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>
References: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>
Message-ID: <44297D75.5020906@gmail.com>

Jason farklem wrote:
> I am working on a bunch of modules (all of which are going very well).  
> 2 of my modules need to be able to see all PMs sent to a channel (not 
> just messages that start with !).  I'm just wondering if there is a way 
> to do this within the module itself.  I am trying to avoid modding the 
> ircservices code.
> 
> I also wanted to thank the makers of ircservices, I think it provides 
> the best services for IRC.

You will need to get a Services pseudoclient to join that channel, 
unless you're using some form of bizarre, horribly modified IRCd.
From farklem at gmail.com  Tue Mar 28 09:35:28 2006
From: farklem at gmail.com (Jason farklem)
Date: Tue Mar 28 09:35:36 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
In-Reply-To: <44297D75.5020906@gmail.com>
References: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>
	<44297D75.5020906@gmail.com>
Message-ID: <ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>

This is my first time using a mailing list so I hope I am replying correctly
(sorry if I'm not).  I allready have the pseudoclient join the channel.  But
the m_privmsg callback only picks up on channel messages that start with !.
It assumes that anything after the ! is a command.

On 3/28/06, Robin Burchell <surreal.w00t@gmail.com> wrote:
>
> Jason farklem wrote:
> > I am working on a bunch of modules (all of which are going very well).
> > 2 of my modules need to be able to see all PMs sent to a channel (not
> > just messages that start with !).  I'm just wondering if there is a way
> > to do this within the module itself.  I am trying to avoid modding the
> > ircservices code.
> >
> > I also wanted to thank the makers of ircservices, I think it provides
> > the best services for IRC.
>
> You will need to get a Services pseudoclient to join that channel,
> unless you're using some form of bizarre, horribly modified IRCd.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060328/368c639e/attachment.html
From Craig at frostycoolslug.com  Tue Mar 28 09:37:30 2006
From: Craig at frostycoolslug.com (Craig McLure)
Date: Tue Mar 28 09:39:39 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
In-Reply-To: <ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>
References: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>	<44297D75.5020906@gmail.com>
	<ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>
Message-ID: <4429745A.9040904@frostycoolslug.com>

seems somewhat odd behavior.. What version of IRCServices are you using? 
Also, make sure your pseudoclient doesn't have the +d user mode (deaf, 
only applies to some IRCds)

Jason farklem wrote:
> This is my first time using a mailing list so I hope I am replying correctly
> (sorry if I'm not).  I allready have the pseudoclient join the channel.  But
> the m_privmsg callback only picks up on channel messages that start with !.
> It assumes that anything after the ! is a command.
> 
> On 3/28/06, Robin Burchell <surreal.w00t@gmail.com> wrote:
>> Jason farklem wrote:
>>> I am working on a bunch of modules (all of which are going very well).
>>> 2 of my modules need to be able to see all PMs sent to a channel (not
>>> just messages that start with !).  I'm just wondering if there is a way
>>> to do this within the module itself.  I am trying to avoid modding the
>>> ircservices code.
>>>
>>> I also wanted to thank the makers of ircservices, I think it provides
>>> the best services for IRC.
>> You will need to get a Services pseudoclient to join that channel,
>> unless you're using some form of bizarre, horribly modified IRCd.
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding

From surreal.w00t at gmail.com  Tue Mar 28 10:41:24 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Tue Mar 28 09:42:39 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
In-Reply-To: <ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>
References: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>	<44297D75.5020906@gmail.com>
	<ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>
Message-ID: <44298354.10103@gmail.com>

I'm sure you'll find that is IRCd behaviour, and not Services. Services 
don't expect to recieve any channel messages, so the '!' behaviour won't 
be built in there.

I've done similar before, so I know this is the case ;p.

Jason farklem wrote:
> This is my first time using a mailing list so I hope I am replying 
> correctly (sorry if I'm not).  I allready have the pseudoclient join the 
> channel.  But the m_privmsg callback only picks up on channel messages 
> that start with !.  It assumes that anything after the ! is a command.
From farklem at gmail.com  Tue Mar 28 09:59:43 2006
From: farklem at gmail.com (Jason farklem)
Date: Tue Mar 28 09:59:56 2006
Subject: [IRCServices Coding] Recieving all PRIVMSG
In-Reply-To: <44298354.10103@gmail.com>
References: <ce4fe3510603280911l19a1aa6dj25de6a443ce83a04@mail.gmail.com>
	<44297D75.5020906@gmail.com>
	<ce4fe3510603280935h252c10b4r2c6dd9c0aa8f293@mail.gmail.com>
	<44298354.10103@gmail.com>
Message-ID: <ce4fe3510603280959x1f25e3dbp5fe7607872d4b204@mail.gmail.com>

Thanks everyone, it was mode d (unreal ircd) that was causing the problem.
For unreal, by default mode d will let the client recieve anything starting
with !.

On 3/28/06, Robin Burchell <surreal.w00t@gmail.com> wrote:
>
> I'm sure you'll find that is IRCd behaviour, and not Services. Services
> don't expect to recieve any channel messages, so the '!' behaviour won't
> be built in there.
>
> I've done similar before, so I know this is the case ;p.
>
> Jason farklem wrote:
> > This is my first time using a mailing list so I hope I am replying
> > correctly (sorry if I'm not).  I allready have the pseudoclient join the
> > channel.  But the m_privmsg callback only picks up on channel messages
> > that start with !.  It assumes that anything after the ! is a command.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060328/f1864026/attachment.htm
From fuzk at ukr.net  Wed Mar 29 16:30:07 2006
From: fuzk at ukr.net (fuzk)
Date: Wed Mar 29 16:30:35 2006
Subject: [IRCServices Coding] some strange bug
Message-ID: <E1FOl39-0009uu-Nq@giper.ukr.net>

Hello.

I get a strange bug... Raw log included:

fuzk@kolibri (03:02:03):~$ nc somehost 6667
...
PRIVMSG NickServ :IDENTIFY *****somepass*******
:NickServ!service@UAnet NOTICE EvilZluk :Password accepted -- you are now recognized.

NICK SomeTester_SomeTester_SomeTester_SomeTester_SomeTester_SomeTester_SomeTester_SomeTester_SomeTester_SomeTester
:EvilZluk!~fuzk@intellect2-gw.ci.ukrpack.net NICK :SomeTester_SomeTester_SomeTester

PRIVMSG NickServ :HELP
:NickServ!service@UAnet NOTICE SomeTester_SomeTester_SomeTester :Internal error - unable to process request

NICK BlaBla
:SomeTester_SomeTester_SomeTester!~fuzk@intellect2-gw.ci.ukrpack.net NICK :BlaBla

PRIVMSG NickServ :HELP
:NickServ!service@UAnet NOTICE BlaBla :Internal error - unable to process request


This bug is presents prior to ircservices-5.0.57...
-----------
Best regargs, Konstantin.

From farklem at gmail.com  Wed Mar 29 19:54:28 2006
From: farklem at gmail.com (Jason farklem)
Date: Wed Mar 29 19:54:38 2006
Subject: [IRCServices Coding] Finding the modes set via channel mode change
Message-ID: <ce4fe3510603291954n7360557obfdb01edc786e0e5@mail.gmail.com>

I am about 99% done with my LogServ module but I have run into 2 issues.

1.  I can't find out how to get the channel mode changes that were made to
the channel using the "channel mode change" callback:
static int do_channel_mode_change(const char *source, Channel *c);

2.  This module logs user joins but everytime ircservices starts up, the
join callback is called for each user that is allready in the channel.  I
tried using is_on_chan() but I guess until services has fully started up, it
doesn't realize that the users are in the channel.

Thanks for everyone's help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060329/191bcdc9/attachment.html
From achurch at achurch.org  Thu Mar 30 13:01:23 2006
From: achurch at achurch.org (Andrew Church)
Date: Wed Mar 29 20:05:03 2006
Subject: [IRCServices Coding] Finding the modes set via channel mode change
In-Reply-To: <ce4fe3510603291954n7360557obfdb01edc786e0e5@mail.gmail.com>
Message-ID: <442b58e8.10274@msgid.achurch.org>

>1.  I can't find out how to get the channel mode changes that were made to
>the channel using the "channel mode change" callback:
>static int do_channel_mode_change(const char *source, Channel *c);

     The callback only informs you of the fact that the modes have changed.
If you want to know exactly what has changed, you'll need to keep your own
copy of the modes (c->mode) for each channel.  I may change this for 5.1.

>2.  This module logs user joins but everytime ircservices starts up, the
>join callback is called for each user that is allready in the channel.  I
>tried using is_on_chan() but I guess until services has fully started up, it
>doesn't realize that the users are in the channel.

     This is because of the way IRC works: when a server joins the network,
all users are treated as if they had just joined the channels they are in.
There's no way around this without rewriting the IRC protocol.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From farklem at gmail.com  Wed Mar 29 20:49:26 2006
From: farklem at gmail.com (Jason farklem)
Date: Wed Mar 29 20:49:34 2006
Subject: [IRCServices Coding] Finding the modes set via channel mode change
In-Reply-To: <442b58e8.10274@msgid.achurch.org>
References: <ce4fe3510603291954n7360557obfdb01edc786e0e5@mail.gmail.com>
	<442b58e8.10274@msgid.achurch.org>
Message-ID: <ce4fe3510603292049p2ae0ba47ya709838f2c424054@mail.gmail.com>

Thank you very much Andrew.  I do have on last question that I forgot to ask
earlier.  Is it possible to see the source of a channel kick with the
"channel KICK" callback? Basicly the user that did the kick is what I am
referring to.
static int do_channel_kick(Channel *c, User *u, const char *reason);

On 3/29/06, Andrew Church <achurch@achurch.org> wrote:
>
> >1.  I can't find out how to get the channel mode changes that were made
> to
> >the channel using the "channel mode change" callback:
> >static int do_channel_mode_change(const char *source, Channel *c);
>
>      The callback only informs you of the fact that the modes have
> changed.
> If you want to know exactly what has changed, you'll need to keep your own
> copy of the modes (c->mode) for each channel.  I may change this for 5.1.
>
> >2.  This module logs user joins but everytime ircservices starts up, the
> >join callback is called for each user that is allready in the channel.  I
> >tried using is_on_chan() but I guess until services has fully started up,
> it
> >doesn't realize that the users are in the channel.
>
>      This is because of the way IRC works: when a server joins the
> network,
> all users are treated as if they had just joined the channels they are in.
> There's no way around this without rewriting the IRC protocol.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060329/610e4820/attachment.htm
From achurch at achurch.org  Thu Mar 30 15:39:52 2006
From: achurch at achurch.org (Andrew Church)
Date: Wed Mar 29 22:40:40 2006
Subject: [IRCServices Coding] Finding the modes set via channel mode change
In-Reply-To: <ce4fe3510603292049p2ae0ba47ya709838f2c424054@mail.gmail.com>
Message-ID: <442b7d61.10525@msgid.achurch.org>

>Thank you very much Andrew.  I do have on last question that I forgot to ask
>earlier.  Is it possible to see the source of a channel kick with the
>"channel KICK" callback? Basicly the user that did the kick is what I am
>referring to.
>static int do_channel_kick(Channel *c, User *u, const char *reason);

     Not currently.  I'll consider adding this for 5.1 as well.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From farklem at gmail.com  Tue Apr 11 17:08:20 2006
From: farklem at gmail.com (Jason farklem)
Date: Tue Apr 11 17:08:46 2006
Subject: [IRCServices Coding] Problems with exporting functions
Message-ID: <ce4fe3510604111708u5cc04e77kf3c1dc26410469@mail.gmail.com>

I have 2 modules im working on.  One of them (OtherServ) needs to access a
function from the other (BotServ).  I have been stuck on this simple thing
for many hours.

I get this error when starting ircservices:
"modules: Unable to load module `otherserv/main':
/home/farklem/ircservices/lib/modules/otherserv/main.so: undefined symbol:
get_botserv_id"

So far this is what I have done with no luck:

1. Added "E int get_botserv_id(const char *chan);" to botserv.h
2. Added #include "modules/botserv/botserv.h" to main.c for BotServ.
3. Added this to main.c for BotServ:

EXPORT_FUNC(get_botserv_id)
int get_botserv_id(const char *chan)
{
     return 0; // Just for testing purposes.
}

4. Edited the Makefile for BotServ to include botserv.h
5. Added #include "modules/botserv/botserv.h" to main.c for OtherServ.
6. Edited the Makefile for OtherServ to include botserv.h

Sorry if that is confusing but I had a hard time figuring out the best way
to organize it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060411/27be30f6/attachment.html
From achurch at achurch.org  Wed Apr 12 16:04:33 2006
From: achurch at achurch.org (Andrew Church)
Date: Wed Apr 12 00:06:16 2006
Subject: [IRCServices Coding] Problems with exporting functions
In-Reply-To: <ce4fe3510604111708u5cc04e77kf3c1dc26410469@mail.gmail.com>
Message-ID: <443ca6dd.74656@msgid.achurch.org>

>I have 2 modules im working on.  One of them (OtherServ) needs to access a
>function from the other (BotServ).  I have been stuck on this simple thing
>for many hours.
>
>I get this error when starting ircservices:
>"modules: Unable to load module `otherserv/main':
>/home/farklem/ircservices/lib/modules/otherserv/main.so: undefined symbol:
>get_botserv_id"

     This is discussed in section 6-1-3 of the manual, "Inter-module
dependencies".

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From ron2k.za at gmail.com  Sat Apr 22 08:07:35 2006
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Sat Apr 22 08:07:57 2006
Subject: [IRCServices Coding] Addition to UnrealIRCd that Services could use
Message-ID: <debb3bc0604220807g11b4d5dbya4cf55ba6c5e77b3@mail.gmail.com>

Here's something added in Unreal that Services can use.

To quote from the changelog:

- [Services coders!] Added PROTOCTL CLK (requires NICKv2) which adds
an extra field in the
  NICK command (when a user connects) right before the infofield (gecos).
  The added field contains the cloaked host, that is: the masked host
if +x would have been
  set. This field is ALWAYS sent, regardless of whether the user is
actually +x or not.
  Services can then store this field in memory, to know the host of
the user if the user
  is set +x (+x-t). This is a (better) alternative to PROTOCTL VHP,
with no race conditions,
  and avoids some other VHP problems.
  VHP will stay supported though... so it's not mandatory to switch over.


As implied, it's up to you whether or not to support this.
From achurch at achurch.org  Sun Apr 23 01:17:54 2006
From: achurch at achurch.org (Andrew Church)
Date: Sat Apr 22 09:18:41 2006
Subject: [IRCServices Coding] Addition to UnrealIRCd that Services could
	use
In-Reply-To: <debb3bc0604220807g11b4d5dbya4cf55ba6c5e77b3@mail.gmail.com>
Message-ID: <444a574d.41471@msgid.achurch.org>

     Thanks, I'll keep that in mind for the next time I have a chance to
work on Services.  (At the moment, work and other commitments are sucking
up all my time and then some...)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Here's something added in Unreal that Services can use.
>
>To quote from the changelog:
>
>- [Services coders!] Added PROTOCTL CLK (requires NICKv2) which adds
>an extra field in the
>  NICK command (when a user connects) right before the infofield (gecos).
>  The added field contains the cloaked host, that is: the masked host
>if +x would have been
>  set. This field is ALWAYS sent, regardless of whether the user is
>actually +x or not.
>  Services can then store this field in memory, to know the host of
>the user if the user
>  is set +x (+x-t). This is a (better) alternative to PROTOCTL VHP,
>with no race conditions,
>  and avoids some other VHP problems.
>  VHP will stay supported though... so it's not mandatory to switch over.
>
>
>As implied, it's up to you whether or not to support this.
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From achurch at achurch.org  Sat Jun  3 09:50:35 2006
From: achurch at achurch.org (Andrew Church)
Date: Fri Jun  2 17:55:44 2006
Subject: [IRCServices Coding] Services 5.1a7 released
Message-ID: <4480ddff.54635@msgid.achurch.org>

     Services 5.1a7 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

598e0bdc451fc92f9cba21e22e4f20d8  ircservices-5.1a7.tar.gz
9a1ae7b875e3e2aa8f2f3cd1eab0d254  ircservices-5.1a7.diff.gz
1f3732813a51c310bc7a4adf5021fe7b  ircservices-5.1a7-1.i386.rpm
54f95fadb189de47339d0d3df15020d8  ircservices_5.1a7-1_i386.deb

The mirrors should have it shortly.

     This release is partly to put out fixes for various bugs I've come
across or seen mentioned, but also to let you know that I'm still alive,
more or less. (:  I'm also making progress (albeit slowly) on the technical
manual, and those of you who are technically inclined may want to take a
look at it; it's in the docs/tech subdirectory of the tarball, or online at
    http://www.ircservices.esper.net/download/testing/docs/tech/
(I really ought to get things moved back to .za.net one of these days...)

Changes in version 5.1a7
------------------------
2006/06/03	Fixed handling of language strings added by modules in
		    external language files.
2006/06/02	Fixed a rare case in which a timed event could fail to be
		    executed, and ensure that extremely long timeouts
		    (>25 days) are not called immediately.
2006/06/01	Added robustness to mode character/flag conversion functions.
2006/05/31	Fixed infinite loop in ignore code when a single command
		    takes longer to execute than the time specified in the
		    IgnoreDecay configuration directive.
2006/05/31	Fixed bug that could potentially cause the log file to be
		    rotated in the middle of writing a log message.
2006/05/31	Cleaned up restart handling.
2006/05/31	Fixed bug causing missing parameters in a configuration
		    directive to get zeroed rather than keeping their
		    previous values.
2006/05/31	Fixed cosmetic bug causing "BUG" message to be logged when
		    deprecated configuration directives are used.
2006/04/14	Fixed bug allowing infinite join/kick loops on autokick
		    when Unreal extended bantypes are in use.
2006/04/14	Fixed bug causing Services to split from InspIRCd servers
		    without the m_globops.so module loaded.  Reported by
		    <techie101@gmail.com>
2006/03/22	Logging initialization moved earlier, to catch any
		    unexpected log messages before the log file is opened.
2006/03/22	Fixed a critical error in the supplied [v]snprintf() which
		    allowed the output to exceed the specified maximum
		    length.
2006/03/20	Corrected a design defect in the hash table implementation
		    creating the potential for entries to get lost after
		    irc_lowertable[] modifications.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Jun  6 10:49:04 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jun  5 18:50:19 2006
Subject: [IRCServices Coding] Finding the modes set via channel mode change
In-Reply-To: <ce4fe3510603292049p2ae0ba47ya709838f2c424054@mail.gmail.com>
Message-ID: <4484df43.52013@msgid.achurch.org>

>Thank you very much Andrew.  I do have on last question that I forgot to ask
>earlier.  Is it possible to see the source of a channel kick with the
>"channel KICK" callback? Basicly the user that did the kick is what I am
>referring to.
>static int do_channel_kick(Channel *c, User *u, const char *reason);

     I've (belatedly) added this for the next release: the callback will
take a fourth parameter, const char *source.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Jun  6 13:50:15 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Jun  5 21:53:09 2006
Subject: [IRCServices Coding] Services 5.1a8 released
Message-ID: <44850a2a.77367@msgid.achurch.org>

     Services 5.1a8 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

77fab91232d226ef7e0276122934681c  ircservices-5.1a8.tar.gz
7ce55e645fd43a8e294c4657858741ea  ircservices-5.1a8.diff.gz
129032cf12b10612113fe7803d4f8f48  ircservices-5.1a8-1.i386.rpm
65c57df80ae372fb0ba7177e37d08d8d  ircservices_5.1a8-1_i386.deb

The mirrors should have it shortly.

     This is just a quick update to implement the KICK callback change;
the Hungarian language file has also been updated for 5.1.

Changes in version 5.1a8
------------------------
2006/06/06	Hungarian language file updated for 5.1.
2006/06/06	Added message source parameter to "channel KICK" callback.
		    Suggested by Jason Farklem <farklem@gmail.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Thu Jun 22 04:37:09 2006
From: achurch at achurch.org (Andrew Church)
Date: Wed Jun 21 12:46:49 2006
Subject: [IRCServices Coding] Services 5.1a9 released
Message-ID: <4499a220.40212@msgid.achurch.org>

     Services 5.1a9 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

6db86b05054de8837322649b5b924333  ircservices-5.1a9.tar.gz
5371d465009306188ca73012ebbad5c2  ircservices-5.1a9.diff.gz
68f7ed8e46c548f701fcbe48f39d0028  ircservices-5.1a9-1.i386.rpm
1f01937c57ef1a451616b273ff78b2ec  ircservices_5.1a9-1_i386.deb

The mirrors should have it shortly.

     Aside from the changes in 5.0.58, this release fixes several bugs of
varying severity in the socket and configuration file handling code.  I've
also added 64-bit integer types (int64 and uint64), which are checked for
by the configure script; you'll now need a compilation environment that
supports either int64_t or a 64-bit long or long long type in order to
compile Services (hopefully everybody has that by now).

Changes in version 5.1a9
------------------------
2006/06/22	Fixed bug in configuration file handling causing
		    function-processed directives like LoadModule to break.
2006/06/22	Added int64 and uint64 types, and added a check to
		    configure to find appropriate system types for them.
2006/06/22	Added robustness to socket code in out-of-memory conditions.
2006/06/22	Changed select() call to not assume that the timeval struct
		    is valid after the call.
2006/06/22	Changed the socket code to use recv() and send() on sockets
		    instead of read() and write().
2006/06/22	Fixed potential bug causing accepted sockets' mute status
		    to get out of sync with internal tables.
2006/06/22	Corrected handling of nested socket callbacks.
2006/06/22	Renamed NET_MIN_BUFSIZE constant to SOCK_MIN_BUFSIZE, and
		    moved it from defs.h to sockets.h.
2006/06/19	Fixed a typo in the OperServ AKILL/SLINE CLEAR syntax
		    message.  Reported by <RealCFC@chatfirst.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From V.Ovsyannikov at kr.ru  Thu Jun 29 04:52:03 2006
From: V.Ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Thu Jun 29 04:52:13 2006
Subject: [IRCServices Coding] IRC attacks
In-Reply-To: <4499a220.40212@msgid.achurch.org>
References: <4499a220.40212@msgid.achurch.org>
Message-ID: <449443233.20060629195203@kr.ru>

Hello, IRC.

Some good guys do regular attacks on my irc network using many
different hosts in parallel. Very often, this is done using open proxies.
Is this possible to implement simple port scanning algorithm to
detect clients with many open tcp ports (or detect blacklisted port
numbers or ranges of them) and block the connection? The problem is
real one. Help please. Server software is bahamut-based fork with
support of Russian codepages translation.

-- 
Sincerely,
Vitaliy Ovsyannikov
JSC Skala, Krasnoyarsk, Russia

From aragon at phat.za.net  Thu Jun 29 04:55:57 2006
From: aragon at phat.za.net (Aragon Gouveia)
Date: Thu Jun 29 04:56:07 2006
Subject: [IRCServices Coding] IRC attacks
In-Reply-To: <449443233.20060629195203@kr.ru>
References: <4499a220.40212@msgid.achurch.org> <449443233.20060629195203@kr.ru>
Message-ID: <20060629115557.GA37147@phat.za.net>

http://wiki.blitzed.org/BOPM


| By Vitaliy Ovsyannikov <V.Ovsyannikov@kr.ru>
|                                          [ 2006-06-29 13:52 +0200 ]
> Hello, IRC.
> 
> Some good guys do regular attacks on my irc network using many
> different hosts in parallel. Very often, this is done using open proxies.
> Is this possible to implement simple port scanning algorithm to
> detect clients with many open tcp ports (or detect blacklisted port
> numbers or ranges of them) and block the connection? The problem is
> real one. Help please. Server software is bahamut-based fork with
> support of Russian codepages translation.
> 
> -- 
> Sincerely,
> Vitaliy Ovsyannikov
> JSC Skala, Krasnoyarsk, Russia
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From admin at webspace.ms  Wed Aug  2 10:12:45 2006
From: admin at webspace.ms (Andreas WILMES)
Date: Wed Aug  2 10:13:14 2006
Subject: [IRCServices Coding] Hostserv.c: undefined symbol: get_nickinfo
Message-ID: <000001c6b656$df50e060$9df2a120$@ms>

Hello,

 

I got the follow Error:

 

[Aug 02 19:11:43 2006] modules: Unable to load module `misc/hostserv':
/home/services/lib/modules/misc/hostserv.so: undefined symbol: get_nickinfo

[Aug 02 19:11:43 2006] Error loading modules, aborting

 

I'm sure, that the nickserv.h is included, any ideas?

Cheers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20060802/9b00b6c7/attachment.html
From achurch at achurch.org  Mon Aug  7 00:11:00 2006
From: achurch at achurch.org (Andrew Church)
Date: Sun Aug  6 08:13:33 2006
Subject: [IRCServices Coding] Services 5.1a10 released
Message-ID: <44d6070f.10663@msgid.achurch.org>

     Services 5.1a10 has been released, and can be downloaded from:

http://www.ircservices.esper.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/             (Western USA)

ec8102eb5e32b503bd8723e5cdbe3226  ircservices-5.1a10.tar.gz
ef47f209c2b9b51c0e6444df1ec8c3ba  ircservices-5.1a10.diff.gz
2b234d2118660febed550b35fa627e97  ircservices-5.1a10-1.i386.rpm
1aaed227b9221e20e94415c4b59409b5  ircservices_5.1a10-1_i386.deb

The mirrors should have it shortly.

     This release adds an experimental protocol module for the solid-ircd
IRC server (http://www.solid-ircd.com/); the Dutch language file has also
been updated for 5.1.  Note that I'm on vacation at the moment, so I may
not be able to reply to any bug reports quickly.

Changes in version 5.1a10
-------------------------
2006/08/06	Added preliminary support for the solid-ircd IRC server.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Aug 15 05:36:45 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 14 13:37:34 2006
Subject: [IRCServices Coding] Test mail
Message-ID: <44e0df00.64164@msgid.achurch.org>

Test mail, please ignore.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Aug 15 05:41:37 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 14 13:42:52 2006
Subject: [IRCServices Coding] Test mail
In-Reply-To: <44e0df00.64164@msgid.achurch.org>
Message-ID: <44e0e046.64177@msgid.achurch.org>

>Test mail, please ignore.

I FAIL IT

Let's try that again...

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Mon Aug 14 15:51:28 2006
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 14 15:51:40 2006
Subject: [IRCServices Coding] Test mail
In-Reply-To: <44e0e046.64177@msgid.achurch.org>
References: <44e0df00.64164@msgid.achurch.org>
	<44e0e046.64177@msgid.achurch.org>
Message-ID: <b19eae4e0608141551k32e06dfeuf47b6a5e1226a861@mail.gmail.com>

Andrew fails it.

Hi, mum. o/

On 8/14/06, Andrew Church <achurch@achurch.org> wrote:
> >Test mail, please ignore.
>
> I FAIL IT
>
> Let's try that again...
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From manual4000 at yahoo.com  Sat Nov  4 16:48:21 2006
From: manual4000 at yahoo.com (MaNUaL)
Date: Sat Nov  4 16:49:00 2006
Subject: [IRCServices Coding] Segmentation fault: 11
Message-ID: <20061105004821.54629.qmail@web53009.mail.yahoo.com>

Hi. I am using Unreal3.2.5 in freebsd 6.1 and
ircservices 5.1.a10
I try to add some nicks in a channels access list,
then i do update on the services, and it crashes. The
debug log shows:

[Nov 05 01:33:45.443163 2006] debug: Received: :sroot
! chanserv@services.example.net :access #opers list
[Nov 05 01:33:45.443987 2006] debug: Sent: :ChanServ
NOTICE sroot :Access list for #Opers:
[Nov 05 01:33:45.444097 2006] debug: Sent: :ChanServ
NOTICE sroot :    Level  Nickname
[Nov 05 01:33:45.444184 2006] debug: Sent: :ChanServ
NOTICE sroot :      999  sroot
[Nov 05 01:33:45.444272 2006] debug: Sent: :ChanServ
NOTICE sroot :      999  xxxx
[Nov 05 01:33:45.444359 2006] debug: Sent: :ChanServ
NOTICE sroot :End of list; 2/2 matches shown.
[Nov 05 01:33:53.560261 2006] debug: Received: :sroot
! operserv@services.example.net :update
[Nov 05 01:33:53.560927 2006] (operserv/main) sroot:
update
[Nov 05 01:33:53.561133 2006] debug: Sent: :OperServ
NOTICE sroot :Updating databases...
[Nov 05 01:33:53.561428 2006] debug: Saving databases
[Nov 05 01:33:53.569234 2006] PANIC! signal 11 (no
buffer)
[Nov 05 01:33:53.569997 2006] debug: Sent:
:services.example.net GLOBOPS :PANIC! signal 11 (no
buffer)
[Nov 05 01:33:53.570676 2006] Services terminating:
Segmentation fault: 11
[Nov 05 01:33:53.571063 2006] debug: Unloading module
`misc/devnull'
[Nov 05 01:33:53.571531 2006] debug: Sent: :DevNull
QUIT :
[Nov 05 01:33:53.572132 2006] debug: Unloading module
`misc/helpserv'
[Nov 05 01:33:53.572645 2006] debug: Sent: :HelpServ
QUIT :
[Nov 05 01:33:53.573150 2006] debug: Unloading module
`statserv/main'
[Nov 05 01:33:53.573795 2006] debug: Sent: :StatServ
QUIT :
[Nov 05 01:33:53.574360 2006] debug: Unloading module
`memoserv/main'
[Nov 05 01:33:53.574832 2006] debug: Sent: :MemoServ
QUIT :
[Nov 05 01:33:53.575318 2006] debug: Unloading module
`chanserv/access-levels'
[Nov 05 01:33:53.575831 2006] debug: Unloading module
`chanserv/main'
[Nov 05 01:33:53.576277 2006] debug: Sent: :ChanServ
QUIT :
[Nov 05 01:33:53.576863 2006] debug: Unloading module
`nickserv/access'
[Nov 05 01:33:53.577368 2006] debug: Unloading module
`nickserv/main'
[Nov 05 01:33:53.577801 2006] debug: Sent: :NickServ
QUIT :
[Nov 05 01:33:53.578504 2006] debug: Unloading module
`operserv/sline'
[Nov 05 01:33:53.579033 2006] debug: Unloading module
`operserv/sessions'
[Nov 05 01:33:53.579545 2006] debug: Unloading module
`operserv/news'
[Nov 05 01:33:53.580019 2006] debug: Unloading module
`operserv/akill'
[Nov 05 01:33:53.580490 2006] debug: Unloading module
`operserv/main'
[Nov 05 01:33:53.580964 2006] debug: Sent: :OperServ
QUIT :
[Nov 05 01:33:53.581372 2006] debug: Sent: :Global
QUIT :
[Nov 05 01:33:53.581929 2006] modules: Module
`operserv/main' forgot to remove callback `save data
complete' from module `core'
[Nov 05 01:33:53.582378 2006] debug: Unloading module
`database/standard'
[Nov 05 01:33:53.582854 2006] debug: Unloading module
`protocol/unreal'
[Nov 05 01:33:53.583576 2006] debug: Sent:
:services.example.net SQUIT services.example.net
:Services terminating: Segmentation fault: 11
[Nov 05 01:33:53.584273 2006] debug: Deleting channel
#Opers
[Nov 05 01:33:53.585494 2006] debug: Deleting channel
#Hellas

Any ideas?


 
____________________________________________________________________________________
Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates 
(http://voice.yahoo.com)

From achurch at achurch.org  Tue Nov  7 10:24:46 2006
From: achurch at achurch.org (Andrew Church)
Date: Mon Nov  6 17:27:27 2006
Subject: [IRCServices Coding] Segmentation fault: 11
In-Reply-To: <20061105004821.54629.qmail@web53009.mail.yahoo.com>
Message-ID: <454fe0fc.56143@msgid.achurch.org>

>Hi. I am using Unreal3.2.5 in freebsd 6.1 and
>ircservices 5.1.a10
>I try to add some nicks in a channels access list,
>then i do update on the services, and it crashes. The
>debug log shows:
[...]
>[Nov 05 01:33:53.561133 2006] debug: Sent: :OperServ
>NOTICE sroot :Updating databases...
>[Nov 05 01:33:53.561428 2006] debug: Saving databases
>[Nov 05 01:33:53.569234 2006] PANIC! signal 11 (no
>buffer)

     I'll need to see a backtrace to be able to look into the problem.
Either start Services from inside GDB (use the -nofork option to Services
when running it), or reconfigure with the -dumpcore option to force
Services to dump core when a segmentation fault occurs and do a backtrace
on the core file.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From manual4000 at yahoo.com  Fri Nov 10 11:34:20 2006
From: manual4000 at yahoo.com (MaNUaL)
Date: Fri Nov 10 11:34:23 2006
Subject: [IRCServices Coding] Segmentation fault: 11
In-Reply-To: <454fe0fc.56143@msgid.achurch.org>
Message-ID: <20061110193420.80510.qmail@web53013.mail.yahoo.com>

sorry for the previous mail
this one is the right one

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `ircservices'.
Program terminated with signal 11, Segmentation fault.
Error while mapping shared library sections:
/usr/home/nemesi/ircservices/lib/services/modules/database/standard.so: No such file or directory.
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/protocol/unreal.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/protocol/unreal.so
Error while reading shared library symbols:
/usr/home/nemesi/ircservices/lib/services/modules/database/standard.so: No such file or directory.
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/operserv/main.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/operserv/main.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/operserv/akill.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/operserv/akill.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/operserv/news.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/operserv/news.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/sessions.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/operserv/sessions.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/operserv/sline.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/operserv/sline.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/nickserv/main.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/nickserv/main.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/nickserv/access.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/nickserv/access.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/chanserv/main.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/chanserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/chanserv/access-levels.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/chanserv/access-levels.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/memoserv/main.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/memoserv/main.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/statserv/main.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/statserv/main.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/misc/helpserv.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/misc/helpserv.so
Reading symbols from /usr/home/nemesi/ircservices/lib/services/modules/misc/devnull.so...done.
Loaded symbols for /usr/home/nemesi/ircservices/lib/services/modules/misc/devnull.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x281ee692 in ?? ()

(gdb) bt
#0  0x281ee692 in ?? ()
#1  0x2819c338 in __isthreaded () from /lib/libc.so.6
#2  0x2819c338 in __isthreaded () from /lib/libc.so.6
#3  0x00000002 in ?? ()
#4  0x28242200 in ?? ()
#5  0x080ad780 in ?? ()
#6  0x08315200 in ?? ()
#7  0xbfbfec38 in ?? ()
#8  0x281ed994 in ?? ()
#9  0x2020202c in ?? ()
#10 0x08318000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0xbfbfebc8 in ?? ()
#14 0x08315200 in ?? ()
#15 0x00004000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x08315200 in ?? ()
#18 0x080ad780 in ?? ()
#19 0x00000001 in ?? ()
#20 0x00002000 in ?? ()
#21 0x0000000a in ?? ()
#22 0x00000003 in ?? ()
#23 0x0000000a in ?? ()
#24 0x08318000 in ?? ()
#25 0x281ef1e0 in ?? ()
#26 0x083151f0 in ?? ()
#27 0x2020202c in ?? ()
#28 0x0000000a in ?? ()
#29 0x080966a0 in logmemptr ()
#30 0x00000401 in ?? ()
#31 0x08068f64 in base_langstrs ()
#32 0xbfbfec0c in ?? ()
#33 0x69706173 in ?? ()
#34 0x0000736f in ?? ()
#35 0x00000000 in ?? ()
#36 0x00000000 in ?? ()
#37 0x00000000 in ?? ()
#38 0x00000000 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000000 in ?? ()
#42 0x00000000 in ?? ()
#43 0xbfbfec28 in ?? ()
#44 0x08054649 in logprintf (fmt=0x0) at log.c:135
Previous frame inner to this frame (corrupt stack?)
(gdb)



 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index
From manual4000 at yahoo.com  Fri Nov 10 11:28:53 2006
From: manual4000 at yahoo.com (MaNUaL)
Date: Fri Nov 10 11:35:37 2006
Subject: [IRCServices Coding] Segmentation fault: 11
In-Reply-To: <454fe0fc.56143@msgid.achurch.org>
Message-ID: <20061110192853.71524.qmail@web53014.mail.yahoo.com>

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `ircservices'.
Program terminated with signal 11, Segmentation fault.
Error while mapping shared library sections:
/usr/home/nemesi/ircservices/lib/services/modules/database/standard.so:
No such file or directory.
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/protocol/unreal.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/protocol/unreal.so
Error while reading shared library symbols:
/usr/home/nemesi/ircservices/lib/services/modules/database/standard.so:
No such file or directory.
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/main.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/operserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/akill.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/operserv/akill.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/news.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/operserv/news.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/sessions.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/operserv/sessions.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/operserv/sline.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/operserv/sline.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/nickserv/main.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/nickserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/nickserv/access.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/nickserv/access.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/chanserv/main.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/chanserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/chanserv/access-levels.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/chanserv/access-levels.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/memoserv/main.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/memoserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/statserv/main.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/statserv/main.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/misc/helpserv.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/misc/helpserv.so
Reading symbols from
/usr/home/nemesi/ircservices/lib/services/modules/misc/devnull.so...done.
Loaded symbols for
/usr/home/nemesi/ircservices/lib/services/modules/misc/devnull.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x281ee692 in ?? ()


(gdb) bt
#0  0x281ee692 in ?? ()
#1  0x2819c338 in __isthreaded () from /lib/libc.so.6
#2  0x2819c338 in __isthreaded () from /lib/libc.so.6
#3  0x00000002 in ?? ()
#4  0x28242200 in ?? ()
#5  0x080ad780 in ?? ()
#6  0x08315200 in ?? ()
#7  0xbfbfec38 in ?? ()
#8  0x281ed994 in ?? ()
#9  0x2020202c in ?? ()
#10 0x08318000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0xbfbfebc8 in ?? ()
#14 0x08315200 in ?? ()
#15 0x00004000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x08315200 in ?? ()
#18 0x080ad780 in ?? ()
#19 0x00000001 in ?? ()
#20 0x00002000 in ?? ()
#21 0x0000000a in ?? ()
#22 0x00000003 in ?? ()
#23 0x0000000a in ?? ()
#24 0x08318000 in ?? ()
#25 0x281ef1e0 in ?? ()
#26 0x083151f0 in ?? ()
#27 0x2020202c in ?? ()
#28 0x0000000a in ?? ()
#29 0x080966a0 in logmemptr ()
#30 0x00000401 in ?? ()
#31 0x08068f64 in base_langstrs ()
#32 0xbfbfec0c in ?? ()
#33 0x69706173 in ?? ()
#34 0x0000736f in ?? ()
#35 0x00000000 in ?? ()
#36 0x00000000 in ?? ()
#37 0x00000000 in ?? ()
#38 0x00000000 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000000 in ?? ()
#42 0x00000000 in ?? ()
#43 0xbfbfec28 in ?? ()
#44 0x08054649 in logprintf (fmt=0x0) at log.c:135
Previous frame inner to this frame (corrupt stack?)



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
From achurch at achurch.org  Fri Dec  8 20:34:50 2006
From: achurch at achurch.org (Andrew Church)
Date: Fri Dec  8 03:39:41 2006
Subject: [IRCServices Coding] Services 5.1a11 released
Message-ID: <45794ef9.71107@msgid.achurch.org>

     Services 5.1a11 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

4c46c4a600d742bd06c8528caee4d3bc  ircservices-5.1a11.tar.gz
196e3fcca6e86001ae4b72ccef63507e  ircservices-5.1a11.diff.gz
7de244b51a88bce35ffc956edcfee138  ircservices-5.1a11-1.i386.rpm
adc4c9f32f19135ad93329476b0a7584  ircservices_5.1a11-1_i386.deb

The mirrors should have it shortly.

     At last, the first draft of the technical manual (docs/tech/index.html)
is complete!  The manual should provide guidance to future developers, and
has also brought to my attention a number of problems with the current code,
some of which have been fixed in this version and the rest of which will be
addressed in future alpha releases.

     The Spanish translation has also been updated for 5.1, thanks to
<RealCFC@chatfirst.com>.

Changes in version 5.1a11
-------------------------
2006/12/08	Merged section 6 of the user's manual (on adding features
		    to Services) into the technical manual.
2006/12/08	Removed unused read/write macros from
		    modules/database/fileutil.h.
2006/12/08	Fixed bug causing the "shutdown" parameter to modules'
		    cleanup functions to always be nonzero.
2006/12/06	Removed all remaining "press Enter" warning prompts from
		    configure, making it fully automated.
2006/12/06	Clarified that missing system functions (strtok(), etc.)
		    detected by configure do not prevent Services from
		    being compiled and run.  Also updated the warning for
		    a missing gethostbyname().
2006/11/09	The httpd/top-page module now explicitly returns an error
		    if the specified file cannot be read, rather than
		    deferring to a subsequent handler.
2006/11/03	Added workaround for NULL masks in autokick lists.  Reported
		    by Gabriel Baez <gabriel.baez@solid-ircd.com>
2006/10/29	Fixed the encryption/unix-crypt module to allow crypt()
                    results longer than 13 characters and to not truncate
		    the final character of a PASSMAX-length password.
2006/10/01	ChanServ OP/VOICE/etc. now check that the target user is on
		    the channel before performing privilege checks; PROTECT
		    is now disallowed on auto-deop users.
2006/09/26	Merged modules/chanserv/autokick.c back into main.c.
2006/08/16	Updated documentation to reflect new domain name.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/