[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
On 06/04/11 10:38, dothebart wrote: Di Apr 05 2011 12:39:14 EDTvon ajc a...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b Push to the project citadel.org : The branch, master has been updated via 2063519eeba1e97c13732f061faea42556e9488b (commit) from 7b25397a71281e53fc9aec4cca4a63d07e2658d8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=2063519eeba1e97c13732f061faea42556e9488b commit 2063519eeba1e97c13732f061faea42556e9488b Author: Art Cancro a...@uncensored.citadel.org Date: Tue Apr 5 12:39:09 2011 -0400 Remove all uses of __FUNCTION__ because it is not portable --- are you trying to achieve Visual Studio 6 compileability? I know this macro isn't portable, but most modern compilers offer it. I'm pretty sure that on GCC it isn't really a macro either - certainly you can't paste it to other symbols, and I'm pretty sure it's left behind after the CPP has finished its work. Sam
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
Mi Apr 06 2011 08:55:10 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b According to what I'm reading it doesn't work on Solaris (with Sun's compiler, not gcc). isn't that next to the age of Visual C++ and fading in relevance meanwhile?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
I'm probably the wrong person to ask. I think everyone should be running Linux.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 98077cf98a82f673c2bc0486e32187c30c267eb4
For a post-8.00 design, would it make sense to use libev as the housekeeping loop? Then it could take care of SMTP delivery along with everything else the server needs to do in the background, and we can dedicate a thread to it (either the supervisor thread or a different one) -- and then the ordinary worker threads can be used for interactive sessions.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Looks good so far. I also think that getting rid of all the extra complexity has fixed the RSS reader crashes.
[Citadel Development] Re:
Ok, here's more info on the problem: When the problem starts to happen (again, right after TDAP runs) -- CC-redirect_buffer no longer works for housekeeping threads (bound to masterCC). This means that the fulltext indexer is coming up with blanks too, which I've tentatively verified.
[Citadel Development] Re:
Perhaps I can run tests on a *clone* of Uncensored's db. Over the last two days I've seen the problem begin after the 04:00 hour; this happens to be when we run TDAP so it's definitely possible that we're looking at a memory issue of some sort. It might even be a massive memory leak triggered by TDAP, but I'm really suspicious as to why the only thing it seems to be affecting is outbound mail delivery.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Removed spurious calls to CtdlClearSystemContext() Hopefully that's what was causing the problem. We'll know by tomorrow morning.
[Citadel Development] Re:
I don't think we have the horsepower to run Uncensored under valgrind. It was bad enough when I constrained its I/O speed a little bit during the last migration -- the system was practically unusable. For the time being I have added a check to see whether msg_size is 0, and if it is, we syslog the problem and then 4XX defer the delivery instead of attempting delivery and losing the message. We can work on this problem in a bit more relaxed fashion as long as I know we're not throwing away mail.
[Citadel Development] Re:
There does seem to be a problem. When citserver is first started there is no problem, but after it runs for a little while, messages are getting corrupted as they are read into the buffer for sending. The symptoms showing up in the log are that the From: address is not extractable (so it's sent to the recipient as MAIL FROM: some...@somewhere.org ) and that we get the warning that the message did not end with a 0x10. I've temporarily added a diagnostic that dumps the buffer to /tmp/badmail.x.x when this condition is detected.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 1472e247d25c64dd52a1e0d8166946c003b74581
ok, seems as if I can send mail again, and now should be able to connect secondary mx'es. any fancy setup to test this around? where the first mx isn't available? btw, just ran citadel/webcit on a debian k/freebsd, and we have per user locale here! another problem we might get with libev in webcit... locales?
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 1472e247d25c64dd52a1e0d8166946c003b74581
libev in webcit? Why? The main loop of webcit is simple enough. It doesn't need libev.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. d8e37b83842f3724e21da6d191a86d91cd3f3f80
And maybe it's my imagination but I could swear it's faster this way. At the moment I'm using a fixed size thread pool. There are eight worker threads, one master socket listening thread, and one supervisor thread. I haven't decided yet whether I want to move the master socket listener back into the worker pool. What I can tell you is that I intend to make citserver's thread pool expansion algorithm identical to webcit's: start with a very small number of threads, and spawn a new thread whenever it is determined that there is 100% utilization, up to a fixed limit. There is no reduction of the pool size. I think any further architecture decisions will be based upon a discussion of how libev will eventually work. I am hoping that libev could eventually become the main loop for all worker threads.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 51a3c9712abdd33ec5871c40a7ae0354110b1883
There's gonna be a huge update coming up as soon as I get things running smoothly again. This is mainly intended to reflect the future migration to a libev-based architecture. The Citadel server is built as a state machine, so the libev move does make sense. This is fundamentally incompatible with the davew thread system, unfortunately -- it's brilliant code but it basically implements an entire multitasking operating system inside the application, which we really don't need. Since it's currently causing stability problems I am removing it. Step 1 will be to go back to the old threading architecture. Step 2 will be to migrate to libev. Then the server will be even *more* of a state machine.
[Citadel Development] Re:
yea, was quiet a bunch of discussions to encourage IG to finaly do it ;-) and, so far I don't think it was a wrong decision. you didn't read our nice commit mails for a while now? else you would have discovered code.citadel.org ;-)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. cc9210c238de95ad2005ef023897dbf5acecc31d
I'm a little hesitant to put that into 7.xx because I don't know how we fixed it. Somewhere along the line we did something to the I/O layer that made it stable enough for XMPP over TLS to work, but I don't know where or what.
[Citadel Development] Re:
So Jan 30 2011 14:09:11 EST von dothebart @ Uncensored how (and where) are the queue entries for mailinglist entries generated? hm, and Why do they read from room_aide in the mailq? just for the bounceto?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Fr Jan 28 2011 07:58:25 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well. since we frequently go over to the config room, how'bout up to n (maybe n=5) rooms? plus... I think it would be a good thing to have the 'last wirte' timestamp of a room, which could be used to revalidate the cache
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
On 27/01/11 23:25, IGnatius T Foobar wrote: Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to. I'm also concerned about the binary tree: If the binary tree is not bulk-populated at the start and in a balanced fashion, but rather as messages are seen, then if messages are seen in mostly numerical order, which will happen in folders with large numbers of messages - the sorts of folders where we really want the benefit of a binary tree, then we will end up with an unbalanced binary tree, which will be as bad as a linear search but taking up a lot more memory. Further, if the tree caches seen message, it means that if a message has been seen at all in a session, it can always be seen until the session logs out, even if the message has been removed from all rooms available to the user. In other words it makes it hard to withdraw access. Maybe the user hadn't even read the message, but merely had it loaded into a room index. The admin moves the message to a restricted room, but all users who ever had it listed in their index can still see it until they log out. It seems to me that the new code is worse than the old code in terms of memory usage, not better in terms of the cases that ought to benefit, and worse in terms of security. I think the binary search of the linear list that was committed is a better solution. If a binary tree is used, it should be a balanced tree. I think there are bigger potential performance gains than can be had here, if performance is a problem. Sam
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to.
[Citadel Development] Re:
Ok, I've built a VM on an IPv6 connected network for you to test with. Check your email for the login.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. f73ec44ea6fb12fe23b7a021993dff8a28cbe0f7
ok, so connecting ipv6 works now. whether the DNS routines output proper addresses still has to be proven. remaining todo list: - catch some more error conditions, especialy dns lookup fails - backup relay config (whops, how did I miss that?) - use libevent calls to add contexts instead of our own homegrown; this will most probably remove moste of serv_eventclient.c - use libevents shutdown callbacks to abort clients - context integration - instant queue wakeup on message save
[Citadel Development] Re:
Mo Jan 24 2011 21:41:25 EST von IGnatius T Foobar @ Uncensored so, first site with the libev based smtp client has just gone live... Do you need a machine on an IPv6 network to test it with? yes, but probably on both ends? i've asked my hoster for an ipv6 range, i'd need some mx that is ipv6 or some relay...
[Citadel Development] Re: 303 Status response
hm, it pro'lly would also straightn the code and reduce unneccesary cross-dependencies.. it should probably be 302 for 'temporarily moved' else one won't be able to post a second message ;-) Fr Jan 21 2011 04:32:36 EST von samjam @ Uncensored Betreff: 303 Status response W3C seem to have updated RCS's inlreation to the meaning and use of the HTTP 302 and 303 status responses: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html It looks like whether or not 302 or 303 is used should possible depend on the level of HTTP in the request. I would therefore like to suggest again, that where possible, citadel should not return body as a result of post, but save state and then issue a 303 to re-request the correct view. This avoids browser pain if/when the back button is used. I have no strong case to make, I merely mention it as potential best-practice. Sam 10.3.3 302 Found The requested resource resides temporarily under a different URI Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
[Citadel Development] Re: 303 Status response
This would work quite nicely with my current efforts to remove all of the round-trip form submissions in the system. For example, in the message editor, we no longer submit the form when adding attachments. It is my intention to validate recipients before sending the form as well. And in the calendar view, I would like to do free/busy checking without a submit.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272
Yes, the chat window uses that API as well, and I believe I've fixed it.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. c12b418a64b44be9d08cae0e5dd25c988a522b90
DNS, Ipv4 ipv6... such a boring SHIT! I finaly know why ipv666 adaptation is so slow: they made the (unpaid) software migration to it a pain in the ass.Most pro'lly the administrative migration process isn't any better. probably not yet all done with ipv6 + relay, but most of it. btw, i've heard that one should use braces when having ipv6 addresses in URLs like that: smtp://foo:bar@[::127:0:0:1]:666 so this is how one will be able to relay through an ipv6 host without dns.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. c12b418a64b44be9d08cae0e5dd25c988a522b90
The conversion of the existing Citadel code to dual-stack actually was far easier than I thought it would be.
[Citadel Development] Re: Message security
On 18/01/11 16:10, dothebart wrote: because of the use of cookie based authentication you can't do that with one browser. I did do it. if you're able to reproduce this with two browsers (run a chrome and a firefox) and we have a problem. Since the client knows the room its in, messages from wrong rooms will be displayed. Even after you explicitly log out of one of the accounts? What does logout mean in such a case? Is the message requested in the context of the logged-out account, or the new logged in account? Either way seems wrong. Sam
[Citadel Development] Re: Message security
Even after you explicitly log out of one of the accounts? What does logout mean in such a case? Is the message requested in the context of the logged-out account, or the new logged in account? Try it again now; it *should* theoretically act like any other web site at this point. If you log out from one window, the session should be logged out and the other window should reflect that as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272
That was kind of nasty. I thought that it was me who broke the ajax stuff, but it was actually the Prototype 1.7 upgrade. Everyone take note of this please, particularly when using ajax_servcmd. The parameters must be wrapped up inside EncodeURI() otherwise they will be truncated.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272
Mi Jan 19 2011 15:41:08 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272 That was kind of nasty. I thought that it was me who broke the ajax stuff, but it was actually the Prototype 17 upgrade. Everyone take note of this please, particularly when using ajax_servcmd. The parameters must be wrapped up inside EncodeURI() otherwise they will be truncated. does the chat window have similar problems? We had it sending requests without a directory component in some cases...
[Citadel Development] Re: Message security
There was, however, a problem with sessions not being *fully* logged out. I have just fixed that. I doubt we will ever have the ability to log in two different users at the same time from the same browser. On the other hand, I have been adding go= url components to a lot of the stuff I've been touching, so that if a user has two different windows open in two different rooms it'll try to keep each window in the correct room.
[Citadel Development] Re:
afaik REST doesn't say anything about authentication mechanisms at all; it primarily says that a resource should be identified by a uniq URL; so the floor roomname would have to be part of the URLs; its doable in some parts, parsing the URL (and message IDs) is a little trickier, since you need to find out whether the URL-Part identifies a part of a floor, roomname, message, or even sub-message. though using different rooms in different browser tabs would be possible with that .
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 48d166d046a07f716ed7ac59021f0cec96907054
I'm not shure if its all that smart; we should have talked about this first. did you distribute the syslog facilities for mailtraffic and such in an appropriate manner?
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 26ade12163f58929a68aa5acc2530c937185d665
aproaching alpha quality. implementation is next to feature complete; timeouts and async connections are handled properly. still missing is the relay code, and ipv6 support. I also want to give each client its own citadel context structure. and... maybe then we should be able to wake us up on freshly queued emails, and increase the polling on the queue to 10 minutes or such. next target would then be to generalize the queue room handling to the extnotify queue, and make that async too. when thats done, rss-client async, pop3 client async, networker async.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. be4674cca2834b773de2987330060227ffd3c020
hm, i'd like to keep at least one point of this; the log-chatty hider. I don't see a point in writing the 10015th SSLG-request, and it makes gdb scroll faster. Do Jan 13 2011 14:22:44 EST von "ajc" a...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. be4674cca2834b773de2987330060227ffd3c020 Push to the project "citadel.org ": The branch, master has been updated via be4674cca2834b773de2987330060227ffd3c020 (commit) from 12eef2e90231a57d2a436cb885ee2fed657747ea (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=be4674cca2834b773de2987330060227ffd3c020 commit be4674cca2834b773de2987330060227ffd3c020 Author: Art Cancro a...@citadel.org Date: Thu Jan 13 14:20:28 2011 -0500 Removed some old TECH_PREVIEW sections. We no longer use TECH_PREVIEW because of the split master/stable repos. --- Summary of changes: webcit/context_loop.c | 32 webcit/messages.c |6 -- webcit/static.c |3 --- webcit/vcard_edit.c |2 +- 4 files changed, 13 insertions(+), 30 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e396526ea63700bee599f96fc03e72fc8ea503c2
On 11/01/11 05:09, IGnatius T Foobar wrote: It's been a productive evening. :) Wiki now works and looks good, even in guest mode. Thanks very much. I'll give it a go. I'll give guest mode a go too, I've never tried that yet. Sam
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e396526ea63700bee599f96fc03e72fc8ea503c2
On 11/01/11 12:38, samjam wrote: On 11/01/11 05:09, IGnatius T Foobar wrote: It's been a productive evening. :) Wiki now works and looks good, even in guest mode. Thanks very much. I'll give it a go. Every time I edit a page, my signature get's added automatically to the top. Is this intentional? I note that wiki links with a space in are never able to be shown. The error message reports that the name (with spaces removed) is not available. No doubt the spaces are removed on retrieval but not on creation. I note that the subject line may be specified on creation and edit but is ignored. Are the wiki rooms safe to manipulate via imap? Or would they need magic headers with an RFC822 representation so as to make them easier to I was expecting cunning use of Supersedes: and In-Reply-To: and things like that... not that I'm complaining... (I see that the add-floors capability is still broken/missing) Sam
[Citadel Development] Re: edit room does not populate radio boxes
Mo Jan 03 2011 22:44:10 EST von IGnatius T Foobar @ Uncensored Betreff: Re: edit room does not populate radio boxes The edit_room view does not pre-populate radio boxes which the check mark, thus any room when editing shows all checkboxes as unchecked dothebart: this one is yours. It appears to have been broken when room_edit was templatized. tracked down and fixed.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 12eef2e90231a57d2a436cb885ee2fed657747ea
this one might be usefull in some cases. - -T6 now barfs the results of conditionals.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 12eef2e90231a57d2a436cb885ee2fed657747ea
That'll be quite useful -- I usually have to add temporary logging for just that purpose while debugging various things.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e396526ea63700bee599f96fc03e72fc8ea503c2
It's been a productive evening. :) Wiki now works and looks good, even in guest mode.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. ee15c03b742bbedd404642c9f1306fa3949d00c7
sam, this is the libevent branch, most likely you're using git-master; else you would be having troubles to sendmail out for about 3 weeks now, and your citserver would be leaky as a sieve. i'm currently having troubles making asynchroneous connects with libev; so I wanted to have c-ares out of the way as a possible source of problems. once I get it working, i'll re-enable it. Then i'll start cleaning up everything, and once this is done, i'll start migrating other client tasks (pop3 aggregator, rss agregator, citadel networker) to this scheme. we then will be able to run several smtp client connections at once, have next to infinity lengthened timeouts, and one blocking/slooow smtp server won't block your mailq anymore. Fr Jan 07 2011 09:17:06 EST von samjam @ Uncensored Betreff: Re: [SCM] citadel.org branch, libevent, updated. ee15c03b742bbedd404642c9f1306fa3949d00c7 Why disable c-ares? - I guess I'm using it. Should I rebuild with this commit? Sam On 07/01/11 11:07, dothebart wrote: Push to the project "citadel.org ": The branch, libevent has been updated via ee15c03b742bbedd404642c9f1306fa3949d00c7 (commit) via 83ff5dd0d51f8bc4e1f3a37e0eac3bbdc71af842 (commit) from d268f98de5cfcd79b55869b79cc08db6e028c108 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=ee15c03b742bbedd404642c9f1306fa3949d00c7 commit ee15c03b742bbedd404642c9f1306fa3949d00c7 Author: Wilfried Goesgensdotheb...@citadel.org Date: Fri Jan 7 12:05:22 2011 +0100 libev/libc-ares migration - disable c-ares for now - add fixed ip to connect instead of looked up ip http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=83ff5dd0d51f8bc4e1f3a37e0eac3bbdc71af842 commit 83ff5dd0d51f8bc4e1f3a37e0eac3bbdc71af842 Author: Wilfried Goesgensdotheb...@citadel.org Date: Fri Jan 7 12:04:21 2011 +0100 libev migration - shutdown cleanly. --- Summary of changes: citadel/event_client.c |8 +++-- citadel/modules/eventclient/serv_eventclient.c |3 +- citadel/modules/smtp/serv_smtpeventclient.c| 37 ++- 3 files changed, 29 insertions(+), 19 deletions(-) hooks/post-receive
[Citadel Development] Re: wiki still does nothing
If I select edit, and save the page, I still see the same message. No home page is ever created. Any advice here? Sam I can confirm that it's definitely broken and I will fix it.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2b54d172dce8b1b30dc9cc616edfab531dfeb207
I am a staunch supporter of the GPL. On the other hand, the rhetoric from RMS/FSF gets kind of tiring. I think ESR said it best in this editorial: http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-28-023-10-NW-SM
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2b54d172dce8b1b30dc9cc616edfab531dfeb207
(Oops ... the canonical location of this essay is: http://www.catb.org/~esr/writings/shut-up-and-show-them.html )
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 17f85f4eeb3f90bf584b483bb4d356f87271bf63
My intention is to completely remove the traditional login screen. All authentication will be performed through the modal dialog and ajax calls. Even on a closed system that does not have guest mode enabled, the login screen will just be a dumb banner with the login modal superimposed on top.
[Citadel Development] Re:
at first guess i'd say that nBytes=1168502 is wrong and citserver isn't sending that much, so it keeps on reading.. NBIO a timeout would be one solution...
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fdb030b497950239b2b7db63b3953f6a6f425f1e
I thought this was going to be done in a separate branch?
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. c973c74dd07b010e70477d31ca325a8d7ba28190
Last call for bugfixes, otherwise I'm going to release 7.85 tomorrow in order to get the networking fix into people's hands.
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. ecdc9e87a3ac4a50299291550c775cfcca783f34
The dialog is built in such a way that we can probably re-use most of it for other upload tasks. At the moment, I would like to focus on message entry. Rewriting the upload dialog wasn't actually what I started out trying to do. My goal was to eliminate all of the round-trips to the server during message composition. Originally I wanted to just add 'attach' fields to the form as they were needed, like GMail does, but it ended up looking very bad so I got the idea to do the popup dialog. Where I am going with this: The next step will be to perform a final validation on the message using ajax before submitting the entire message. If there are bad recipients or an access control problem, I want it to pop up an error. Only when everything is validated will the full message form finally be submitted to the server. The final goal is for the entire system to be usable without logging in. That's the main reason I added the modal dialog code last week.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a70ac03ebc6c5de716f6ff71c1663fffe66c4fbe
Qte! realy Qute. I'd like to add one todo... could you add a throbber to the screen while its uploading the files on send? The one we also show while loading the messages list in the mbox view? Yes, that's definitely something for the TODO list. Right now the problem is that I don't have a low-bandwidth connection to test it. 25 Mbps via fiber to my house, uploads finish instantly no matter how big :)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 4ba859fe5bed361aa7aa3b5a8c0b7c57d8ada1f4
have a look at that IG, its mostly what you did, plus wrap cunit around it... I wasn't familiar with CUnit so it's going to take me some time to figure everything out, but it looks like you simply changed my assert() calls to CUnit's equivalents, so yes, that's fine. I will use test_stripallbut.c as a template if I write any more unit tests. I like the idea of adding unit tests; perhaps in the future we can write some more that connect to citserver and do things like testing the IMAP service for accuracy etc.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. f7a17f83336a84d369f93fde2f164457a40616d9
I try to re-use localizations when I can. The string Attachments: was already in there.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd
Di Dez 07 2010 22:25:21 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd its supposed to find the last left boundary? The behavior of stripallbut() when multiple boundaries are found is *undefined*. However, my goal with this rewrite, aside from simplicity (and not crashing) was to attempt to find the innermost string, so we don't end up extracting a string that still has boundary characters in it. While repairing this function I wrote a test program that gave it every possible problem string I could think of. Since that work was already done, I took the liberty of adding it to the tests/ directory. I don't know how to integrate it into CUnit, though. So, how's the MIME parser fix coming along? it now prefers the binary decoder (which is also better then before now using memchr); just in case it detects base64 or qp it will use strchr. browser.mime contains a multipart form upload with a binary (.gz) Finding the attachment-id: ./mimeparser_test -f testdata/mime/browser.mime -p and extracting the zip: ./mimeparser_test -f testdata/mime/browser.mime -p -P 11 /tmp/foo.gz produces a file that gzip will decompress without problems. please check whether it works out for you now, if not, please grab a sample and add it.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd
its supposed to find the last left boundary? Di Dez 07 2010 11:32:27 EST von "ajc" a...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd Push to the project "citadel.org ": The branch, master has been updated via 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd (commit) from d5a9994ae97dd98e976069e4711b4428df9a0166 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=82a955f8397a6622d2e4ee11e0df8e83ddf44cfd commit 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd Author: Art Cancro a...@citadel.org Date: Tue Dec 7 11:31:35 2010 -0500 Rewrote stripallbut() again, tested extensively --- Summary of changes: libcitadel/lib/tools.c | 49 ++- 1 files changed, 19 insertions(+), 30 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. bb844ffeae944bb80257323b84d25d742488bf53
Yay! test coverage starts to show first green spots. http://debian.citadel.org/coverage/libcitadel/lib/index.html Di Dez 07 2010 16:27:03 EST von "dothebart" dotheb...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. bb844ffeae944bb80257323b84d25d742488bf53 Push to the project "citadel.org ": The branch, master has been updated via bb844ffeae944bb80257323b84d25d742488bf53 (commit) via 93732f7256027b1f90d92303aab28e479e0a2c00 (commit) from 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=bb844ffeae944bb80257323b84d25d742488bf53 commit bb844ffeae944bb80257323b84d25d742488bf53 Author: Wilfried Goesgens dotheb...@citadel.org Date: Tue Dec 7 22:27:52 2010 +0100 Add more test-mimecontainers. http://code.citadel.org/cgit.cgi/gitcitadel.org/commit/?id=93732f7256027b1f90d92303aab28e479e0a2c00 commit 93732f7256027b1f90d92303aab28e479e0a2c00 Author: Wilfried Goesgens dotheb...@citadel.org Date: Tue Dec 7 22:24:49 2010 +0100 Be more conservative about when not to apply binary searching for the next boundary or not. --- Summary of changes: libcitadel/lib/mime_parser.c | 10 +- libcitadel/tests/testdata/mime/bumperstickers.eml |16841 libcitadel/tests/testdata/mime/karsten_1.eml |101352 libcitadel/tests/testdata/mime/karsten_2.eml |90974 ++ .../mime/mail_with_multiple_attachments.eml|13548 +++ libcitadel/tests/testdata/mime/mortorary.eml | 60 + .../tests/testdata/mime/qp_with_extra_blanks.eml | 75 + libcitadel/tests/testdata/mime/spam_GB2312.eml | 2434 + .../tests/testdata/mime/spam_iso-2022-jp.eml | 322 + libcitadel/tests/testdata/mime/spam_koir8-r.eml| 100 + libcitadel/tests/testdata/mime/spam_utf8.eml | 79 + .../tests/testdata/mime/spam_windows-1255.eml | 98 + .../tests/testdata/mime/spam_windows-1255_2.eml| 90 + .../tests/testdata/mime/spam_windows-874.eml | 40 + 14 files changed, 226020 insertions(+), 3 deletions(-) create mode 100644 libcitadel/tests/testdata/mime/bumperstickers.eml create mode 100644 libcitadel/tests/testdata/mime/karsten_1.eml create mode 100644 libcitadel/tests/testdata/mime/karsten_2.eml create mode 100644 libcitadel/tests/testdata/mime/mail_with_multiple_attachments.eml create mode 100644 libcitadel/tests/testdata/mime/mortorary.eml create mode 100644 libcitadel/tests/testdata/mime/qp_with_extra_blanks.eml create mode 100644 libcitadel/tests/testdata/mime/spam_GB2312.eml create mode 100644 libcitadel/tests/testdata/mime/spam_iso-2022-jp.eml create mode 100644 libcitadel/tests/testdata/mime/spam_koir8-r.eml create mode 100644 libcitadel/tests/testdata/mime/spam_utf8.eml create mode 100644 libcitadel/tests/testdata/mime/spam_windows-1255.eml create mode 100644 libcitadel/tests/testdata/mime/spam_windows-1255_2.eml create mode 100644 libcitadel/tests/testdata/mime/spam_windows-874.eml hooks/post-receive -- citadel.org
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd
its supposed to find the last left boundary? The behavior of stripallbut() when multiple boundaries are found is *undefined*. However, my goal with this rewrite, aside from simplicity (and not crashing) was to attempt to find the innermost string, so we don't end up extracting a string that still has boundary characters in it. While repairing this function I wrote a test program that gave it every possible problem string I could think of. Since that work was already done, I took the liberty of adding it to the tests/ directory. I don't know how to integrate it into CUnit, though. So, how's the MIME parser fix coming along?
[Citadel Development] Re: MIME parser is broken
where do you see QP exactly? All I have to do is use WebCit to post a message in any room, and then read it. QP-encoding all over the place.
[Citadel Development] Re: MIME parser is broken
Also: uploading files (attachments, images, etc.) is broken. The form data stops when it gets to an upload file. It is important to repair this quickly because I have a commit almost ready that will *greatly* improve attachment uploading in webcit, but I can't test it until the MIME parser is fixed. (I'm getting WebCit in line with the other 'web 2.0' email programs. Attaching files will no longer require two different form submits, and we can get rid of the whole AttachList stuff too.)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a1cdf216c9d092490b69eb54566896b9463dc379
Sa Nov 27 2010 08:08:51 EST von "dothebart" dotheb...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. a1cdf216c9d092490b69eb54566896b9463dc379
Add test mime containers that (used to..) cause troubles in the recent past. Add mime-parser-testing tool to be able to test the mimeparser in an insulated binary, here we have a test, that reads a given file into memory, and parses it using the mime parser. More hickups found due to the mimetester; pre push. - the_mime_parser (): we need to know where parse_MimeHeaders() finds the end of the headers. - the_mime_parser (): don't move the pointer around just to count up to the end-pointer. this can be done by pointer substraction. - parse_MimeHeaders (): move the parameter so our caller gets to know what we read - parse_MimeHeaders (): if (ptr = content_end) after reading is probably a bug (also there in stable..), that makes us fail to read the last line, if. move it to the end of the pointer. - don't call strchr twice; remember evaluate the first result - stripping the disposition-header can be done right where we found it. fix crash: we want to do is_digit() on *char* not on char* some bug the mimetest found before push. First Step: chop mimeparser into pieces. - move the cluster of buffers into a struct compatible to the CKEY macro - add the interesting other evaluated flags numbers to that struct - move finding parsing of the 'interesting headers' into its own function. by all this we hope to get informations about the mimepart before we have to search for its end create mode 100644 libcitadel/tests/mimeparser_test.c rename libcitadel/tests/{ = testdata/emailaddresses}/email_recipientstrings.txt (100%) create mode 100644 libcitadel/tests/testdata/mime/badmsg.eml create mode 100644 libcitadel/tests/testdata/mime/browser.mime create mode 100644 libcitadel/tests/testdata/mime/endlessloop.eml create mode 100644 libcitadel/tests/testdata/mime/post_mimecontainer.mime create mode 100644 libcitadel/tests/testdata/mime/vcard_hides_message_content.eml
ok, big chunk. not yet all there. this moves the search for content-type friends into their own sub-function and does some more optimizations.
for easy testing there now is a tests/mimeparser_test to be called like this
./tests/mimeparser_test -p -f ./tests/testdata/mime/endlessloop.eml
(for example...)
where endlessloop.eml would be something one saved via imap/tbird ctrl+u
post_mimecontainter.mime is sniffed from webcit with a multipart mime post.
still want to create more flexibility when to call the 'interesting header - parser' so we can decide better where how to search for the next boundary.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. f56c54a0313a60d1a692dcae9fe3fbd9e25c4d8c
The homework helpers mail is parsing properly but it is *not* displaying properly. I see quoted-printable on the screen.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. f56c54a0313a60d1a692dcae9fe3fbd9e25c4d8c
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.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 81ad90568d8c00c2104339d2b132ba2945bb01f9
some tiny notes.. - we have ibstr - please use a strbuf to construct the URL - please use the HKEY macro where initialising strings instead of strlen there is...StrBufUrlescAppend; StrBufHexescAppend, (maybe you want to create a base64 wrapper instead?) - use StrBufAppendTemplate() to add your result to target; it offers the standard escaping methods to the token (see next point) - you probably don't want ?MAIL:SUMM:SUBJECT(X) in the URL but rather U So Nov 21 2010 23:27:37 EST von ajc a...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. 81ad90568d8c00c2104339d2b132ba2945bb01f9 Push to the project citadel.org : The branch, master has been updated via 81ad90568d8c00c2104339d2b132ba2945bb01f9 (commit) from 36821734e42c9200de69079d314b71c5a6b5526e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=81ad90568d8c00c210 4339d2b132ba2945bb01f9 commit 81ad90568d8c00c2104339d2b132ba2945bb01f9 Author: Art Cancro a...@citadel.org Date: Sun Nov 21 23:27:11 2010 -0500 Began working on a permalink system WARNING NOT WORKING YET --- Summary of changes: webcit/blogview_renderer.c | 23 +++ webcit/static/styles/webcit.css |9 + webcit/static/t/view_blog_post.html |2 +- 3 files changed, 33 insertions(+), 1 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. cea750b0e7430731f9a2c3497d235cd3f7a9b6b0
ok, here we are. ready for 7.85 had a little f'up with my netbook (now luckily fixed) so this took a little longer... So Nov 21 2010 10:42:19 EST von "dothebart" dotheb...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, stable-78x, updated. cea750b0e7430731f9a2c3497d235cd3f7a9b6b0 Push to the project "citadel.org ": The branch, stable-78x has been updated via cea750b0e7430731f9a2c3497d235cd3f7a9b6b0 (commit) via 1a37eeac261dc02832db6a4974e3cbdc14c16780 (commit) via 6e935843af551a20cecd7428770068877587f305 (commit) from 49c07036805a7cda3fb8d61557a03a46b864daab (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=cea750b0e7430731f9a2c3497d235cd3f7a9b6b0 commit cea750b0e7430731f9a2c3497d235cd3f7a9b6b0 Author: Wilfried Goesgens dotheb...@citadel.org Date: Sun Nov 21 16:34:16 2010 +0100 Relax SMTP Client timeout settings as discussed. - default is 30 seconds - Server greeting 90 seconds (DNS lookups for RBLs might be slow - Server sending the response to the EOM sequence; here we might have background processing like virus or spam scanning that wants to finish before finaly accepting the message. http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=1a37eeac261dc02832db6a4974e3cbdc14c16780 commit 1a37eeac261dc02832db6a4974e3cbdc14c16780 Author: Wilfried Goesgens dotheb...@citadel.org Date: Sat Nov 6 12:18:23 2010 +0100 Nonblocking sockets need to select while writing we changed the SMTP outbound connections to be nonblocking so we could abort on not reacting SMTP-Servers. thus we need to select before writing, else the connection will fail. http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=6e935843af551a20cecd7428770068877587f305 commit 6e935843af551a20cecd7428770068877587f305 Author: Wilfried Goesgens dotheb...@citadel.org Date: Sat Nov 6 13:51:41 2010 +0100 have flexible timouts while reading lines in our client mode connections since some mailserver take a little longer to finish reading mails we need to wait after we send our '.\r\n'; its 90 seconds now, all other parts will wait 5s, quit will wait 1 second. --- Summary of changes: citadel/clientsocket.c | 66 ++ citadel/clientsocketh |4 +- citadel/modules/smtp/serv_smtp.c | 20 ++- citadel/msgbase.c|2 +- 4 files changed, 66 insertions(+), 26 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re: installation failed
On 17/11/10 20:17, IGnatius T Foobar wrote: how to install citadel on centos 5 i did easy install, Log in as root and enter the following command: rm -rf / Don't do that. I'm guessing that IGnatius was just over-tired. If you are running roundcube, then you are probably running apache, so you need to either run webcit on a different port or use the apache proxy passthrough module. Sam
[Citadel Development] Re: installation failed
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.
[Citadel Development] Re: installation failed
Yeah well Exchange does that all on its own :)
[Citadel Development] Re: (no subject)
On 16/11/10 22:29, dothebart wrote: Ok, most of the needed bugfixes were cherry-picked into stable-78x. this one i'd like to discuss first, 'caus its a little more intrusive then the other ones; its changes are primarily intended to get a SMTP client timeout: http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=a1b7d9e895e73401161427363611b0160f51225f http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=9148bf110ec104dd6035c8f511d4c88afb276278 Client-sockets are in non-blocking mode now; we have timeouts after which we abort the SMTP-sesison. This saves us from trapping into tarpits, or just connecting to SMTP-servers that won't send us a greeting within 5 seconds. I think 5 seconds is a bit low for normal slowness. Although most sites respond more quickly, 5 seconds is still a short cutoff. Some sites have a latency of a few seconds, and if they need do do DNS lookup as well over a congested link, 5 seconds will cause failure needlessly. I'd favour at least 30 seconds. Sam
[Citadel Development] Re:
Mi Nov 17 2010 16:09:04 EST von Spell Binder @ Uncensored Subject: SMTP client timeout. Would it be overkill to make the timeout values be configurable from the admin screen? Spell for 7.90 probably not, 7.85 definitely yes.
[Citadel Development] Re: (no subject)
Nov 17 2010 3:32am from samjam @uncnsrd in Mail to room_citadel_development@uncensored.citadel.org Subject: Re: (no subject) On 16/11/10 22:29, dothebart wrote: Ok, most of the needed bugfixes were cherry-picked into stable-78x. this one i'd like to discuss first, 'caus its a little more intrusive then the other ones; its changes are primarily intended to get a SMTP client timeout: http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=a1b7d9e895e7340116 1427363611b0160f51225f http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=9148bf110ec104dd60 35c8f511d4c88afb276278 Client-sockets are in non-blocking mode now; we have timeouts after which we abort the SMTP-sesison. This saves us from trapping into tarpits, or just connecting to SMTP-servers that won't send us a greeting within 5 seconds. I think 5 seconds is a bit low for normal slowness. Although most sites respond more quickly, 5 seconds is still a short cutoff. Some sites have a latency of a few seconds, and if they need do do DNS lookup as well over a congested link, 5 seconds will cause failure needlessly. I'd favour at least 30 seconds. Sam Actually, this is a value that we might want to allow configurability on... This would allow the system administrator to make a judgement call as to how long he/she feels is appropriate, and also put Citadel on par with other MTAs regarding configurability of this particular issue. - Stu
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a
Di Nov 16 2010 10:51:03 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a IG, could you have a look at this? why does the mentioned pointer contain invalid data instead of NULL? could you clean that up? *facepalm* char event_jid[256]; It's an actual buffer, not a pointer. It didn't need to be freed in the first place. aww. *gna* do the copy operations protect it from overflowing?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a
Yes, everything is done using safestrncpy()
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a
So Nov 14 2010 22:26:44 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a 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? #if 0// TODO: why do we have an invalid pointer here? if (ptr-event_jid != NULL) free(ptr-event_jid);#endif that one.
[Citadel Development] Re: IMAP on outlook express
with current git master? or older revisions? I've tried with outlook 2k3, and fixed a bug last weekend. if that doesn't fix their trouble, could you please do a tcpdump? (see the faq for details)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a
Sun Nov 14 2010 17:16:49 EST from "dothebart" dotheb...@uncensored.citadel.org Subject: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=1bca8e52ac5e6713c26867195fffed2e49861f0e commit 1bca8e52ac5e6713c26867195fffed2e49861f0e Author: Wilfried Goesgens dotheb...@citadel.org Date: Sun Nov 14 23:11:40 2010 +0100 Memleak: free the XMPP-Eventqueue on shutdown TODO: the event_jid member contains an unclean pointer, no clue why. --- Summary of changes: citadel/modules/xmpp/serv_xmpp.c |4 +++- citadel/modules/xmpp/xmpp_queue.c | 21 + 11 files changed, 97 insertions(+), 3 deletions(-) -- citadel.org IG, could you have a look at this? why does the mentioned pointer contain invalid data instead of NULL? could you clean that up?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a629da83391d58813cc962f6c52d991868b10e3a
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?
[Citadel Development] Re: Commit log to refs/heads/master
Mo Okt 25 2010 10:58:01 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: d9f66010689b4b008677c138f077b00e0f5f0be6 webcit/messages.c webcit/messages.h webcit/msg_renderers.c branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs Use new MSet-Matcher to retrieve seen state (10% of what we do in big mboxes) whew. cool. from 15.72 % down to 0.55 % in a similar usecase.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 225dd04dbe1f36c04a8d62a32db6111d99d6ac70
better. no artificial line breaks. let the viewer handle linebreaks where appropriate. in other news: anouncing http://code.citadel.org/ our cgit installation. CIA anounced shorter URLs will point there, and match the right commit Mi Okt 27 2010 14:58:03 EDT von "ajc" a...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. 225dd04dbe1f36c04a8d62a32db6111d99d6ac70 Push to the project "citadel.org ": The branch, master has been updated via 225dd04dbe1f36c04a8d62a32db6111d99d6ac70 (commit) from 1ff5766f84fac1d651d3fcb18cb500555f1ad302 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 225dd04dbe1f36c04a8d62a32db6111d99d6ac70 Author: Art Cancro a...@citadel.org Date: Wed Oct 27 14:53:46 2010 -0400 Added a little bit of clever _javascript_ to make the TinyMCE window occupy the full height of the browser window. --- Summary of changes: webcit/static/t/edit_message.html | 11 +-- webcit/static/t/richedit.html |4 +++- 2 files changed, 8 insertions(+), 7 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 015ce67f6ed15cd794e878058938bef6fcc69095
hmz, damn. full commit diff gone, link to cgit right, but no commit texts... *grml* Mo Nov 01 2010 05:44:11 EDT von "dothebart" dotheb...@uncensored.citadel.org Betreff: [SCM] citadel.org branch, master, updated. 015ce67f6ed15cd794e878058938bef6fcc69095 Push to the project "citadel.org ": The branch, master has been updated via 015ce67f6ed15cd794e878058938bef6fcc69095 (commit) from e5704e28c3be6d94b9e8f498ce66012f237fcf14 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://code.citadel.org/cgit.cgi/git.citadel.org/commit/?id=015ce67f6ed15cd794e878058938bef6fcc69095 --- Summary of changes: webcit/po/webcit/el.po | 31 +++ 1 files changed, 19 insertions(+), 12 deletions(-) hooks/post-receive -- citadel.org
[Citadel Development] Re:
oh, thanks; didn't search for it over there... if I didn't, will others too? is that going to be the primary 'issue' people have with webcit 7.90 and float citadel support then?
[Citadel Development] Re:
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. :)
[Citadel Development] Re:
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.
[Citadel Development] Re:
yep, the current version is definitely much better. It removes all needs to go to older messages most of the time by simply displaying them. we're all curious how your thread view will look like ;-)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 826932b012c26b5ef97a5bbf45acf10fca6acc60
So Nov 07 2010 15:53:26 EST von IGnatius T Foobar @ Uncensored Betreff: Re: [SCM] citadel.org branch, master, updated. 826932b012c26b5ef97a5bbf45acf10fca6acc60
When I see the words "rewrite IMAP module" I get very very scared. How many different clients were tested to make sure nothing broke?
so far? imaptest and thunderbird.
Imaptest: me has a question here. it groans over imap_fetch.c:
/* * Fetch RFC822-formatted messages. * * 'whichfmt' should be set to one of: * "RFC822" entire message * "RFC822.HEADER" headers only (with trailing blank line) * "RFC822.SIZE" size of translated message * "RFC822.TEXT" body only (without leading blank line) */void imap_fetch_rfc822(long msgnum, const char *whichfmt) {
if (IMAP-cached_rfc822 == NULL) {...
if (!need_body) cprintf("\r\n"); /* extra trailing newline */
if thats here (commented it out for testing, success then) imaptest complains about that it doesn't find the closing ')' from that reply. TSS in irc://##imap gave me the hint that this linebreak mustn't be there.
since I didn't find a usefull commit message for that line, IG, do you remember a specific reason why its there anyways?
in general, that rewrite wasn't intended to change syntax in by any means; its there because of evolutions imap implementation can't stand us sending the greeting in several tcp packages (cut where i've added the linebreaks):
CAPABILITY IMAP4REV1 NAMESPACE ID AUTH=PLAIN AUTH=LOGIN UIDPLUS
ACL
STARTTLS
METADATA
citadel blablabla
which now come in one chunk like that:
CAPABILITY IMAP4REV1 NAMESPACE ID AUTH=PLAIN AUTH=LOGIN UIDPLUS ACL STARTTLS METADATA citadel blablabla
which is achieved by replacing cprintf by calls writing to outbound buffers which is then sent to the client in one piece at the end.
There are several tiny exceptions from it, where the code chatters with the client without the dispatcher loop (hope I found all of them)
Next i've replaced all "%s BAD lorem ipsum\r\n" , Params[0].Key by a function implicitely prepending Params[0].Key' ' and appending '\r\n' So we don't need a printf here in most places (which is good because of it saves us lots of strlens ;-)
the other part of the rewrite is to replace the rumpelstilskin handler lookup by a hashtable filled a start time.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 826932b012c26b5ef97a5bbf45acf10fca6acc60
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.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 826932b012c26b5ef97a5bbf45acf10fca6acc60
Nov 9 2010 9:08pm from IGnatius T Foobar @uncnsrd Subject: Re: [SCM] citadel.org branch, master, updated. 826932b012c26b5ef97a5bbf45acf10fca6acc60 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. Amen to that... And, it looks like we are broken with Evolution 2.30.3 right now on copy and move operations (both SSL and non-SSL). Need to look at the code to figure out what's going on...
[Citadel Development] Re: Commit log to refs/heads/master
So Okt 10 2010 17:11:53 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: 67105603363528dbc622cac30927e4759c01cee6 citadel/debian/citadel-server.install branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs include the URL-shortener config in the .deb how many of these damn shorter url services are around there? I thought after a week or two i'd have them all, I just follow 3 tweets, and they keep on comming... now its a config file.
[Citadel Development] Re: Commit log to refs/heads/master
Mi Okt 13 2010 15:51:27 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: fb181fc0c1be1f3f05e7891e635c2ad5503b3abc citadel/sysdep.c branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs vCtdlLogPrintf(): combine the server data plus the application format string into a new format string we then process with va_args. - still no strbuf needed - no problems with race conditions causing clashes between several lines it seems as if the 7.84 version of vCtdlLogPrintf leaks (which is pretty uncool) the Rewrite of the Rewrite of the Rewrite neither leaks, nor needs a strbuf nor writes in several chunks; plus it has some dynamic server side aditions like the TID which was the source of starting to change it was initialy. time to start thinking about 7.85?
[Citadel Development] Re: Commit log to refs/heads/master
Do Okt 21 2010 13:05:35 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: Merge branch 'master' of ssh://git.citadel.org/appl/gitroot/citadel lets see whether this works out for the automatic import. re-bootstrap required to do this the right way.
[Citadel Development] Re: Commit log to refs/heads/master
Di Okt 05 2010 23:26:02 EDT von "Art Cancro" a...@citadel.org Betreff: Commit log to refs/heads/master Files: bed4ff700cc3c215f561a5ed0c637b951a814f3e webcit/blogview_renderer.c blog view - retain msgid and refs in array using strbuf for later sorting into threads are the refs already citadel message ids? else I think its probably a good thing to use lookup3 to create a hash value which can be used for sorting afterwards
[Citadel Development] Re: Commit log to refs/heads/master
Fr Okt 22 2010 15:08:00 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: d62a8c8ef6806683067f0c25f243b67206f787a1 citadel/context.c citadel/context.h citadel/include/ctdl_module.h citadel/serv_extensions.c citadel/threads.c branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs if we're shutting down instantly close our server file descriptions branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs if we had problems shutting down because of client threads still blocked, close all sessions fd's so they come to an end. ok, finaly fed up with that shut down thingabob. this _instantly_ closes our server sockets so no more new sessions can be established in first place. I had the symptom figured: netcat an ssl port (without saying a word into it) and no shutdown would finish. when the first warning message about "we're not shutting down but we want to" arives, walk all client contexts, and close their fd's. we probably still would have issues with pop3 aggregators or RSS-clients hanging, we don't have a way to access their FD's so far, right?
[Citadel Development] Re: webcit: Splitting vcard_edit.c into templates not too trivial
this is not just about the editor; its about how vcards are printed in general... like the address book popup... and so on.
[Citadel Development] Re: webcit: Splitting vcard_edit.c into templates not too trivial
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.
[Citadel Development] Re: webcit: Splitting vcard_edit.c into templates not too trivial
Don't spend too much time on the vCard editor. I will probably rewrite it in the not too distant future.
[Citadel Development] Re: Two commits at GitHub: Trying to clean some older HTML to learn
Well, I don't really have the time to do it, but it's a reasonable idea.
[Citadel Development] Re: Two commits at GitHub: Trying to clean some older HTML to learn
Thu Sep 30 2010 18:11:43 EDT from dothebart @ Uncensored Subject: Re: Two commits at GitHub: Trying to clean some older HTML to learn hm, where do I get the url to pipe it into git am? Just realized that didn't really answer your question. But I think you can do it to ways: Fetch the GitHub repository read-only into a separate directory with the URL from my last message, and then do things like: git remote add citadel git://git.citadel.org/appl/gitroot/citadel.git git fetch citadel git format-patch -o /tmp citadel/master..cbcd09d02d90ebab2441 That reverses the viewpoint, the master Citadel repository is called citadel in my repository dir and my repository at GitHub is called origin in this case. So you can export patches between the citadel master copy and the GitHub repository. I don't know what's better for you, when I have projects with multiple independent git repositories, I usually just add multiple remotes and then merge and cherry-pick from there, then commit to a master repository. Or should I just submit patches as files here? I've attached those two anyhow.From 29791c63e7197492b7343747d8691aac2b865b4e Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Ram=C3=B3n=20Cahenzli?= ramon.cahen...@gmail.com Date: Thu, 30 Sep 2010 19:55:13 +0200 Subject: [PATCH] Added indentation to the table. --- webcit/static/t/aide/edituser/detailview.html | 104 + 1 files changed, 71 insertions(+), 33 deletions(-) diff --git a/webcit/static/t/aide/edituser/detailview.html b/webcit/static/t/aide/edituser/detailview.html index 8396782..8b4acd8 100644 --- a/webcit/static/t/aide/edituser/detailview.html +++ b/webcit/static/t/aide/edituser/detailview.html @@ -4,37 +4,75 @@ h1?_(Edit user account: )?USERLIST:USERNAME(X)/h1 /div div id=content class=service -table class=useredit_backgroundtrtd -form method=POST action=edituser -input type=hidden name=username value=?USERLIST:USERNAME(X) -input type=hidden name=is_new value=?BSTR(is_new) -input type=hidden name=usernum value=?USERLIST:UID -input type=hidden name=nonce value=?NONCE -input type=hidden name=flags value=?USERLIST:FLAGS -centertable -trtd?_(User name:)/tdtdinput type=text name=newname value=?USERLIST:USERNAME(X) maxlength=63/td/tr -trtd?_(Password)/tdtdinput type=password name=password value=?USERLIST:PASSWD(X) maxlength=20/td/tr -trtd?_(Permission to send Internet mail)/tdtdinput type=checkbox name=inetmail value=yes ?%(COND:USERLIST:FLAG:USE_INTERNET, 1, 1, 1, checked, )/td/tr -trtd?_(Number of logins)/tdtdinput type=text name=timescalled value=?USERLIST:NLOGONS maxlength=6/td/tr -trtd?_(Messages submitted)/tdtdinput type=text name=msgsposted value=?USERLIST:NPOSTS maxlength=6/td/tr -trtd?_(Access level)/tdtdselect name=axlevel -option ?%(COND:USERACCESS, 1, 1, #AxDeleted, 'selected=selected', ) value=00 - ?_(Deleted)/option -option ?%(COND:USERACCESS, 1, 1, #AxNewU, 'selected=selected', ) value=11 - ?_(New User)/option -option ?%(COND:USERACCESS, 1, 1, #AxProbU, 'selected=selected', ) value=22 - ?_(Problem User)/option -option ?%(COND:USERACCESS, 1, 1, #AxLocU, 'selected=selected', ) value=33 - ?_(Local User)/option -option ?%(COND:USERACCESS, 1, 1, #AxNetU, 'selected=selected', ) value=44 - ?_(Network User)/option -option ?%(COND:USERACCESS, 1, 1, #AxPrefU, 'selected=selected', ) value=55 - ?_(Preferred User)/option -option ?%(COND:USERACCESS, 1, 1, #AxAideU, 'selected=selected', ) value=66 - ?_(Aide)/option -/select/td/tr -trtd?_(User ID number)/tdtdinput type=text name=usernum value=?USERLIST:UID maxlength=7/td/tr -trtd?_(Date and time of last login)/tdtdselect name=lastcall - option selected value=?USERLIST:LASTLOGON:NO?USERLIST:LASTLOGON:STR/option - option value=?DATE:NOW:NO?DATE:NOW:STR/option -/select/td/tr - -trtd?_(Auto-purge after this many days)/tdtdinput type=text name=purgedays value=?USERLIST:DAYSTILLPURGE maxlength=5/td/tr +table class=useredit_background + tr +td + form method=POST action=edituser + input type=hidden name=username value=?USERLIST:USERNAME(X) + input type=hidden name=is_new value=?BSTR(is_new) + input type=hidden name=usernum value=?USERLIST:UID + input type=hidden name=nonce value=?NONCE + input type=hidden name=flags value=?USERLIST:FLAGS + center + +table + tr +td?_(User name:)/td +tdinput type=text name=newname value=?USERLIST:USERNAME(X) maxlength=63/td + /tr + tr +td?_(Password)/td +tdinput type=password name=password value=?USERLIST:PASSWD(X) maxlength=20/td + /tr + tr +td?_(Permission to send Internet mail)/td +tdinput type=checkbox name=inetmail value=yes ?%(COND:USERLIST:FLAG:USE_INTERNET, 1, 1, 1, checked, )/td + /tr + tr +td?_(Number of logins)/td +tdinput type=text name=timescalled
[Citadel Development] Re: Commit log to refs/heads/master
hm, maybe the leading / is wrong? /webcit/ should have been entered by the user in advance, and webcit just ignores/keeps it. remember that you need to restart webcit if you add new files to any of its static template directories. Yes, there shouldn't be any links to external resources ;-)
