The homework helpers mail is parsing properly but it is *not* displaying
properly. I see quoted-printable on the screen.
The homework helpers mail is parsing properly but it is *not*
displaying properly. I see quoted-printable on the screen.
Actually, it seems that quoted-printable is being displayed all over the
system.
I'm more concerned with the fact that he posted a newbie installation question
to the developer list. It shows that he didn't bother to read the instructions
for requesting help.
Yeah well Exchange does that all on its own :)
Yes, everything is done using safestrncpy()
IG, could you have a look at this? why does the mentioned pointer
contain invalid data instead of NULL? could you clean that up?
Which pointer are we talking about here?
It's still there. I moved it up into the nav bar.
Nope. Uncensored will be running the new WebCit too, so if they can't find
the save button then they can't post messages complaining about it. :)
We'll do what we always do -- deploy it first to Uncensored and see how it
is received by the user community. It wouldn't be the first time we had a
UI design rejected. I was really proud of the dynamic BBS view but nobody
liked it.
so far? imaptest and thunderbird.
Until you've also tested Outlook, Pine, whatever Apple is using these days,
and a mobile client or two ... assume that your patch broke them all.
Seriously.
IMAP is that fragile.
Sure, there's a ton of that kind of work that needs to be done. I do it when
I'm already in there somewhere and notice little things that need adjusting,
but having someone around to focus on it would be great.
Don't spend too much time on the vCard editor. I will probably rewrite it
in the not too distant future.
Well, I don't really have the time to do it, but it's a reasonable idea.
Not working yet, but I'm going to make it work. CSS3 has rounded edges,
gradients,
and drop shadows. It makes no sense to do this any other way. Please bear
with me for a little while as I build a new CSS3 based theme.
The sad thing is that I'm going to have to live with Internet Explorer as
my reference browser for a while just because it's the most broken.
Ok, we're switching to git. I remain ambivalent about the subject, but since
it is in high demand I will go with the flow here.
My needs are simple ... even CVS worked just fine for me.
Our source code repository will be offline until the conversion is complete.
Ok folks, commit 8f713e8bba92ebb93a9a486d81ec7e966583fd9e in branch stable-78x
is the official 7.84 release of all components. tarballs have been built
and uploaded.
Yes I did, but it has not been implemented.
Personally I use the terminal as much as I use the GUI. I wish they
would lose the mach kernel one day though. I'd love to see OS X be
based on straight *BSD.
Let me get something clear, then ... was your trouble report involving the
Terminal application or the console? Is there
Just curious - if additional information (for a plugin, etc.) needs to
be added to a user's profile, what is the best way to accomplish that
w/o modifying internal structures? This information would need to be
secure from modification by the end user.
What I normally do is
It would be much easier, but I can't guarantee exactly when I'm going to have
the chance to work on it.
Nope. It's either there or it isn't. I suppose you could drop the table
:)
while we should continue our stable branches in SVN, I'm all in for
switching HEAD to git right now. Can we? Please?
I'm not maintaining two different repositories. It's going to be one or
the other.
I'm reading some documentation and tutorials on git, and it looks like something
that's only useful for developing the Linux kernel ... essentially not the
right tool for a project like ours that relies on a central repository.
Why do we want all of this extra complexity?
That's ok, I think we're going to ditch the rounded boxes in the next theme
we build.
Ok, there we go.
The previous IPv6-only implementation required a hybrid stack host such as
Linux or FreeBSD, on which the listening address in6addr_any causes it to
accept both IPv6 and IPv4 connections on the same socket. I was ok with
dropping
support for OpenBSD, but when I found out
Citserver doesn't have IPv6 yet.
Not that anonymous after all?
Not for someone with admin rights.
Perhaps we can find a better way of automating it?
I suppose we could just eliminate the #define entirely, and then every place
we need CC we could just do
struct CitContext *CC = MyContext();
That's a lot of noise, of course, but if you're going to put struct CitContext
*CCC = CC;
seems to me as if you've nuked logging to syslog?
if (enable_syslog) {
vsyslog((syslog_facility | loglevel), format, arg_ptr);
}
Nope
Looks like I'm seeing failures on IMAP partial fetch here... Citadel is
returning a null response after upgrading to 7.80. Also tried the
newest 7.81.
To replicate, use Alpine to view messages with Quell-Partial-Fetch set
to off.
Fixed in r8703 (both trunk and stable).
I have pushed Citadel 7.80 to Easy Install. Source tarballs will follow soon.
As soon as we are sure everything is working smoothly, we will open the
stable_78x
branch. Until then, all commits should be for bug fixes only.
Gaah, that was a pain in the ass to fix.
* entroom (): after creating a room, don't display the empty room but rather
display the advanced room editing screen.
What? What if the user is not an Aide and doesn't have permissino to edit
the room?
a list of addresses to send spam to?
it's that time of year again ... i'm at the beach this week, but the rental
house now has high speed internet so i'll be online. we should work on the
7.80 release, i think we're pretty much there.
Not to worry, we're just about to 7.80 -- I fixed most of the remaining IE
problems today, and hopefully will have everything tested with all browsers
and ready for release by the end of the week. Then we can branch 7.8x-stable
and start working on Citadel 8.
IG, maybe this: http://c-ares.haxx.se/ could be a solution to our
nslookup blocking stuff? It also would cover the ivp6 part of
nslookups...
Are we blocking on lookups? I'm pretty sure we're blocking on connection
attempts. Or am I wrong about that?
hm, and maybe another idea... Could you run ntop on hawthorne for a
while? it would show whether for example spam attacks are the reason
for these hickups...
Already running. http://quark.xand.com/mrtg/ghettobaystack_17.html
This really is a bizarre bug. Maybe it's some sort of race condition. What
I can tell you is that sometime between when we fetch the server greeting
(always a 200 ready) and when we call get_serv_info(), the server socket dies.
If you run it in the debugger you get a SIGPIPE.
There is just no sensible explanation for this. One moment we're reading
the server greeting, the next moment the socket is toast. citserver doesn't
provide an explanation either.
Ok, now we're getting somewhere. 4 alerts in the last 8 hours. It isn't
locking up; it's getting the message Received unexpected answer from Citadel
server; bailing out.
maybe you'd like to add a debug statement here??
Yes, that's obviously the right thing to do; I haven't been writing webcit
logs but it's probably time to start. :)
Ok, here's the answer:
The INFO command returned a *blank line*.
I'm working on this too. It isn't actually that specific server command.
WebCit's ability to receive server replies appears to be broken by the time
get_serv_info() starts. When I began checking the output of the IDEN command,
it failed there too.
I just added some code to check the
Very weird. We had another unexpected response error with those checks
in place. The server passed the 200 banner check, but then by the time we
got into get_serv_info(), the server responses became blank.
The next time it happens I will try to analyze it from the citserver side
to see if
Even with the longer timeout on the watchdog script, it's still firing from
time to time. I really don't know what's happening, because the cores all
show the same thing: all threads waiting on accept(), except for the
housekeeping
thread, which is sleeping.
I am going to disable the
Ok. Just so you know, a couple of weeks ago I switched from protoaculous
back to discrete copies of prototype and scriptaculous, in order to support
better manageability.
I suspect that Chrome will eventually overtake Firefox as the leader in
non-Microsoft
web browsing, just like Android will overtake iPhone/iPad in the portable
space.
But for the time being, I have to spend a few days using IE as my WebCit
test browser, because that's where the brokenness
hmmm ... as far as I can tell, the networking problem is due to the server
getting stuck with doing_queue permanently set to 1, for some reason, so it's
not accepting polls.
Scratch that ... it's another I/O layer problem!
(gdb) bt
#0 0x0051b7f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x006bc89b in write () from /lib/libpthread.so.0
#2 0x080750fb in sock_write (sock=0xb6cf5ff8, buf=0x80bde78 \n, nbytes=1)
at clientsocket.c:286
#3 0x08075184
One more thing I can indicate now: we're hung up on Uncensored performing
a read() operation during a network session that it initiated towards dogpound2.
dogpound2 is running stable code.
If you have a Blogger account, it can be used as an OpenID provider too.
I assume you've tested this with an actual OpenID account to make sure it
still works?
I'm not at all familiar with the way this new chat implimentation works.
It's a lovely new protocol that sacrifices efficiency for simplicity by having
the client poll the server for new incoming messages every few seconds. It
doesn't use START_CHAT_MODE and it relinquishes control of the
Uncensored will do an upgrade to svn head and automatically restart services
at 2:30am US Eastern time.
Hmm ... I don't think it happened. Dunno why. :(
The queue was backed up a couple of days ago. At the moment I'm sending all
mail out through a pool of smart hosts, so it'll get delivered faster. We
have to revisit mail delivery at some point.
probably just because i'm used to memcpy; I thing strndup will check
for \0 while copying which we don't need to since we know the length?
We're going to continue to have a difference of opinion on this. I still
prefer readability and maintainability over shaving off a handful of cpu
Let's not mess with it yet -- the module is not finished. The reason I'm
maintaining this xmpp mortuary is because when a Jabber client logs in,
the first thing we have to do is flush out all of the roster entries that
existed in all previous sessions. Stupidly, XMPP doesn't have a way to tell
So there wasn't a Delete operation at the time I started writing this? Oops
:)
At the moment, the key and value are both the full address. If you want
to change it to a hash later, that's fine, but please let me finish the
application
logic first.
Ah, you found my bug and fixed it already? Thanks!
Ok, I see that. When you call Put() you're transferring control of the memory
to the hash table; it doesn't copy it over.
But why did you fix it the long way instead of just calling strdup() ?
Considering that Uncensored is currently spinning 100% cpu on citserver, I'd
say that's still the big issue.
hm, it seems as if the next page link is added if there is no new
message for that page yet.
Is that intended? or is it a bug?
It has to do with the calculation of the number of messages per page ...
there's an off-by-one condition that triggers in certain situations.
The CHAT command was implemented during a time when we didn't use worker
threads;
every session was bound to one socket and one thread, and that was it.
Yes, we'll get past that, but NOT RIGHT NOW!!
Also keep in mind that START_CHAT_MODE is also used in some other places,
for example,
I don't see much sense debugging it in the state its currently in.
So let me get this straight ... the chat code that has been working fine
for 12 years, needs to be rewritten because it doesn't work nicely anymore
after you changed the transport underneath it?
This is my problem why?
Ok, well I do agree that the chat protocol is suboptimal and needs to be
rewritten
.. just not during a feature freeze. In the future we should make the chat
protocol look more like the instant message protocol.
If we need to stop the bleeding, right now we could just disable the server
If we switch to git will it screw up davew's ability to eventually merge his
branch?
I'll be in and out of consciousness all weekend long.
Ok, now Uncensored is running on svn head. I accidentally "upgraded" to the stable-77x branch.
Found a bunch of stray characters in de.po while upgrading that broke the build. Not sure how they got there but I removed them.
Right. If there is a - in that fourth position, it MUST continue reading
until
it sees a in the fourth position.
Ok, I looked at those diffs and they were indeed quite straightforward without a
lot of surface area for new bugs.
I'm at a VMware seminar this week so I have limited computer time, but I'll
update my dev system when I get a chance to test the most recent fixes.
Cool, I'll test it when I get a chance.
if it gets fed with
[[a][b]], '[', ']'
what should the result look like?
To be honest, I haven't thought about that. Since it starts on the left side
first, it would probably extract b .
The fix was going to be to make sure the request messge was in the
current room.
Anyone know if this has been fixed?
Not yet.
Hmm, SMTP outgoing fails? since when? I'm running my branch server and it
seems to be working fine and its merged with the trunk HEAD (more or less).
Well, a couple of days ago when I upgraded Uncensored to svn trunk/head we
began
to see a problem where all outgoing SMTP
* CtdlOutputPreLoadedMsg: use length calculated by safestrncpy instead of
doing
strlen on each loop iteration
No really, I mean it, NO MORE OPTIMIZATIONS until we fix the bugs introduced
by
all previous optimizations!!
Ok, due to too many problems in the current svn trunk, I have reverted Uncensored to older code. I'm going to be having a very busy week (spending most of it at a VMware seminar and will be away from my office) so it was important to get things stable for now.
Here are some problems with the
hmm ... that didn't fix it. The problem is somewhere else. :(
which fixes the saving of messages via imap.
messages copied in so far are b0ken, their unparsed headers are glued
together without newlines :-(
I think the reason I thought there was more to it than that was because it had
gone unnoticed for a long time.
By the way, it
let me take an educated guess... It fails to output a \0 if there is
a string without newline?
so aoeu\0aoeu wouldtrigger the issue?
That sounds about right. We are definitely giving it strings without a
trailing
newline.
When pidgin sends to webcit the message is slightly corrupted. Seems the last
char is dropped and probably the terminating NUL too.
I have identified this as a bug in memfmout(). When I use cprintf() it goes
away.
I don't know if this is related to characters missing in messages, but I've
been
noticing that room names being deleted by the DAP are having the last
character
truncated as well in the Aide room posts.
This could quite possibly be a memfmout() or fmout() issue as well!
client connections are timed out based on lastcmd which means they never time
out because every client sends NOOP
Is this correct / intentional?
That is correct. It's not intended to log off idle humans; it's intended to
kill off stale connections.
I made several assumptions on the types of contexts that could be selected on
and which ones to check the fd of after select. Maybe these assumptions are
flawed.
What exactly happens to the context when an async message is sent?
Check out modules/xmpp/xmpp_queue.c arolines
Fix async messages (hopefully).
Nope.
If you send a message from Cit client to pidgin the message doesn't arrive.
Got that bit.
Question. Does the message from Cit client arrive when pidgin sends a new
message to Cit client?
It should, at least it did when I tested it.
Pidgin should also receive
As soon as my pidgin sends to the citserver the citserver dives off into an
endless loop in dothebarts new buffered IO code.
Now thats a different problem that causes me issues instead.
I didn't see that, but perhaps I'll try it again.
By the way, Citadel clients *poll*
Ok, it seems that the buffered I/O *is* causing a problem.
sysdep.c : 1147
HaveMoreLinesWaiting() *always* returns 1, until the session ends. As a
result,
we never fall through the loop until the session is ending, which explains why
we
never get around to processing our async
Using SVN, or doing anything else, on Windows is SO VERY WRONG.
BIG PROBLEM!
Sometime recently, something broke in the main server context loop.
Asynchronous events are not firing. This is a big problem for the XMPP service,
which makes heavy use of its async loop in order to determine whether there are
any events in the queue which require action
#0 0x08058bbb in worker_thread (arg=0x0) at sysdep.c:1083
1083if ( (FD_ISSET(ptr-client_socket, readfds))
(gdb) bt
#0 0x08058bbb in worker_thread (arg=0x0) at sysdep.c:1083
#1 0x08077cbf in ctdl_internal_thread_func (arg=0x9fd08a0) at threads.c:839
#2 0xb7e5f50f in
New buffered I/O code crash:
#0 0x080594f2 in client_write (buf=0xb6dc4df0 250 Message accepted.\r\n,
nbytes=23) at sysdep.c:488
488 FD_SET(Ctx-client_socket, wset);
(gdb) bt
#0 0x080594f2 in client_write (buf=0xb6dc4df0 250 Message accepted.\r\n,
nbytes=23) at
it seems as if the new bbsview fails to mark everything read?Â
behaves a little funny to me over here.
Same as before. Messages are marked as read when you Goto out of the room.
davew: yes, it's been running very nicely. I think you got it this time. We
will continue to observe its operation for a while.
* use mmap to read the download file for output; this way we don't need to
copy
it into memory first and can let the kernel do this job
Does mmap() read the whole file into memory at the kernel level? Or does it
merely provide userspace with the illusion that this has happened?
Fair enough. Is it portable?
It's about time. So we do have to figure out what code we have in our framework
that exists solely to support obsolete browsers. That'll be the challenge.
(Matt? Thierry? Anyone know for sure?)
Not a problem, let me know when you're ready. And don't worry, it won't
saturate
a 2M link because most of the spam is for accounts that don't exist (actually,
all of it, since I'm not actually running that company, but I did activate a
couple of addresses such as info@ so a little of the mail
I would say that it should be decoded by libcitadel when the vcard is
deserialized into our in-memory data structure.
701 - 800 of 1678 matches
Mail list logo
