This fixes the following warning of gcc on OpenBSD 5.0: conf.c:728: warning: strcpy() is almost always misused, please use strlcpy()

This is correctly handled by ipaddr/ng_ipaddr.h today, and the check in tool.h isn't required any more -- and caused errors on OpenBSD 5.0: In file included from ./../tool/tool.h:23: /usr/include/arpa/inet.h:74: warning: "struct in_addr" declared inside parameter list

This fixes the following warning with current versions of GnuTLS: conf-ssl.h:36: warning: "gnutls_session" is deprecated

This flag indicates, that the server supports the enhanced "xop channel user modes", like channel owner, admin, and halfop. This information is used to make sure that no unsupported CHANINFO commands are sent to servers not supporting such mode prefixes, for example.

Starting with Anope 1.9.8, the ngIRCd protocol module is included in the Anope distribution, so there's no longer any need to support our own (but now heavily outdated!) patches. Therefore remove them.

Starting with Anope 1.9.8, the ngIRCd protocol module is rewritten from scratch by "DukePyrolator" and included in the Anope distribution. So no patching is required any more, yeah! Drawback: Anope 1.9.8 is in development and not yet released ...

Use "METADATA host" commands to let servers supporting this command know which (possibly cloaked) hostname is in effect for a specific client. This prevents "double cloaking" of hostnames and even cloaked hostnames are in sync on all servers supporting "METADATA" now.

A client for which a METADATA command has been received from one of its peers got the client flag "M" set. So it's safe to assume that such a client gets "METADATA host" commands for its cloaked hostname and the server must not cloak the hostname on its own, even when the client mode "+x" is set.

The METADATA command can be used by other servers to update "metadata" of registered clients, like the client info text ("real name"), user name, and hostname: :<prefix> METADATA <target> <key> :<value> It is distributed in the network, unknown <key> names are silently ignored and passed on, too. This allows for further extensions.

If PredefChannelsOnly is enabled, and if someone tries to create a channel which does not exist, then the error message is a 474. The 474 Error message changed recently and does not match anymore: 'Cannot join channel (+b) -- You are banned'. Changed the error message to numeric 403 'No such channel'. Bug introduced by commit 9a82304a. (cherry picked from commit 2c2e08f34187a33c1da745995c5f213e33a91410)

Now NICK commands are always generated using the prefix of the target user, even when the nickname change has been initiated by some other (pseudo) server or using the SVSNICK command. In this case, the prefix of the initiator has been used, but this isn't compatible with clients (at least weechat and irssi don't handle such NICK commands correctly).

The SVSNICK command allows other servers (and services on "pseudo-servers") to forcefully change nicknames of remote users. Syntax: ":<from> SVSNICK <oldnick> <newnick>" The SVSNICK command itself doesn't change the nickname, but it becomes forwarded to the server to which the user is connected to. And then this server initiates the real nickname changing using regular NICK commands. This allows to still run networks with old servers not supporting the SVSNICK command, because SVSNICK commands for nicknames on such servers are silently ignored and don't cause a desync of the network.

This reverts a not intentional code change and fixes the following compiler warning message (tested with gcc 4.4.5): irc-server.c: In function "IRC_SERVER": irc-server.c:142: warning: suggest parentheses around operand of "!" or change "&" to "&&" or "!" to "~"