[IPv6 IRC-DEV] Modulo Hispano-IPv6 ipv6 .patches,1.1.1.1,1.2 CAMBIOS.Ipv6,1.10,1.11 CAMBIOS2_10_H_05
Brought to you by:
zolty
Menu
▾
▴
[IPv6 IRC-DEV] Modulo Hispano-IPv6 ipv6 .patches,1.1.1.1,1.2 CAMBIOS.Ipv6,1.10,1.11 CAMBIOS2_10_H_05,1.1.1.1,1.2 Makefile.in,1.3,1.4 todo.jcea,1.1.1.1,1.2
|
From: Zolty <zo...@us...> - 2002-09-30 15:02:03
|
Update of /cvsroot/irc-dev/ipv6 In directory usw-pr-cvs1:/tmp/cvs-serv3940 Modified Files: .patches CAMBIOS.Ipv6 CAMBIOS2_10_H_05 Makefile.in todo.jcea Log Message: Sincronizacion u2.10.H.05.93 Index: .patches =================================================================== RCS file: /cvsroot/irc-dev/ipv6/.patches,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -d -r1.1.1.1 -r1.2 --- .patches 11 Sep 2002 10:09:07 -0000 1.1.1.1 +++ .patches 30 Sep 2002 15:01:59 -0000 1.2 @@ -1 +1 @@ -u2.10.H.05.69 +u2.10.H.05.93 Index: CAMBIOS.Ipv6 =================================================================== RCS file: /cvsroot/irc-dev/ipv6/CAMBIOS.Ipv6,v retrieving revision 1.10 retrieving revision 1.11 diff -u -d -r1.10 -r1.11 --- CAMBIOS.Ipv6 16 Sep 2002 16:22:00 -0000 1.10 +++ CAMBIOS.Ipv6 30 Sep 2002 15:01:59 -0000 1.11 @@ -1,3 +1,7 @@ +* 2002/09/30 zo...@ir... INET6.11 +----------------------------------------------------------------------- +Actualizacion IRCD hasta el u2.10.H.05.93. + * 2002/09/16 ni...@ir... INET6.10 ----------------------------------------------------------------------- Se adaptan el pretty_mask y el codigo de chequeo de banspara que admita Index: CAMBIOS2_10_H_05 =================================================================== RCS file: /cvsroot/irc-dev/ipv6/CAMBIOS2_10_H_05,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -d -r1.1.1.1 -r1.2 --- CAMBIOS2_10_H_05 11 Sep 2002 10:09:07 -0000 1.1.1.1 +++ CAMBIOS2_10_H_05 30 Sep 2002 15:01:59 -0000 1.2 @@ -1,5 +1,114 @@ $Id$ +* 2002/09/30 ni...@ir... (u2.10.H.05.93) FIX + ----------------------------------------------------------------------- + Bug en el parche anterior que hacia que no se propagasen los ban. + +* 2002/09/27 ni...@ir... (u2.10.H.05.92) FIX + ----------------------------------------------------------------------- + Permitimos quitar banes con cualquier caracter, y para ponerlos solo + sirven los que el parche u2.10.H.05.34 admite. + +* 2002/09/27 jc...@ar... (u2.10.H.05.91) FIX + ----------------------------------------------------------------------- + Revertimos el parche u2.10.H.05.77, por violar el RFC 1459. + +* 2002/09/27 ni...@ir... (u2.10.H.05.90) FIX + ----------------------------------------------------------------------- + En un /trace pepe pepe.* se imprimia dos veces "No such server". + +* 2002/09/27 ni...@ir... (u2.10.H.05.89) FIX + ----------------------------------------------------------------------- + Consistencia en el WATCH: cptr -> sptr. + +* 2002/09/27 ni...@ir... (u2.10.H.05.88) FIX + ----------------------------------------------------------------------- + Cuando enviamos un WALLCHOPS a un canal inexistente, se muestra error. + +* 2002/09/24 ni...@ir... (u2.10.H.05.87) FIX + ----------------------------------------------------------------------- + Correccion en un numeric. + +* 2002/07/23 jc...@ar... (u2.10.H.05.86) CLEANUP + ----------------------------------------------------------------------- + Simplificacion del parche anterior. + +* 2002/07/23 ni...@ir... (u2.10.H.05.85) FIX + ----------------------------------------------------------------------- + El +M aparece en los raws 004 y 005. + +* 2002/09/23 jc...@ar... (u2.10.H.05.84) CLEANUP + ----------------------------------------------------------------------- + Mas limpieza y simplificacion en "can_send". + +* 2002/09/23 jc...@ar... (u2.10.H.05.83) CLEANUP + ----------------------------------------------------------------------- + Simplificacion y optimizacion del parche anterior. + +* 2002/09/23 ni...@ir... (u2.10.H.05.82) FEATURE + ----------------------------------------------------------------------- + Nuevo modo de canal: +M. Impide enviar texto al canal y especificar + texto en los PART y QUIT a nicks que no sean +r. + +* 2002/09/23 jc...@ar... (u2.10.H.05.81) FIX + ----------------------------------------------------------------------- + Compilacion correcta si se configura sin soporte BDD. + +* 2002/09/23 ni...@ir... (u2.10.H.05.80) FEATURE + ----------------------------------------------------------------------- + Nuevo numeric en el WHOIS para el modo +R. Mostramos "Solo admite + privados de nicks registrados", y usamos el 342 para ello. + +* 2002/07/19 ni...@ir... (u2.10.H.05.79) FIX + ----------------------------------------------------------------------- + Solucionamos un pequeño error que impedia recompilar las tablas de + caracteres de common.c con 'make ctables'. + +* 2002/07/19 ni...@ir... (u2.10.H.05.78) FIX + ----------------------------------------------------------------------- + En el WHO mostramos el +k si procede. + +* 2002/07/19 ni...@ir... (u2.10.H.05.77) FIX + ----------------------------------------------------------------------- + En la respuesta RPL_LUSERCLIENT en vez de mostrar el numero de usuarios + sin +i y con +i, mostramos el total y los que son +i. + +* 2002/07/18 ni...@ir... (u2.10.H.05.76) FEATURE + ----------------------------------------------------------------------- + En el raw 004, mostramos el +B como modo de usuario. + +* 2002/07/18 ni...@ir... (u2.10.H.05.75) FEATURE + ----------------------------------------------------------------------- + En el WHO, mostramos el +B si procede. + +* 2002/07/18 ni...@ir... (u2.10.H.05.74) FEATURE + ----------------------------------------------------------------------- + En la respuesta a LUSERS, si hemos compilado el ircd con soporte BDD + se muestran, aparte de los IRCops, los Opers y bots de la red: + + There are 27 users and 14 invisible on 1 servers + 4 IRCop(s), 7 helper(s) and 2 official bots online + I have 4 clients and 3 servers + +* 2002/09/17 ni...@ir... (u2.10.H.05.73) FEATURE + ----------------------------------------------------------------------- + Nuevo numeric en el WHOIS para los bots. Si el bot tiene +B mostramos + "Es un roBOT oficial de la Red". Usamos el 316 para ello. + +* 2002/09/17 ni...@ir... (u2.10.H.05.72) FIX + ----------------------------------------------------------------------- + Correccion en un numeric. + +* 2002/09/12 red...@ya... (u2.10.H.05.71) FIX + ----------------------------------------------------------------------- + Cuando un usuario abandona el IRC teniendo mensajes en "transito" hacia + el circulando por la red, el mensaje de "Target left IRC" indica + correctamente el nick en cuestion. + +* 2002/09/11 jc...@ar... (u2.10.H.05.70) FIX + ----------------------------------------------------------------------- + Permitir compilar el IRCD con soporte de WATCH pero sin soporte +x. + * 2002/09/10 jc...@ar... (u2.10.H.05.69) FIX ----------------------------------------------------------------------- No permite que un usuario cambie de nick varias veces *ANTES* de que el Index: Makefile.in =================================================================== RCS file: /cvsroot/irc-dev/ipv6/Makefile.in,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- Makefile.in 16 Sep 2002 12:22:13 -0000 1.3 +++ Makefile.in 30 Sep 2002 15:01:59 -0000 1.4 @@ -126,6 +126,6 @@ # Indent all headers and source files: indent: - @test "`indent --version`" = "GNU indent 2.2.8a" || \ + @test "`indent --version`" = "GNU indent 2.2.8" || \ (echo "You need GNU indent 2.2.8a; See doc/readme.indent" && exit -1); VERSION_CONTROL=none indent include/*.h ircd/*.c Index: todo.jcea =================================================================== RCS file: /cvsroot/irc-dev/ipv6/todo.jcea,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -d -r1.1.1.1 -r1.2 --- todo.jcea 11 Sep 2002 10:09:07 -0000 1.1.1.1 +++ todo.jcea 30 Sep 2002 15:01:59 -0000 1.2 @@ -1,13 +1,19 @@ $Id$ +25/Sep/02 +Ahora que se muestran los IRCops, Opers y Bots online, ver +en que orden nos interesan, porque el primer parametros es +usado por algunos scripts. + +16/Sep/02 +Cuando quitamos a un usuario del WATCH, nos aparece un TimeStamp +de 1970. + 09/Sep/02 Permitir el caracter ~ en los nicks. Aparentemente, segun NiKoLaS, eso requeriria una actualizacion en dos etapas. -05/Sep/02 -Consistencia en el WATCH: cptr -> sptr. - 13/Ago/02 La variable que contiene los modos de usuario esta superpoblada y apenas le queda ya algun bit libre. Habia que mover lo que son @@ -15,17 +21,6 @@ a una variable separada, preferiblemente que exista SOLO cuando el usuario/conexion es local. -13/Ago/02 -Cuando un usuario esta silenciado, recibe un "notice" del servidor, -informandole de este hecho. Eso deberia cambiarse por un NUMERIC. - -06/Ago/02 -Poder poner, al conectar, una clave de servidor y otra de nick, al mismo tiempo. - -06/Ago/02 -Documentar en el registro (irc.org) correspondiente el uso -de QUITLEN y AWAYLEN. - 05/Ago/02 Estudiar la conveniencia de que el taman~o del comentario de los QUIT y de las GLINES no este vinculado a TOPICLEN. El problema se @@ -49,21 +44,6 @@ Estudiar implicaciones en cosas como cambios de nick. -24/Jun/02 -[13:16] <zolty> Cuando el servidor tiene activado el WATCH y un usuario -[13:16] <zolty> que monitorizamos y que no esta en nuestro servidor, -[13:16] <zolty> entra/sale de la red o cambia de nick, y el nick -[13:16] <zolty> esta en la tabla "v" o "w", la IP que aparece en el -[13:16] <zolty> WATCH que nos manda el servidor, es la ip virtual -[13:16] <zolty> normal, no la ip virtual personalizada que le -[13:16] <zolty> corresponde. -[13:16] <zolty> Cuando uno sale, se avisa el watch, antes de hacer -[13:16] <zolty> un "mode -r" y es muy raro, porque a la hora de enviar -[13:16] <zolty> el notify, AUN tiene el +r. -[13:16] <zolty> Cuando uno entra, se avisa el watch antes de recibir -[13:16] <zolty> un +r que vendra del nodo donde esta el usuario -[13:16] <zolty> monitorizado. - 21/Jun/02 Comprobar que KICK, JOIN, PART efectivamente son ya 100% puros. @@ -98,20 +78,6 @@ Por ejemplo, el comando ":nombre_del_Servidor join #canal" mata un server. -15/Nov/01 -Comentado por "SHauN": - -Porqué los servidores puestamente no admiten mayusculas en nombre o -identidades? Será depende del dia... porque hay dias que no hay dios que -entre con una identidad Mayus/Minus Porque el servidor te denega el accesso -con un mensaje: Bad Name/Ident i sin embargo otros dias por el mismo -servidor no hay ningun problema? - -Comprobarlo y solucionarlo. - -12/Nov/01 -"/trace pepe pepe.*" muestra dos veces un mensaje de "no such server". - 12/Nov/01 Zoltan: Para acabar, hay un bug, para meter en el todo.jcea... Ocurre que si un usuario con modos +r o +rh, recibe un rename, @@ -154,10 +120,6 @@ marca al usuario, y se le deje continuar. Una vez validadas las GLINES, comprobamos dicha marca y nos lo cargamos si es menester. -18/Sep/01 -Cambios de nick y de ciertos modos (en especial +h y +x) deben -borrar la caché de IP virtual de ese nick. - 07/Sep/01 Entrando a traves de un nodo que no tolera el +x, si hago un whois a un usuario con IP virtual en la tabla "v", aparece su @@ -196,20 +158,9 @@ y calcular su HASH. De esa forma es más fácil aprovechar los 64 bits de verdad, aun con claves relativamente "recordables". -16/Ago/01 -Persiste el problema de que algunos usuarios ven IPs virtuales -incorrectas si un usuario cambia de nick, y ambos nicks tienen -IPs virtuales diferentes (solo posible si al menos uno de ellos -tiene entrada en la tabla "v", o hay un cambio de clave -de proteccion de IP por medio). - 27/Jul/01 En el MOTD deberia salir una frase al azar, en plan "fortune". -25/Jul/01 -Pensar sobre la conveniencia de ampliar el limite de -30 "bans" que tienen ahora los canales. - 22/Jun/01 Cuando se compacta la base de datos, debe realizarse en un "thread" o proceso aparte, para no dejar de gestionar las conexiones durante @@ -217,17 +168,6 @@ principal de su finalizacion, para que haga un "rehash" y recargue la base de datos, incluyendo la validacion de su "hash". -14/Jun/01 -> >Se supone que si pongo un ban a alguien solo por su nick (nick!*@*), el -> >tipo no puede hablar si esta en el canal, y no puede entrar si sale e -> >intenta volver a entrar, no ? Bueno, esto funciona. -> > -> >Pero y si el tipo se cambia el nick? Puede volver a entrar en el canal y -> >hablar, pero si luego se vuelve a poner el otro nick (el que estaba -> >baneado) ... puede seguir hablando ? Es lo que me ha pasado a mi. Esto es -> >correcto? Si hay un ban para un nick, por que si se lo cambia y despues -> >vuelve al nick baneado, ese ban no le afecta ya ? - 06/Jun/01 Pensar sobre la conveniencia de que los usuarios normales no puedan ver el nodo por el que se @@ -308,15 +248,6 @@ nuevas tablas o registros confidenciales, los viejos nodos los seguiran mostrando mientras no se actualicen. -16/Nov/00 -Cada vez que cambias de nick, el server te informa de -tu nueva IP virtual... que es la misma. Al menos es la -misma si solo tienes el flag "+x". - -16/Nov/00 -Si tenemos los flags "ohX", y nos quitamos el -"oh", el "X" permanece. - 14/Nov/00 El lag calculado para "/map" debe actualizarse en mas ocasiones que "CREATE". Por ejemplo, cuando @@ -423,13 +354,6 @@ Si se hace un /whois IPvirtual, no dice que este conectado, aunque asi sea. -28/Mar/00 -Probando "/who" no deberia ser posible sacar la -IP de un usuario con IP virtual. - -Tampoco deberia ser posible localizar clones cuando -algunos de los usuarios tienen IP virtual y otros no. - 23/Mar/00 An~adir una base de datos con clave el nombre de un nodo y valor un mensaje @@ -495,12 +419,6 @@ Cuando un cliente sale del IRC, se almacena en el WHOWAS su IP cifrada si estaba protegido. Los Operadores de la red deberian tener acceso tambien a la IP real. - -08/Feb/00 -Aunque un Channel Service puede enviar mensajes a todos -los miembros de un canal, dichos mensajes aparecen -dentro del canal, como si el CS estuviese dentro, -no como un mensaje Global. 24/Ene/00 Cuando no se puede completar una verificacion SOCKS, |
