*sigh* debugging my own debugging..
In the correction, when mo_info() calls m_info, it should return what m_info
returns, a la:
if(!IsOper(sptr))
return m_info(cptr,sptr,parc,parv); /* the comments say one
m_* function can call another, so why not actually try it : ) */
I agree. Original message follows.
On Thu, Jun 12, 2003 at 09:52:18PM +0100, Chris Crowther wrote:
> On Thursday 12 Jun 2003 9:30 pm, you wrote:
>
> > channels should be listed with the channel name clearly shown... and either
> > display the topic, or show "" (or something similiar) in
> > it's
> > How about we drop +p as a separate mode and make it do +s for
> compatibility?
> > --
> > Kevin L. Mitchell <[EMAIL PROTECTED]>
The most important difference is (or used to be, dunno
if that still works as-is) that when you are on a channel
that is +s then you cannot be found with a wildcard /
On Fri, Jun 13, 2003 at 01:43:06PM +0200, Carlo Wood wrote:
> The most important difference is (or used to be, dunno
> if that still works as-is) that when you are on a channel
> that is +s then you cannot be found with a wildcard /WHO
> if you'd otherwise have matched. This isn't the case
> when
Agreed. That's exactly what you use it for. As is implies fixing it to
work properly though I'd assume :)
At 10:08 PM 6/12/2003 -0600, Captain Kirk wrote:
I always found +p useful for those who wanted to find the channel, and
weren't just people looking to pester someone. +s hides completely,
> > I can't see a constructive difference between showing the channel names
as
> > Prv and hiding them completly. The only way it would make sense is the
way I
> > stated, otherwise +p and +s become analegous and +p is just there for
> > historical reasons.
>
> How about we drop +p as a separate m
On Thursday 12 Jun 2003 9:55 pm, you wrote:
> How about we drop +p as a separate mode and make it do +s for
> compatibility?
Yeah, or just remove it entirely, people would soon stop using it *g*
--
hikari
[EMAIL PROTECTED]
oper @ London.UK.EU.Undernet.Org
> I can't see a constructive difference between showing the channel names as
> Prv and hiding them completly. The only way it would make sense is the way I
> stated, otherwise +p and +s become analegous and +p is just there for
> historical reasons.
How about we drop +p as a separate mode
On Thursday 12 Jun 2003 9:30 pm, you wrote:
> channels should be listed with the channel name clearly shown... and either
> display the topic, or show "" (or something similiar) in
> it's place.
Which is pretty much what I said. +p *should* be visible on /list, but
should be hidden on a
I'd agree 100% The point I was making was that the historical versions of
ircu (2.9) showed them as "*"... at least 2.9.32 did. I would say that +p
channels should be listed with the channel name clearly shown... and either
display the topic, or show "" (or something similiar) in
it's place.
On Thursday 12 Jun 2003 8:25 pm, you wrote:
> Unfortunately for whatever reason this is _not_ the way the current version
> of ircu works. Both +p and +s are totally hidden from /list (it doesn't
> even show a "*" or "Prv" like some older ircd versions did).
I can't see a constructive di
At 18:23 12-06-2003, Tom Rons wrote:
> My view of it was this:
>
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
Why do I have the odd feeling that it's acually the other way around? :)
AFAIK +p channels are shown, but without their name (+s not sho
This is what I've always thought as well (though I thought the topics were
supposed to show up as well? I suppose that's a minor detail) and is borne
out in the way that I use +p on my own channels. I use it if I am going
somewhere and I don't want people in that channel to /whois me and follo
According to my look at ircu 2.9.32 (the last version of 2.9) it was the
other way around... except that the topics were also hidden for +ps.
if (cptr->user && !(SecretChannel(chptr) && !IsMember(cptr, chptr)))
{
nr--;
sendto_one(cptr, rpl_str(RPL_LIST), me.name, cptr->name,
Ummm... +p channels were _always_ showed in /list as I recall.
"Secret" implies totally secret -- i.e: you can't find out about it unless
you already know the name.
"Private" implies that your existence on the channel is "private" unless
they already know the name... or if they start /join'ing
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
>
are you sure its not the other way around?
> My view of it was this:
>
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
Why do I have the odd feeling that it's acually the other way around? :)
AFAIK +p channels are shown, but without their name (+s not shown in
list at all, if you're not on
>
> Although afaic we know longer send "Prv" as the channel name for a Private
> (+p) channel...I don't know if anyone ever did tbh. I believe the
intended
> operation is that Private channels will show up on LIST, without their
topic,
> but membership of the channel is not visible through use of
At 09:28 12-06-2003, you wrote:
On Thursday 12 Jun 2003 5:43 am, Captain Kirk wrote:
[snip /list +s/+p discussion]
My view of it was this:
Both show up on /list if you are in the channel.
Both show up on /whois'ing someone else if you are in the channel.
+p does not show in /list at all
+s shows
On Thursday 12 Jun 2003 5:43 am, Captain Kirk wrote:
> I always thought it was the other way around. If you set +p, the channel
> won't appear in /list but if you whois someone who "is" in the channel it
4.2.6 List Message
"[...] Private channels are listed (without their topics) as chann
>
> I have found what I think is a bug in the /list command. Mainly that +p
> channels do not seem to show up.
>
> It was always my understanding that the major (only?) difference between a
> PRIVATE and a SECRET channel is that PRIVATE channels show up in
> /list. This is the way I have always u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > This will block all eembots that were active on the channel because of =
> > 'Internal database doesn't match with server' and it is not compliant to =
> > the RFC1459. Can you please take a look at this?
I believe this is fixed in one of the rec
> > When someone parts a channel, the server will send a message to all =
> > clients that the one has parted
> >
> > in older versions it looked like
> >
> > PART #holland
> > now it is:
> > PART :#holland
> > with a semicolor before the #
> >
> > This will block all eembots that were active on t
Okay, just tried it! 8)Bug submitted on the site for 2.10.11
Note that I'll be forced to revert to the old version if we can't find why
the server isn't able to deal with netburst anymore in this version. 8(
regards,
radium
On the 6 Octobre 2002 22:45, you wrote :
> Greetings. As so
On Wed, Oct 09, 2002 at 12:14:03AM +0100, [EMAIL PROTECTED] wrote:
> I'm assuming this trivial fix will nail it (but haven't tested of course).
Update: tested, applied, deployed.
splidge
QuakeNet person
lt;[EMAIL PROTECTED]>
To: "C-C people" <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 6:18 PM
Subject: Re: [Coder-Com] bug with BAN cmd (level 74-)
NicoS,
it could maybe explain why, but it's still not normal that X lets USP get
ops to then deop it cause it isnt
/msg X op #chan [nick].
Feel free to correct me if I'm wrong.
Hidden
- Original Message -
From: "éL NìçoS" <[EMAIL PROTECTED]>
To: "Hidden" <[EMAIL PROTECTED]>
Cc: "Undernet Coder Committee" <[EMAIL PROTECTED]>
Sent: Friday, August
I might be mistaken, but I think this has something to do with the bot's
own level.
If I would have 400 access for exemple, I would be able to suspend someone
with 200 access, but not someone with 450. If I would wanna ban the host of
someone who has 450 access, X would normally execute this ban,
Hello Imad,
Sunday, June 16, 2002, 6:22:41 AM, you wrote:
Ie> hi , some one reported that on #coder-com
->> *x* access #close tracker2 -modif
Ie> -X- USER: Tracker2 ACCESS: 420 LU
Ie> -X- CHANNEL: #close -- AUTOMODE: None
Ie> -X- ** SUSPENDED ** - Expires in 0 days, 05:08:30 (Level 400)
Ie> -X-
I suppose we could have a separate list, but that just seems sort of
bureaucratic.
On Thu, 2 May 2002, Kev wrote:
>
> > All this talk about X ... Does that belong on this list?
>
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for
On Thu, 2 May 2002, Kev wrote:
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for this list.
"so nuh!"
--
Chris "_Shad0w_" Crowther
[EMAIL PROTECTED]
http://www.shad0w.org.uk/
> All this talk about X ... Does that belong on this list?
X is a module of GNUWorld, which is a coder-com-sponsored project.
Therefore discussion of it is appropriate for this list.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
Well, it's not actually a bug since X will automaticly remove bans that
are covered by more restrictive bans. Example:
I ban *!*[EMAIL PROTECTED] *!*[EMAIL PROTECTED]
And after that I set ban *!*@*, *!*@* implies that *!*[EMAIL PROTECTED]
and *!*[EMAIL PROTECTED] are banned, so X removes thease ba
All this talk about X ... Does that belong on this list?
In order to preserve synchronization it is necessary for
the servers to remove all bans that are overlapped
by a new ban that is set. That means that when someone
(including when that someone is X) sets a ban *!*@*
then ALL bans are remove
You'll have to excuse my feeble mind on this one:
> Thats indeed a bug, and when it'll be fixed, I think the unban issue with
> *!*@* can be forgotten. That cmd SHOULD remove only bans matching
> [EMAIL PROTECTED] (*!*@*) and not the 2 others (*!*[EMAIL PROTECTED] and
> the other)
When setting t
I would guess that the *!*@* ban overwrote the other 2 bans, since the other
2 bans were covered by the *!*@*, and therefore they were probably deleted
in favor of the *!*@* ban. Therefore, the only ban left in the channel
would be the 1 *!*@* ban, and therefore only 1 ban would be removed. :-)
On Wed, Apr 24, 2002 at 06:20:57PM -0400, Hidden wrote:
> Dear ircu coders,
>
> I think I found a very little bug and thought should let you know about it.
>
> /msg will say: no such nick.
> /notice will return nothing.
It's normal behaviour. You should *never* send an (automatic)
reply in
At 23:20 24/04/2002, you wrote:
>Dear ircu coders,
>
>I think I found a very little bug and thought should let you know about it.
>
>/msg will say: no such nick.
>/notice will return nothing.
>[18:16] -> *akvn* uh
>(Script/18:16:08) No such nick: akvn
>[18:16] -> -akvn- uh
From rfc1459:
T
> I think I found a very little bug and thought should let you know about it.
>
> /msg will say: no such nick.
> /notice will return nothing.
> [18:16] -> *akvn* uh
> (Script/18:16:08) No such nick: akvn
> [18:16] -> -akvn- uh
This is by design, actually. NOTICE is usually used when no resp
On Wed, Feb 27, 2002 at 07:37:03AM +1300, Isomer wrote:
> In this case it will not squit. It checks to see if the timestamp is
> more than 5 minutes in the *future* not the past, so lag will only make
> the test *less* likely to succeed.
Ah ok. What about that it seems to KILL the client
who cr
> While implementing apass1-2, my eye fell on m_create.
> It seems that what happens there should be changed.
>
> Firstly, the last exit_client KILLs sptr, a client. It doesn't SQUIT
> the server of sptr. But changing this into squitting the server of
> sptr would be at least as wrong - conside
Its missing a new language entry (You may have seen it used on Undernet
warning you not to give out passwords). To fix, run this from the doc/
directory in your gnuworld repository:
psql dbname I don't know if this is just buggy for me or not, I compiled a new
version of
> gnuworld for a "pl
Please do not send HTML email to this list.
> -X- AUTHENTICATION SUCCESSFUL as tang--X- Unable to retrieve
> response. Please contact a cservice administrator.
I'm not very familiar with X's current architecture, but two possibilities
come to mind. The first is that the language tables haven't
> > When doing /who ~* x and /who * it don't show all the users, even it don't
> > show a end of who list.
> > And it shows actions that the people send to the server.
>
> Just to eliminate the obvious--have you verified that this isn't a client bug,
> perhaps by telnetting to the server and attem
> My Oper password is 12 char long, I did a mistake when typing it and it
> worked. Example: /Oper Math MYPASSWORDWORD instead of MYPASSWORD
>
> Server version : u2.10.10.pl18.(release). *.PartyNet.Org
> B27eEFfHIKMpRStUvW
1) Please do NOT send HTML emails to this list. The HTML portion of your
When you crypt a pass it only crypts like the first
8 chars of it. It is the same when I oper up... you only have to type /oper
username first_8_char_of_pass. That is normal... nothing to worry about...
:)
~reed
R33D33R@UnderNet
R33D33R@PartyNet
PartyNet Network Administrator
- Ori
On Sun, 20 Jan 2002, Mathieu René wrote:
> My Oper password is 12 char long, I did a mistake when typing it and it
> worked. Example: /Oper Math MYPASSWORDWORD instead of MYPASSWORD
>
> Server version : u2.10.10.pl18.(release). *.PartyNet.Org
> B27eEFfHIKMpRStUvW
>
> Math
> [EMAIL PROTECTED]
>
i
> When doing /who ~* x and /who * it don't show all the users, even it don't
> show a end of who list.
> And it shows actions that the people send to the server.
Just to eliminate the obvious--have you verified that this isn't a client bug,
perhaps by telnetting to the server and attempting to r
1. Please do not use html formatted emails on this list.
2. the limiting of /stats etc was done in 2.10.10.pl something, when they
started hub hiding. your best option is to upgrade to the latest ircu
version where those options you are after are available.
--
xplora is wakco (Richard T Smith)
49 matches
Mail list logo
