> Fr Sep 11 2009 12:02:22 EDT von IGnatius T Foobar @ Uncensored Betreff:
>Re: Citadel commit log: revision 7806
>
>Hey look, the commit logs are back. :)
>
>
>
>
>
what's actualy been wrong with them?
Hey look, the commit logs are back. :)
At the moment I am not concerned with premature optimization, because it
still isn't working correctly.
> Di Sep 08 2009 23:59:48 EDT von IGnatius T Foobar @ Uncensored Betreff:
>Re: Citadel commit log: revision 7793
>
>Ok, that takes care of the truncate issue, but there's still something
>weird about this. Manipulating the flag on the very last message in the
>list doesn't work. I s
Ok, that takes care of the truncate issue, but there's still something
weird about this. Manipulating the flag on the very last message in the
list doesn't work. I see the code there to handle that condition, but I
don't see why it isn't working.
On the good news side, however, citserver is no longer looping on
CtdlSetSeen().
> So Sep 06 2009 22:32:42 EDT von IGnatius T Foobar @ Uncensored Betreff:
>Re: Citadel commit log: revision 7779
>
>
>>* fix it some, but not all.
>>
>
>As of right now, the bug is still there -- it's still looping endlessly
>when I try to open the inbox on my dev system.
>
>* fix it some, but not all.
As of right now, the bug is still there -- it's still looping endlessly
when I try to open the inbox on my dev system.
> Fr Sep 04 2009 14:40:14 EDT von IGnatius T Foobar @ Uncensored Betreff:
>Re: Citadel commit log: revision 7774
>
>The other issue is performance. That function was *highly* tuned, after
>I took a lot of abuse for it running very slowly when operations are
>performed on very large m
The other issue is performance. That function was *highly* tuned, after I
took a lot of abuse for it running very slowly when operations are
performed on very large mailboxes (2 messages or more). If the
introduction of StrBuf incurs a performance penalty, this is a problem.
Ok, but we have to be REALLY REALLY CAREFUL here. citserver will not
tolerate the kind of subtle bugs that have crept into WebCit during the
adoption of the StrBuf class.
No need to retro-patch; I'll release it as 7.64.
Is anything currently in the trunk unstable? Or can we just release
what's there now?
In this case, TFM describes in great detail how I feel about people who whine
for support on software that has been declared as unsupported. It's a good
read. :)
> READ THE README FILE. READ IT SEVERAL TIMES.
fsck that noise. We are men. We don't need TFM.
Ok, for those of you who were looking for a convenient way to auto-submit
Citadel messages into SpamAssassin for training its Bayesian filter,
here's a quick and dirty utility to do it.
READ THE README FILE. READ IT SEVERAL TIMES.
> Thu Aug 06 2009 08:52:11 EDT from BOFHMike @ My Castle Realm Subject:
>Re: Citadel commit log: revision 7724
>
>
>
>
>> Thu Aug 06 2009 02:08:13 EDT from IGnatius T Foobar @ Uncensored Subject:
>>Re: Citadel commit log: revision 7724
>>
>>
>>We've fixed enough heinous bugs ove
> Thu Aug 06 2009 02:08:13 EDT from IGnatius T Foobar @ Uncensored Subject:
>Re: Citadel commit log: revision 7724
>
>
>We've fixed enough heinous bugs over the last couple of days to justify a
>7.61 release, so I went ahead and did it. This was worth doing even if 762
>comes right behind
We've fixed enough heinous bugs over the last couple of days to justify a
7.61 release, so I went ahead and did it. This was worth doing even if
7.62 comes right behind it.
> Mon Jul 27 2009 10:16:50 am EDT EDT from IGnatius T Foobar @ Uncensored
>Subject: Re: evolution and namespaces
>
>And it looks like they've already marked it as a dupe.
>
>Evolution's failure to behave properly with namespaces is a colossal
>failure on their part. They should eit
And it looks like they've already marked it as a dupe.
Evolution's failure to behave properly with namespaces is a colossal
failure on their part. They should either map the namespaces properly or
not support them at all.
Of course, this is Ximian (aka Novell) we're talking about h
It's an edge case, to be sure, but we might as well fix it now before
someone inevitably finds it later and starts complaining about it.
I was skeptical about the json format and client-side rendering at first,
but now that I'm getting used to it I'm starting to see how versatile it
is.
That appears to have fixed the remaining bugs. Thanks, Matt.
Let's all give this a good solid testing before we release it. Everyone
please hit this code (the mailbox view particularly) with everything
you've got.
Ok, all yours, Matt ... here's where we stand:
* Group select is working
* Multi select is partially working. Clicking on an unselected message
will select it, but clicking on a selected message will not unselect it.
* Hitting "delete" appears to perform the correct server op
Aha! Now this is some real progress:
WCLog('startMarkingFrom=' + startMarkingFrom + ', finish=' + finish);
for(var x = startMarkingFrom; x
Here's what I've done so far:
* Renamed rowId and markedRowId to rowIndex and markedRowIndex, to
reflect the fact that we are working with current on-screen index
positions rather than the order in which the rows were loaded from the
server
* Used the expression "parent.rowIndex" t
Still trying to make sense of this ... what I'm starting to see now is
that it attempts to determine the range of messages for group select with
row numbers based on the order in which they were received from the
server, NOT the order in which they appear on the screen. So, if the
table was so
Ok, there are still some problems in this. I don't think the data model
has been fully updated. There are still references to *.ctdlRowId in the
code. I updated one of them, and that produced valid starting and ending
row numbers, but the group select still didn't work.
I also see a re
Still doesn't work ... I'll see if I can help figure out why.
Hmm ... as far as I can tell, ctdlRowId isn't assigned a value anywhere.
Matt, any thoughts on this?
Looking into the group select bug ... so far I'm seeing that these
expressions are failing:
markedRowId = parent.ctdlRowId;
var rowId = parent.ctdlRowId;
The expression "parent.ctdlRowId" is undefined. This causes the group
select operation to mark rows 0 through 0, which
Umm ... I hate to say this, but ...
... group select is broken again.
(Testing using svn head and Firefox 3.0.11 on Linux)
It's fine as long as you've tested it with all supported browsers.
Yes, all good ideas; unfortunately it's one of those things that the core
team just doesn't have enough time available to do. We've definitely left
the door open for this to be done in the future ... or in the present if
someone volunteers to help out :)
>Does the Citadel project have any start on an automated test suite? Â
Or
>any documentation of manual tests, for that matter?
Yes, look at stress.c for a small test suite. It isn't comprehensive but
it does work.
> I agree that "edit" is confusing in most vires, but most mailers to
provide
>the option to edit a message as a new message, so I'm also not entirely
>comfortable removing it.
I'm not comfortable having it there unless it works! I'm sure it broke
on its way into the tree, but
Citadel's RSS reader is a hand-coded mapping of RSS directly into the
Citadel message base. It's fewer than 600 LoC because we *didn't* bolt on
some big library that has lots of features we'll never use.
(Unfortunately the same cannot be said for the HTTP-client portion, but
libCurl did
* dothebart wrote, On 12/06/09 13:57:
>
>
>
> Fri Jun 12 2009 14:25:20 CEST from samjam @ Uncensored Subject:
> Citadel commit log: revision 7566
>
>
>
> Fri Jun 12 2009 05:11:08 AM EDT from dothebart @ Uncensored
> Subject: Citadel commit log: revision 7566
>
>
* dothebart wrote, On 12/06/09 14:00:
>
> ups. the save to drafts already trapped me.
>
and it posted to the room instead of Drafts.
Probably the goto _DRAFTS_ failed (if citadel supporting _DRAFTS_ wasn't
updated, or if you don't have a Drafts folder) and the != 2 type meant
that the goto failure
* dothebart wrote, On 12/06/09 08:06:
>
> Sam I'll apply it for now.
>
> Though i'm not shure whether this is correct.
>
> I think having another *0==NULL should continue comparing rather than
> aborting the search as success. (so do continue instead of return in
> your patch)
>
> IGnatiusTFoobar s
>Heh - I didn't mean "hurry up and do it" I meant, any ideas on how it
could
>be portayed?
Rather simply, actually. Amend the output of the RWHO server command to
include an extra field indicating an IM-capable session. Any session not
advertising the ability to receive IM's sho
Thanks for the patch; it has been applied.
We don't really know what happened to davew. He just disappeared one day
and never came back.
This needs a re-bootstrap too; I changed the format of the Hdr struct.
For a manual delete, we remove the message number from the room's msglist
and then write a record to refcount_adjustments.dat containing the msgnum
and the number "-1" to indicate that the message has been removed from one
room.
When the autopurger runs, one of the last things it does is
doesn't the autopurger do the final clean up of these at nite too while on
delete it just tags them deleted?
ok, overwriting would be a problem, but would that message have the same
citadel id?
I'd primarily want something so an external application could do clean up of
its database, so sort
That sounds expensive.
The autopurger lives in modules/expire/serv_expire.c
Do you want notifications of a message's removal from disk, or from a
particular room?
If it is the latter then I suppose we could write out a flat file as we
do the purge, and process it asynchronou
>Comments? Complaints?
How many weeks did we just add to the 7.60 development cycle by doing
this now?
the message is already rendered. for example >>> is converted to
's
in HTML messages your work added the resampling of inline images...
view_message_replyquote.html is the compactest template to view that.
there's work ongoing to render it into a json struct too.
> Wed May 13 2009 3:15:52 am EDT EDT from dothebart @ Uncensored
>Subject: Re: Citadel commit log: revision 7451
>
>
>
>
>> Mi Mai 13 2009 02:35:21 EDT von samjam @ Uncensored Betreff: Re:
>>Citadel commit log: revision 7451
>>
>>
>>
>>My nephew suggests an additional text/html
> Mi Mai 13 2009 02:35:21 EDT von samjam @ Uncensored Betreff: Re:
>Citadel commit log: revision 7451
>
>
>
>
>> Tue May 12 2009 5:34:36 pm EDT EDT from IGnatius T Foobar @ Uncensored
>> Subject: Re: Citadel commit log: revision 7451
>>
>>
>>>Thanks for reading our minds and th
> Tue May 12 2009 5:34:36 pm EDT EDT from IGnatius T Foobar @ Uncensored
>Subject: Re: Citadel commit log: revision 7451
>
>
>>Thanks for reading our minds and then coding it for us, guys! Nice once!
>>
>
>
>The hard part has been getting the framework to do this in place. Now tha
>Thanks for reading our minds and then coding it for us, guys! Nice once!
The hard part has been getting the framework to do this in place. Now
that it's here, stuff like this is easy. And it just seemed like the
right thing to do.
Ok, looking good here. I'll have to learn how to use all these new toys
when I start building some of the new components.
I did notice something wrong, though: the Notes view is now broken.
Instead of showing the notes themselves it now shows MIME headers.
I'm hoping to get some t
ok, big chance to fuck up everything.
if server related io stuff goes wrong, tell me.
don't forget to make clean.
samjam: this is all great stuff. I wasn't familiar with socat; it looks
like just the thing to make the php framework usable without the clumsy
session proxy.
I only plan to check that, if nothing was read, or better, if the select
doesn't indicate that we 've got more to read.
> Tue Apr 21 2009 2:34:57 am EDT from dothebart <> Subject: Re: Citadel
>commit log: revision 7384
>
>
>
>there are two possible causes:
>
>* StrBufReadBLOBBuffered() is fed by the wrong size to read by wrong
>calculation
>
>* StrBufReadBLOBBuffered() is trying to continue to read, while
there are two possible causes:
* StrBufReadBLOBBuffered() is fed by the wrong size to read by wrong
calculation
* StrBufReadBLOBBuffered() is trying to continue to read, while the other
party is gone
* StrBufReadBLOBBuffered() is fed by the wrong size to read because of for
example a 'cont
Ok, here's where it's hanging up...
#0 0xb8083424 in __kernel_vsyscall ()
#1 0xb7e5810b in read () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7ec0d56 in StrBufReadBLOBBuffered (Buf=0x94296f8, IOBuf=0x940b118,
BufPos=0x93eda14, fd=0x93eda0c,
append=1, nBytes=607, Error=0xb
Ok, I can log in now, but in several places WebCit is now just sitting
there spinning forever ... I'll try to figure out why
>I'd also like the verbose MSGS output to output all the citadel headers,
not
>just a few; or maybe I'll implement a streaming mode into the php
session
>proxy so I can do a request-headers efficiently...
This I'm not so sure about. We have to keep performance in mind -- any
>I'm suggesting that a search for an empty header (wefw|) should also
match
>messages without that header.
Ok, this seems reasonable enough that you should go ahead and try it;
please watch for side effects. A good place to do regression testing
would be load/save of preferences
> Fri Apr 17 2009 3:16:21 pm EDT from samjam <> Subject: Re: ctdlphp +, git
>tree
>
>
>
>
>> Fri Apr 17 2009 1:15:32 pm EDT from IGnatius T Foobar <> Subject: Re:
>>ctdlphp +, git tree
>>
>>samjam: I'm afraid I don't quite understand what you're asking to do.
>>
>>
>>
>>
>>
>>
>>
> Fri Apr 17 2009 1:15:32 pm EDT from IGnatius T Foobar <> Subject: Re:
>ctdlphp +, git tree
>
>samjam: I'm afraid I don't quite understand what you're asking to do
>
>
>
>
>
>
I'm trying to find a MSGS template to select messages without a references
header which count as top-lev
samjam: I'm afraid I don't quite understand what you're asking to do.
> Fri Apr 17 2009 8:51:59 am EDT from samjam <> Subject: Re: ctdlphp +, git
>tree
>
>
>
>
>> Sat Apr 11 2009 5:01:15 pm EDT from samjam <> Subject: Re: ctdlphp +,
>>git tree
>>
>>
>>
>>
>>> Fri Mar 27 2009 14:59:02 EDT from IGnatius T Foobar <> Subject: Re:
>>>ctdlphp +, git tree
> Sat Apr 11 2009 5:01:15 pm EDT from samjam <> Subject: Re: ctdlphp +, git
>tree
>
>
>
>
>> Fri Mar 27 2009 14:59:02 EDT from IGnatius T Foobar <> Subject: Re:
>>ctdlphp +, git tree
>>
>>
>>>I'm using ctdlphp to write a blog front-end that exposes public foldersand
>>>
>>>
>>
Well, there goes the first Brown Paper Bag (tm) bug. My fault, too. The
build fails if OpenSSL development libraries are not present, because
there were a couple of lines of code that weren't wrapped around #ifdef.
Easy Install has been updated, and I'll follow through with updated
sour
> Fri Mar 27 2009 14:59:02 EDT from IGnatius T Foobar <> Subject: Re:
>ctdlphp +, git tree
>
>
>>I'm using ctdlphp to write a blog front-end that exposes public foldersand
>>
>>
>
>>shows messages that start a thread as blog posts (full html with embedded
>>
>>
>
>>images etc) an
Ok, that about wraps it up for LDAP authentication. If anyone wants to
test it out I'd love to hear what you think of it.
I ended up having to offer two different modes, one for the standard
RFC2307 schema, and a different one for Active Directory's ugly
nonstandard schema.
Hi -
I would second keeping 0 as the exit code. This is "standard knowledge" and
would significantly increase needless questions... as well as possibly "turn
off" those new to Citadel due to the initial stress caused by using the
non-standard values in the first place.
- Stu
> Mon Apr 06 2
citing got the same conditionals as viewing, viewings sequences were altered
to make the sense more clear. I hope they're right the way they are, My
feeling tells me 3 should wrap 4, but I think you edited that part last?
Was anything changed in the conditionals other than the numbers? (I just
need to know how extensively we need to re-test.)
Ok folks, please observe that we now have a STABLE branch. Any
last-minute bug fixes made between now and the 7.50 release need to be
committed to *both* the stable branch and the trunk.
That doesn't mean we can be careless with the trunk, though. I would
like the 7.6X development
As per my comments on irc earlier today ...
* I really think it's a bad idea to throw away 30 years of unix tradition
by declaring some value other than 0 to be the non-failure exit code.
This will certainly mess up a lot of third-party scripts out there.
* If we have the need for
> Mi Apr 01 2009 12:20:59 EDT von IGnatius T Foobar <> Betreff: Re:
>crashdetect..
>
>The normal exit path is through master_cleanup() in citserver.c, line
>231 if it's an error-free shutdown. exit(exitcode) where exitcode == 0.
>
>
>
>
>
>
since there probably is no way to chan
> Thu Apr 02 2009 12:48:02 EDT from IGnatius T Foobar <> Subject: Re:
>Citadel commit log: revision 7283
>
>Ok, there it is ... you should be able to switch back to DLAT now.
>
>
>
>
>
>
Thanks - my work-around was faulty anyway, I think it would have failed to
recognize when DLAT
Ok, there it is ... you should be able to switch back to DLAT now.
Yikes. DLAT is missing the MIME metadata. Must fix that immediately.
The normal exit path is through master_cleanup() in citserver.c, line 231
if it's an error-free shutdown. exit(exitcode) where exitcode == 0.
sorry, since stunnel did the job, I thought doing it the same way we do it in
smtps would be an easy shot.
If we want to do SSL-encrypted Jabber, here's how to do it:
1. Edit serv_xmpp.c and search for "starttls"
2. Change "#ifdef HAVE_OPENSSL__COMMENTED_OUT" to "#ifdef
HAVE_OPENSSL"
3. Note that we have the exact same problem that is experienced with the
port-5223 implementation: the
Ok, well, if this cannot be made to work reliably and immediately, then
these changes should be rolled back.
It "hung" because citadel server crashed! - at least according to the
messages in my Aide room.
No core was generated (although I had cores generated on crashes a few weeks
ago and I did nothing to turn them off); so I turned core dumps on again and
I'll get some backtraces I hope.
Sam
> S
> Sat Mar 28 2009 10:45:26 EDT from IGnatius T Foobar <> Subject: Re:
>Citadel commit log: revision 7278
>
>Hanging after the SSL negotiation is exactly what happened when I tried
>to implement this the preferred way (using a 'starttls' stanza in the
>protocol). I haven't been able to figu
Hanging after the SSL negotiation is exactly what happened when I tried to
implement this the preferred way (using a 'starttls' stanza in the
protocol). I haven't been able to figure out why it does that, which is
why I never finished that function.
And ... we're supposed to be in a fea
>I'm using ctdlphp to write a blog front-end that exposes public folders
and
>shows messages that start a thread as blog posts (full html with
embedded
>images etc) and threaded replies as blog replies.
Sounds *very* useful. We don't currently render threads but the
underlyin
Only one more table to go!
The "c_" prefix isn't for "citadel" it's for "config". I don't care about
the tag names being globally unique, as long as they're unique within this
one application. All of our configuration variable names start with "c_"
already, and wherever possible I'm keeping the tag names identical to th
> Wed Mar 25 2009 13:42:07 EDT from IGnatius T Foobar <> Subject: Re:
>Citadel commit log: revision 7261
>
>I am simply not planning to write a DTD, that's all. The program's
>output looks like this:
>
>
>
>743
>
>testhost015
>testhost015..com
>Foo Bar and Baz
>US
I am simply not planning to write a DTD, that's all. The program's output
looks like this:
743
testhost015
testhost015..com
Foo Bar and Baz
US 800 555 1212
0
...
> Tue Mar 24 2009 23:48:27 EDT from IGnatius T Foobar <> Subject: Re:
>Citadel commit log: revision 7261
>
>
>
>Oh, and in case anyone was wondering: the XML exported by this module will
>be well-formed but not valid.
>
>
>
>
>
>
In what ways do you anticipate it being invalid xml
Those of you who have been paying attention over the years are probably
asking yourselves, "What's going on here? Doesn't IG hate XML?"
Well, we've got a situation here where the data could appear in any
order, and potentially with fields missing, so it seems that XML actually
is the rig
After a lot of review and consideration, I'm just not happy with the extra
complexity introduced by the xmacros stuff. I really think I'd prefer to
keep it simple, and if serv_vandelay is being replaced, now's the time to
make that decision, before any more time is spent on it.
It's an i
Copy isn't always appropriate either ... although I suppose a copy from a
public room into a mailbox is. Now isn't the time to be adding features,
though.
My opinion on that is, as already told on IRC, while it might be simple, it
doesn't fit into whath mail.aliases is intended for, and our plans to remove
this somewhen.
Probably Your original problem, Mailinglist rooms prefixing [roomname] to the
subject should be solved,
and adding a hard to
>Hey you think we can apply this to WebCit to get it to recognize primary
>email address when editing vCards made with Sync Kolab?
Hang tight, I'll do this the right way
Because, y'know, comments that are DFSG-compliant are better than comments
that are guaranteed to be accurate to the RFC. Grumble grumble grumble.
>so that nice link to citadel.org in every login screen won't be
evaluated at
>all...
>
>shouldn't we allow that in a way? is there a way?
For now, it's fine to just tell robots to go away.
Citadel v8 will need something more sophisticated than that, because the
new
>i'd like to release beta 7.42 with that. any objections?
Go for it!
1301 - 1400 of 1884 matches
Mail list logo
