[Citadel Development] Re: Commit log to refs/heads/master
Wed Sep 29 2010 6:46:48 am EDT EDT from dothebart @ Uncensored Subject: 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. no doubt, as you say, the leading / is wrong. remember that you need to restart webcit if you add new files to any of its static template directories. In my case it was browser-side caching. Yes, there shouldn't be any links to external resources ;-)
[Citadel Development] Re: Setting up a build environment to work with the source release
Wed Sep 29 2010 16:16:03 EDT from dothebart @ Uncensored Subject: Re: Setting up a build environment to work with the source release me personaly symlinks the static/ directory from the target directory (/usr/share/citadel-webcit/static on my debian) over. note that if webcit isn't ran with -T it will cache templates, so add -T1 while editing testing templates. Note that new files aren't recognized before restarting webcit in any case. for compiling have a look at... http://www.citadel.org/doku.php/installation:easyinstall:easyinstall:homebrew Great, thanks! I had found most of those pages, but the key one (compiling against Easy Install) never appeared on my radar because I thought Easy Install is the last thing I'd use in this situation :) I'm very happy that it's mostly just a few LDFLAGS and a bunch of symlinks. I'll get hacking this weekend.
[Citadel Development] Re: Commit log to refs/heads/master
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.
[Citadel Development] Re: Commit log to refs/heads/master
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.
[Citadel Development] Re: Git?
Fr Aug 27 2010 14:58:06 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Git? 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? In git you also have a 'central official repository' its just that its a convention making it the 'central official repository' not the featureset it offers to the client/user. Every working copy or other git server can offer the same (or maybe a bit more of some experimental functions) so you can work committed with a higher commit resolution than the resolution of what you put upstream (and bother the other devs with) which is quiet nice in conjunktion with blame annotation, since the commit comment closer describes that edit Git also has the ability to 'pull' other repos which is good for somebody developing without having commit access to the 'central repository', since he can also commit in sensfull stepps and git will offer the same abilities features to him (plus the git more ;-) as somebody with svn write access has. The documentation is for shure written from a kernel developers point of view, since thats the origin of git ;-) While SVN creates a Monarchy, GIT is a democracy, each with equal rights and features. but as also pointed out in my last post, it offers more superior ways of working with a repository.
[Citadel Development] Re: Unusual SSL behavior, likely bug
hm, ok, i'd say its the line between header and body which is breaking our neck here. could you please reassure, that the last line of those messages being written to citserver is the last line of the email-header? for example .4 X-Evolution-Source: imap://some...@somewhereplace.com/ or in .3: Content-Transfer-Encoding: 7bit
[Citadel Development] Re: Unusual SSL behavior, likely bug
Sorry about the delay in getting these logs... Had my workstation decide to melt down (or at least the CPU, literally... thankfully Intel has a 3 year warranty...) Logs are attached. At the end of foolog_IMAPS.3 and foolog_IMAPS.4 it appears that we might (and I stress might, because I have no idea and haven't looked at the code) be catching a buffer underrun when SSL is enabled. I used mailing list traffic from full disclosure as the source messages to populate the development system, henceforth the strange headers or titles in some of the messages. - Stu Wed Aug 18 2010 02:05:28 AM EDT from dothebart @ Uncensored Subject: Re: Unusual SSL behavior, likely bug if you compile citadel with '-D BIGBAD_IODBG' as one of your CFLAGS, it will write a transscript of what its doing on al IO chanels to /tmp/modulename_fd_random this could give us a chance to catch your incident. do you have some test system where you could try that out? (on a production system /tmp/ would run full verry quick) citadel_ssl_debug_logs_1.tar.gz Description: GNU Zip compressed data
[Citadel Development] Re: Git?
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.
[Citadel Development] Re: Git?
Mon Aug 30 2010 1:58:38 pm EDT EDT from IGnatius T Foobar @ Uncensored Subject: Re: Git? 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. thank-you thank-you thank-you Sam
[Citadel Development] Re:
Sat Aug 28 2010 10:06:18 am EDT EDT from dothebart @ Uncensored 15:10 CIA-37: citadel: dothebart * r8892 citadel/ (13 files in 8 dirs): * do typedef the visit struct, remove all those 'struct' statements from all over the source15:11 CIA-37: citadel: dothebart * r8893 citadel/user_ops.c: * fix GTSN not to cut seen stats at 1024 chars (somehow no svn commit mail?) sam, could you please try whether that fixes your troubles? Sure (as soon as git comes online). Thanks for looking at that for me. Sam
[Citadel Development] Re: Unusual SSL behavior, likely bug
ok, since our SVN is unavailable, and our Git is still maturizing, this is the fix for our imaps-blob-uploading issue.
So Aug 29 2010 18:32:54 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
So Aug 29 2010 17:19:14 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
hm, ok, i'd say its the line between header and body which is breaking our neck here.
could you please reassure, that the last line of those messages being written to citserver is the last line of the email-header?
for example .4
X-Evolution-Source: imap://some...@somewhereplace.com/
or in .3:
Content-Transfer-Encoding: 7bit
ok, forget about it. its the ssl-blob-reader; need to have a closer look at it tomorow.
/* $Id$
*
* Copyright (c) 1987-2009 by the citadel.org team
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include string.h
#include unistd.h
#include sys/stat.h
#include sys/types.h
#include sysdep.h
#ifdef HAVE_OPENSSL
#include openssl/ssl.h
#include openssl/err.h
#include openssl/rand.h
#endif
#if TIME_WITH_SYS_TIME
# include sys/time.h
# include time.h
#else
# if HAVE_SYS_TIME_H
# include sys/time.h
# else
# include time.h
# endif
#endif
#ifdef HAVE_PTHREAD_H
#include pthread.h
#endif
#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
#endif
#include stdio.h
#include libcitadel.h
#include server.h
#include serv_crypto.h
#include sysdep_decls.h
#include citadel.h
#include config.h
#include ctdl_module.h
/* TODO: should we use the standard module init stuff to start this? */
/* TODO: should we register an event handler to call destruct_ssl? */
#ifdef HAVE_OPENSSL
SSL_CTX *ssl_ctx; /* SSL context */
pthread_mutex_t **SSLCritters; /* Things needing locking */
static unsigned long id_callback(void)
{
return (unsigned long) pthread_self();
}
void destruct_ssl(void)
{
int a;
for (a = 0; a CRYPTO_num_locks(); a++)
free(SSLCritters[a]);
free (SSLCritters);
}
void init_ssl(void)
{
SSL_METHOD *ssl_method;
DH *dh;
RSA *rsa=NULL;
X509_REQ *req = NULL;
X509 *cer = NULL;
EVP_PKEY *pk = NULL;
EVP_PKEY *req_pkey = NULL;
X509_NAME *name = NULL;
FILE *fp;
if (!access(EGD_POOL, F_OK))
RAND_egd(EGD_POOL);
if (!RAND_status()) {
CtdlLogPrintf(CTDL_CRIT,
PRNG not adequately seeded, won't do SSL/TLS\n);
return;
}
SSLCritters =
malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t *));
if (!SSLCritters) {
CtdlLogPrintf(CTDL_EMERG, citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
} else {
int a;
for (a = 0; a CRYPTO_num_locks(); a++) {
SSLCritters[a] = malloc(sizeof(pthread_mutex_t));
if (!SSLCritters[a]) {
CtdlLogPrintf(CTDL_EMERG,
citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
}
pthread_mutex_init(SSLCritters[a], NULL);
}
}
/*
* Initialize SSL transport layer
*/
SSL_library_init();
SSL_load_error_strings();
ssl_method = SSLv23_server_method();
if (!(ssl_ctx = SSL_CTX_new(ssl_method))) {
CtdlLogPrintf(CTDL_CRIT, SSL_CTX_new failed: %s\n,
ERR_reason_error_string(ERR_get_error()));
return;
}
if (!(SSL_CTX_set_cipher_list(ssl_ctx, CIT_CIPHERS))) {
CtdlLogPrintf(CTDL_CRIT, SSL: No ciphers available\n);
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
#if 0
#if SSLEAY_VERSION_NUMBER = 0x00906000L
SSL_CTX_set_mode(ssl_ctx, SSL_CTX_get_mode(ssl_ctx) |
SSL_MODE_AUTO_RETRY);
#endif
#endif
CRYPTO_set_locking_callback(ssl_lock);
CRYPTO_set_id_callback(id_callback);
/* Load DH parameters into the context */
dh = DH_new();
if (!dh) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't allocate a DH object: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
if (!(BN_hex2bn((dh-p), DH_P))) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't assign DH_P: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
if (!(BN_hex2bn((dh-g), DH_G))) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't assign DH_G: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
dh-length = DH_L;
SSL_CTX_set_tmp_dh(ssl_ctx, dh);
DH_free(dh);
/* Get our certificates in order.
* First,
[Citadel Development] Re:
Sat Aug 28 2010 10:06:18 am EDT EDT from dothebart @ Uncensored 15:10 CIA-37: citadel: dothebart * r8892 citadel/ (13 files in 8 dirs): * do typedef the visit struct, remove all those 'struct' statements from all over the source15:11 CIA-37: citadel: dothebart * r8893 citadel/user_ops.c: * fix GTSN not to cut seen stats at 1024 chars (somehow no svn commit mail?) sam, could you please try whether that fixes your troubles? That's great! Absolutely great! I can now use webcit to view mailboxes with thousands of messages. Also, lately I've notice everything much faster! I don't know if my vhoster has moved me to better hardware or if citadel has just got lots better. Sam
[Citadel Development] Re: Unusual SSL behavior, likely bug
Scanios, can you re-test with current git trunk?
TIA.
Mo Aug 30 2010 17:34:25 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
ok, since our SVN is unavailable, and our Git is still maturizing, this is the fix for our imaps-blob-uploading issue.
So Aug 29 2010 18:32:54 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
So Aug 29 2010 17:19:14 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
hm, ok, i'd say its the line between header and body which is breaking our neck here.
could you please reassure, that the last line of those messages being written to citserver is the last line of the email-header?
for example .4
X-Evolution-Source: imap://some...@somewhereplace.com/
or in .3:
Content-Transfer-Encoding: 7bit
ok, forget about it. its the ssl-blob-reader; need to have a closer look at it tomorow.
/* $Id$
*
* Copyright (c) 1987-2009 by the citadel.org team
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include string.h
#include unistd.h
#include sys/stat.h
#include sys/types.h
#include sysdep.h
#ifdef HAVE_OPENSSL
#include openssl/ssl.h
#include openssl/err.h
#include openssl/rand.h
#endif
#if TIME_WITH_SYS_TIME
# include sys/time.h
# include time.h
#else
# if HAVE_SYS_TIME_H
# include sys/time.h
# else
# include time.h
# endif
#endif
#ifdef HAVE_PTHREAD_H
#include pthread.h
#endif
#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
#endif
#include stdio.h
#include libcitadel.h
#include server.h
#include serv_crypto.h
#include sysdep_decls.h
#include citadel.h
#include config.h
#include ctdl_module.h
/* TODO: should we use the standard module init stuff to start this? */
/* TODO: should we register an event handler to call destruct_ssl? */
#ifdef HAVE_OPENSSL
SSL_CTX *ssl_ctx; /* SSL context */
pthread_mutex_t **SSLCritters; /* Things needing locking */
static unsigned long id_callback(void)
{
return (unsigned long) pthread_self();
}
void destruct_ssl(void)
{
int a;
for (a = 0; a CRYPTO_num_locks(); a++)
free(SSLCritters[a]);
free (SSLCritters);
}
void init_ssl(void)
{
SSL_METHOD *ssl_method;
DH *dh;
RSA *rsa=NULL;
X509_REQ *req = NULL;
X509 *cer = NULL;
EVP_PKEY *pk = NULL;
EVP_PKEY *req_pkey = NULL;
X509_NAME *name = NULL;
FILE *fp;
if (!access(EGD_POOL, F_OK))
RAND_egd(EGD_POOL);
if (!RAND_status()) {
CtdlLogPrintf(CTDL_CRIT,
PRNG not adequately seeded, won't do SSL/TLS\n);
return;
}
SSLCritters =
malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t *));
if (!SSLCritters) {
CtdlLogPrintf(CTDL_EMERG, citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
} else {
int a;
for (a = 0; a CRYPTO_num_locks(); a++) {
SSLCritters[a] = malloc(sizeof(pthread_mutex_t));
if (!SSLCritters[a]) {
CtdlLogPrintf(CTDL_EMERG,
citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
}
pthread_mutex_init(SSLCritters[a], NULL);
}
}
/*
* Initialize SSL transport layer
*/
SSL_library_init();
SSL_load_error_strings();
ssl_method = SSLv23_server_method();
if (!(ssl_ctx = SSL_CTX_new(ssl_method))) {
CtdlLogPrintf(CTDL_CRIT, SSL_CTX_new failed: %s\n,
ERR_reason_error_string(ERR_get_error()));
return;
}
if (!(SSL_CTX_set_cipher_list(ssl_ctx, CIT_CIPHERS))) {
CtdlLogPrintf(CTDL_CRIT, SSL: No ciphers available\n);
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
#if 0
#if SSLEAY_VERSION_NUMBER = 0x00906000L
SSL_CTX_set_mode(ssl_ctx, SSL_CTX_get_mode(ssl_ctx) |
SSL_MODE_AUTO_RETRY);
#endif
#endif
CRYPTO_set_locking_callback(ssl_lock);
CRYPTO_set_id_callback(id_callback);
/* Load DH parameters into the context */
dh = DH_new();
if (!dh) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't allocate a DH object: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
if (!(BN_hex2bn((dh-p), DH_P))) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't assign DH_P: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
if (!(BN_hex2bn((dh-g), DH_G))) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't assign DH_G: %s\n,
ERR_reason_error_string(ERR_get_error()));
[Citadel Development] Re: macro strncmp requires 3 arguments, but only 2 given
Wed Sep 01 2010 6:14:03 am EDT EDT from samjam @ Uncensored Subject: Re: macro "strncmp" requires 3 arguments, but only 2 given
Wed Sep 01 2010 6:06:48 am EDT EDT from dothebart @ Uncensored Subject: Re: macro "strncmp" requires 3 arguments, but only 2 given
HKEY is a macro that does
a, sizeof(a) - 1
so it actualy has 3 parameters. Maybe for some reason that macro isn't visible to your compiler there?
that strncmp actualy wants to check for the first two chars.
To be clear to my other reply, on my system strcmp and strncmp are macros and so HKEY won't work to return more than one parameter
You can do the HKEY trick on vararg macros:
cat END x.c
#define strncmp(a,b,c) [a][b][c]#define _strncmp(...) strcmp(__VA_ARGS__)#define HKEY(a) a, (sizeof(a)-1)_strncmp("something", HKEY("__"));x.c
gcc -E x.c
# 1 "x.c"# 1 "built-in"# 1 "command-line"# 1 "x.c"["something"]["__"][(sizeof("__")-1)];
But on my system strncmp isn't a vararg macro.
[Citadel Development] Re: Unusual SSL behavior, likely bug
Wed Sep 01 2010 5:39:34 am EDT EDT from dothebart @ Uncensored Subject: Re: Unusual SSL behavior, likely bug
Scanios, can you re-test with current git trunk?
TIA.
Mo Aug 30 2010 17:34:25 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
ok, since our SVN is unavailable, and our Git is still maturizing, this is the fix for our imaps-blob-uploading issue.
So Aug 29 2010 18:32:54 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
So Aug 29 2010 17:19:14 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug
hm, ok, i'd say its the line between header and body which is breaking our neck here.
could you please reassure, that the last line of those messages being written to citserver is the last line of the email-header?
for example .4
X-Evolution-Source: imap://some...@somewhereplace.com/
or in .3:
Content-Transfer-Encoding: 7bit
ok, forget about it. its the ssl-blob-reader; need to have a closer look at it tomorow.
I am now (for the first time in a while) able to save messages to drafts without an error message - thanks
Sam
/* $Id$
*
* Copyright (c) 1987-2009 by the citadel.org team
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include string.h
#include unistd.h
#include sys/stat.h
#include sys/types.h
#include sysdep.h
#ifdef HAVE_OPENSSL
#include openssl/ssl.h
#include openssl/err.h
#include openssl/rand.h
#endif
#if TIME_WITH_SYS_TIME
# include sys/time.h
# include time.h
#else
# if HAVE_SYS_TIME_H
# include sys/time.h
# else
# include time.h
# endif
#endif
#ifdef HAVE_PTHREAD_H
#include pthread.h
#endif
#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
#endif
#include stdio.h
#include libcitadel.h
#include server.h
#include serv_crypto.h
#include sysdep_decls.h
#include citadel.h
#include config.h
#include ctdl_module.h
/* TODO: should we use the standard module init stuff to start this? */
/* TODO: should we register an event handler to call destruct_ssl? */
#ifdef HAVE_OPENSSL
SSL_CTX *ssl_ctx; /* SSL context */
pthread_mutex_t **SSLCritters; /* Things needing locking */
static unsigned long id_callback(void)
{
return (unsigned long) pthread_self();
}
void destruct_ssl(void)
{
int a;
for (a = 0; a CRYPTO_num_locks(); a++)
free(SSLCritters[a]);
free (SSLCritters);
}
void init_ssl(void)
{
SSL_METHOD *ssl_method;
DH *dh;
RSA *rsa=NULL;
X509_REQ *req = NULL;
X509 *cer = NULL;
EVP_PKEY *pk = NULL;
EVP_PKEY *req_pkey = NULL;
X509_NAME *name = NULL;
FILE *fp;
if (!access(EGD_POOL, F_OK))
RAND_egd(EGD_POOL);
if (!RAND_status()) {
CtdlLogPrintf(CTDL_CRIT,
PRNG not adequately seeded, won't do SSL/TLS\n);
return;
}
SSLCritters =
malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t *));
if (!SSLCritters) {
CtdlLogPrintf(CTDL_EMERG, citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
} else {
int a;
for (a = 0; a CRYPTO_num_locks(); a++) {
SSLCritters[a] = malloc(sizeof(pthread_mutex_t));
if (!SSLCritters[a]) {
CtdlLogPrintf(CTDL_EMERG,
citserver: can't allocate memory!!\n);
/* Nothing's been initialized, just die */
exit(1);
}
pthread_mutex_init(SSLCritters[a], NULL);
}
}
/*
* Initialize SSL transport layer
*/
SSL_library_init();
SSL_load_error_strings();
ssl_method = SSLv23_server_method();
if (!(ssl_ctx = SSL_CTX_new(ssl_method))) {
CtdlLogPrintf(CTDL_CRIT, SSL_CTX_new failed: %s\n,
ERR_reason_error_string(ERR_get_error()));
return;
}
if (!(SSL_CTX_set_cipher_list(ssl_ctx, CIT_CIPHERS))) {
CtdlLogPrintf(CTDL_CRIT, SSL: No ciphers available\n);
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
#if 0
#if SSLEAY_VERSION_NUMBER = 0x00906000L
SSL_CTX_set_mode(ssl_ctx, SSL_CTX_get_mode(ssl_ctx) |
SSL_MODE_AUTO_RETRY);
#endif
#endif
CRYPTO_set_locking_callback(ssl_lock);
CRYPTO_set_id_callback(id_callback);
/* Load DH parameters into the context */
dh = DH_new();
if (!dh) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't allocate a DH object: %s\n,
ERR_reason_error_string(ERR_get_error()));
SSL_CTX_free(ssl_ctx);
ssl_ctx = NULL;
return;
}
if (!(BN_hex2bn((dh-p), DH_P))) {
CtdlLogPrintf(CTDL_CRIT, init_ssl() can't assign DH_P: %s\n,
[Citadel Development] Re: Unusual SSL behavior, likely bug
So Aug 29 2010 17:19:14 EDT von dothebart @ Uncensored Betreff: Re: Unusual SSL behavior, likely bug hm, ok, i'd say its the line between header and body which is breaking our neck here. could you please reassure, that the last line of those messages being written to citserver is the last line of the email-header? for example .4 X-Evolution-Source: imap://some...@somewhereplace.com/ or in .3: Content-Transfer-Encoding: 7bit ok, forget about it. its the ssl-blob-reader; need to have a closer look at it tomorow.
[Citadel Development] Re:
That's great! Absolutely great! I can now use webcit to view mailboxes with thousands of messages. Also, lately I've notice everything much faster! I don't know if my vhoster has moved me to better hardware or if citadel has just got lots better. I can confirm that it is in fact much, much faster on IMAP operations. I operate all of my own servers and I've seen speed increases in the 30%-50% range (subjective) and a lower CPU load. - Stu
[Citadel Development] Re:
Mi Sep 01 2010 05:34:55 EDT von samjam @ Uncensored Betreff: Re: Sat Aug 28 2010 10:06:18 am EDT EDT from dothebart @ Uncensored 15:10 CIA-37: citadel: dothebart * r8892 citadel/ (13 files in 8 dirs): * do typedef the visit struct, remove all those 'struct' statements from all over the source15:11 CIA-37: citadel: dothebart * r8893 citadel/user_ops.c: * fix GTSN not to cut seen stats at 1024 chars (somehow no svn commit mail?) sam, could you please try whether that fixes your troubles? That's great! Absolutely great! I can now use webcit to view mailboxes with thousands of messages. Also, lately I've notice everything much faster! I don't know if my vhoster has moved me to better hardware or if citadel has just got lots better. Sam well, i've done another bunch of profiling to citserver. Glad somebody notices ;-)
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
Ignore that patch; I have one that fixes all 3 projects - otherwise they fail to build properly with symlink loops and the like
[Citadel Development] Re: What happened to c_port_number?
Sat Sep 04 2010 8:54:39 am EDT EDT from samjam @ Uncensored Subject: Re: What happened to c_port_number? Nope, still broken - re-installing the (new) debs, breaks it again and knocks the config back again setup -q is the culprit, after "setup" my ip address is 0.0.0.0, after setup -q is has gone again
[Citadel Development] Re: Commit log to refs/heads/master
So Sep 05 2010 14:32:59 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: 348c6acf5f481614e88c74cc19e9a04083ff92f0 citadel/euidindex.c citadel/user_ops.c webcit/static/t/edit_message.html webcit/static/t/view_message.html branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs re-enable drafts as proposed by samjam IG, I think there are some newlines missing here? is there a cheap way to add them? I'd probably prefer to have it like that: Files: (#348c6acf5f481614e88c74cc19e9a04083ff92f0) citadel/euidindex.c citadel/user_ops.c webcit/static/t/edit_message.html webcit/static/t/view_message.html branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs re-enable drafts as proposed by samjam.
[Citadel Development] Re: Fw: [PATCH] Re-enable drafts
afair IG disabled it because of it was getting late to get a 7.60 release out; maybe the history of this room of that time shows a more detailed reason. I think some of the concepts weren't all clean yet; probably when that 'save to drafts' button should be shown and when not; or, what to do with a draft if it was for example targeted to a public room (a forum in advance) how' d you continue posting that message into that room (and not just send it out as an email) ?
I think we should discuss these (and other questions) and find a solution to it.
Sa Sep 04 2010 11:19:09 EDT von samjam @ Uncensored Betreff: Fw: [PATCH] Re-enable drafts
This patch applies to HEAD and re-enables draft folders.
I'm using it at home - seems to work - what was wrong with it that it was disabled?
Sam
--- forwarded message ---
Sat Sep 04 2010 4:06:51 am EDT EDT from "Sam Liddicott" sam...@uncensored.citadel.org Subject: [PATCH] Re-enable drafts
--- citadel/euidindex.c |1 + citadel/user_ops.c|2 +- libcitadel/lib/libcitadel.h |1 + webcit/static/t/edit_message.html |2 -- webcit/static/t/view_message.html |2 -- 5 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/citadel/euidindex.c b/citadel/euidindex.c
index 842fa1d..8ca39ee 100644
--- a/citadel/euidindex.c
+++ b/citadel/euidindex.c
@@ -69,6 +69,7 @@ int DoesThisRoomNeedEuidIndexing(struct ctdlroom *qrbuf) {
case VIEW_BBS: return(0);
case VIEW_MAILBOX: return(0);
case VIEW_ADDRESSBOOK: return(1);
+ case VIEW_DRAFTS: return(0);
case VIEW_CALENDAR: return(1);
case VIEW_TASKS: return(1);
case VIEW_NOTES: return(1);
diff --git a/citadel/user_ops.c b/citadel/user_ops.c
index 2f23c38..d68d334 100644
--- a/citadel/user_ops.c
+++ b/citadel/user_ops.c
@@ -739,7 +739,7 @@ void do_login(void)
CtdlCreateRoom(MAILROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(SENTITEMS, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(USERTRASHROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
- /* CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX); temporarily disabled for 7.60 */
+ CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
/* Run any startup routines registered by loadable modules */
PerformSessionHooks(EVT_LOGIN);
diff --git a/libcitadel/lib/libcitadel.h b/libcitadel/lib/libcitadel.h
index 69781b6..82c0ec6 100644
--- a/libcitadel/lib/libcitadel.h
+++ b/libcitadel/lib/libcitadel.h
@@ -103,6 +103,7 @@ typedef enum _room_views {
VIEW_CALBRIEF = 7, /* Brief Calendar view */
VIEW_JOURNAL = 8, /* Journal view */
VIEW_BLOG = 9, /* Blog view */
+ VIEW_DRAFTS = 10, /* Drafts view */
VIEW_MAX
} ROOM_VIEWS;
diff --git a/webcit/static/t/edit_message.html b/webcit/static/t/edit_message.html
index 600dd67..7febb91 100644
--- a/webcit/static/t/edit_message.html
+++ b/webcit/static/t/edit_message.html
@@ -14,10 +14,8 @@
?!(COND:BSTR, 1, __RCPTREQUIRED)input type=submit name=send_button value=?_(Send message)?!(X, 1)
??(COND:BSTR, 2, __RCPTREQUIRED)input type=submit name=send_button value=?_(Post message)?!(X, 2)
nbsp;
-!-- temporarily disabled for 7.60
input type=submit name=save_button value=?_(Save to Drafts)
nbsp;
---
input type=submit name=cancel_button value=?_(Cancel)
/p
img src=static/newmess3_24x.gif class=imgedit ?DATE:NOW:STR
diff --git a/webcit/static/t/view_message.html b/webcit/static/t/view_message.html
index aa2150e..941f98b 100644
--- a/webcit/static/t/view_message.html
+++ b/webcit/static/t/view_message.html
@@ -16,9 +16,7 @@ onMouseOut=document.getElementById(msg?MAIL:SUMM:N).style.visibility=hidden
?!(COND:MAIL:SUMM:, 6)?_(CC:)?MAIL:SUMM:(X)??(X, 6)
?!(COND:MAIL:SUBJ, 7)p class=message_subject?_(Subject:) ?MAIL:SUMM:SUBJECT(X)/p??(X, 7)
p style=visibility: hidden; id=msg?MAIL:SUMM:N class=msgbuttons
-!-- temporarily disabled for 7.60
a href=display_enter?edit=?MAIL:SUMM:Nrecp=?MAIL:SUMM:TO(U)cc=?MAIL:SUMM:(U)subject=?MAIL:SUMM:SUBJECT(U, 0, , )force_room=_MAIL_span[/span?_(Edit)span]/span/a
---
?!(COND:ROOM:TYPE_IS, 8, #VIEW_BBS)
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(Reply)span]/span/a
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?replyquote=?MAIL:SUMM:Nrecp=%22?MAIL:SUMM:FROM(U)%22%3C?MAIL:SUMM:RFCA(U)%3E?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(ReplyQuoted)span]/span/a
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
Mon Sep 06 2010 5:11:39 am EDT EDT from samjam @ Uncensored Subject: Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files Sun Sep 05 2010 2:24:33 pm EDT EDT from dothebart @ Uncensored Subject: Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files hm, did you run that script in advance? since its not clever to rename subdirectories (citadel/ to citadel-7.83) in a git workingcopy (and symlink citadel/ to it), I instead made it create the symlink to the citadel directory. If you already have it the other way arround, it won't work for you then ;-) Not at all. Originally I did what you did, but it's not enough - ./buildpackage debian src doesn't work and ./buildpackage src produces different paths to originally (because tar follows the symlink before tar-ing). With just your patch, clean "/.buildpackage debain" were failing and symlinks-to-self of citadel was created in the citadel folder and of libcitadel in the libcitadel folder which made builds fail. Sam As ti turns out, that patch isn't very good. I've been having problems with stgit missing chunks or whole changesets. I'm just rebasing master (and confirmed the symlink loop) and will re-do the patch and post shortly. Sam
[Citadel Development] Re: Fw: [PATCH] Re-enable drafts
Sun Sep 05 2010 2:44:51 pm EDT EDT from dothebart @ Uncensored Subject: Re: Fw: [PATCH] Re-enable drafts
afair IG disabled it because of it was getting late to get a 7.60 release out; maybe the history of this room of that time shows a more detailed reason. I think some of the concepts weren't all clean yet; probably when that 'save to drafts' button should be shown and when not; or, what to do with a draft if it was for example targeted to a public room (a forum in advance) how' d you continue posting that message into that room (and not just send it out as an email) ?
I think we should discuss these (and other questions) and find a solution to it.
Originally, the room was saved as an extra message header so the draft could be picked-up back to the same room.
I'll check it all over and post back.
Sam
diff --git a/citadel/euidindex.c b/citadel/euidindex.c
index 842fa1d..8ca39ee 100644
--- a/citadel/euidindex.c
+++ b/citadel/euidindex.c
@@ -69,6 +69,7 @@ int DoesThisRoomNeedEuidIndexing(struct ctdlroom *qrbuf) {
case VIEW_BBS: return(0);
case VIEW_MAILBOX: return(0);
case VIEW_ADDRESSBOOK: return(1);
+ case VIEW_DRAFTS: return(0);
case VIEW_CALENDAR: return(1);
case VIEW_TASKS: return(1);
case VIEW_NOTES: return(1);
diff --git a/citadel/user_ops.c b/citadel/user_ops.c
index 2f23c38..d68d334 100644
--- a/citadel/user_ops.c
+++ b/citadel/user_ops.c
@@ -739,7 +739,7 @@ void do_login(void)
CtdlCreateRoom(MAILROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(SENTITEMS, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(USERTRASHROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
- /* CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX); temporarily disabled for 7.60 */
+ CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
/* Run any startup routines registered by loadable modules */
PerformSessionHooks(EVT_LOGIN);
diff --git a/libcitadel/lib/libcitadel.h b/libcitadel/lib/libcitadel.h
index 69781b6..82c0ec6 100644
--- a/libcitadel/lib/libcitadel.h
+++ b/libcitadel/lib/libcitadel.h
@@ -103,6 +103,7 @@ typedef enum _room_views {
VIEW_CALBRIEF = 7, /* Brief Calendar view */
VIEW_JOURNAL = 8, /* Journal view */
VIEW_BLOG = 9, /* Blog view */
+ VIEW_DRAFTS = 10, /* Drafts view */
VIEW_MAX
} ROOM_VIEWS;
diff --git a/webcit/static/t/edit_message.html b/webcit/static/t/edit_message.html
index 600dd67..7febb91 100644
--- a/webcit/static/t/edit_message.html
+++ b/webcit/static/t/edit_message.html
@@ -14,10 +14,8 @@
?!(COND:BSTR, 1, __RCPTREQUIRED)input type=submit name=send_button value=?_(Send message)?!(X, 1)
??(COND:BSTR, 2, __RCPTREQUIRED)input type=submit name=send_button value=?_(Post message)?!(X, 2)
nbsp;
-!-- temporarily disabled for 7.60
input type=submit name=save_button value=?_(Save to Drafts)
nbsp;
---
input type=submit name=cancel_button value=?_(Cancel)
/p
img src=static/newmess3_24x.gif class=imgedit ?DATE:NOW:STR
diff --git a/webcit/static/t/view_message.html b/webcit/static/t/view_message.html
index aa2150e..941f98b 100644
--- a/webcit/static/t/view_message.html
+++ b/webcit/static/t/view_message.html
@@ -16,9 +16,7 @@ onMouseOut=document.getElementById(msg?MAIL:SUMM:N).style.visibility=hidden
?!(COND:MAIL:SUMM:, 6)?_(CC:)?MAIL:SUMM:(X)??(X, 6)
?!(COND:MAIL:SUBJ, 7)p class=message_subject?_(Subject:) ?MAIL:SUMM:SUBJECT(X)/p??(X, 7)
p style=visibility: hidden; id=msg?MAIL:SUMM:N class=msgbuttons
-!-- temporarily disabled for 7.60
a href=display_enter?edit=?MAIL:SUMM:Nrecp=?MAIL:SUMM:TO(U)cc=?MAIL:SUMM:(U)subject=?MAIL:SUMM:SUBJECT(U, 0, , )force_room=_MAIL_span[/span?_(Edit)span]/span/a
---
?!(COND:ROOM:TYPE_IS, 8, #VIEW_BBS)
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(Reply)span]/span/a
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?replyquote=?MAIL:SUMM:Nrecp=%22?MAIL:SUMM:FROM(U)%22%3C?MAIL:SUMM:RFCA(U)%3E?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(ReplyQuoted)span]/span/a
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
The symlink loop occurs when this line is executed: ln -sf libcitadel libcitadel-7.83cd libcitadel-7.83 if libcitadel-7.83 is already a symlink pointing to libcitadel - so the symlink get's made inside libcitadel. The -f option doesn't have the desired effect if the pre-existing symlink target is a directory. Patch to follow. It would help sending git-patches if drafts-mode patch could be enabled on uncensored; git-imap-send dumps the diff and message in my drafts folder ready for me to pick-up.
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
Mon Sep 06 2010 7:12:03 am EDT EDT from samjam @ Uncensored Subject: Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files The symlink loop occurs when this line is executed: ln -sf libcitadel libcitadel-7.83cd libcitadel-7.83 if libcitadel-7.83 is already a symlink pointing to libcitadel - so the symlink get's made inside libcitadel. The -f option doesn't have the desired effect if the pre-existing symlink target is a directory. Patch to follow. It would help sending git-patches if drafts-mode patch could be enabled on uncensored; git-imap-send dumps the diff and message in my drafts folder ready for me to pick-up. Although I found the un-quote button works nice. (Why doesn't the un-quote button appear for normal builds, but shows up on uncensored?)
[Citadel Development] Re: Fw: [PATCH] Re-enable drafts
Sun Sep 05 2010 2:44:51 pm EDT EDT from dothebart @ Uncensored Subject: Re: Fw: [PATCH] Re-enable drafts
afair IG disabled it because of it was getting late to get a 7.60 release out; maybe the history of this room of that time shows a more detailed reason. I think some of the concepts weren't all clean yet; probably when that 'save to drafts' button should be shown and when not; or, what to do with a draft if it was for example targeted to a public room (a forum in advance) how' d you continue posting that message into that room (and not just send it out as an email) ?
I think we should discuss these (and other questions) and find a solution to it.
Yep; I see that save-to-drafs from a room now complains at lack of recipients. I'll look back to my original patches in my old git-svn tree where recipients weren't required to save-to-drafts and it remembered the active room as an SMTP header.
Sam
diff --git a/citadel/euidindex.c b/citadel/euidindex.c
index 842fa1d..8ca39ee 100644
--- a/citadel/euidindex.c
+++ b/citadel/euidindex.c
@@ -69,6 +69,7 @@ int DoesThisRoomNeedEuidIndexing(struct ctdlroom *qrbuf) {
case VIEW_BBS: return(0);
case VIEW_MAILBOX: return(0);
case VIEW_ADDRESSBOOK: return(1);
+ case VIEW_DRAFTS: return(0);
case VIEW_CALENDAR: return(1);
case VIEW_TASKS: return(1);
case VIEW_NOTES: return(1);
diff --git a/citadel/user_ops.c b/citadel/user_ops.c
index 2f23c38..d68d334 100644
--- a/citadel/user_ops.c
+++ b/citadel/user_ops.c
@@ -739,7 +739,7 @@ void do_login(void)
CtdlCreateRoom(MAILROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(SENTITEMS, 4, , 0, 1, 0, VIEW_MAILBOX);
CtdlCreateRoom(USERTRASHROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
- /* CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX); temporarily disabled for 7.60 */
+ CtdlCreateRoom(USERDRAFTROOM, 4, , 0, 1, 0, VIEW_MAILBOX);
/* Run any startup routines registered by loadable modules */
PerformSessionHooks(EVT_LOGIN);
diff --git a/libcitadel/lib/libcitadel.h b/libcitadel/lib/libcitadel.h
index 69781b6..82c0ec6 100644
--- a/libcitadel/lib/libcitadel.h
+++ b/libcitadel/lib/libcitadel.h
@@ -103,6 +103,7 @@ typedef enum _room_views {
VIEW_CALBRIEF = 7, /* Brief Calendar view */
VIEW_JOURNAL = 8, /* Journal view */
VIEW_BLOG = 9, /* Blog view */
+ VIEW_DRAFTS = 10, /* Drafts view */
VIEW_MAX
} ROOM_VIEWS;
diff --git a/webcit/static/t/edit_message.html b/webcit/static/t/edit_message.html
index 600dd67..7febb91 100644
--- a/webcit/static/t/edit_message.html
+++ b/webcit/static/t/edit_message.html
@@ -14,10 +14,8 @@
?!(COND:BSTR, 1, __RCPTREQUIRED)input type=submit name=send_button value=?_(Send message)?!(X, 1)
??(COND:BSTR, 2, __RCPTREQUIRED)input type=submit name=send_button value=?_(Post message)?!(X, 2)
nbsp;
-!-- temporarily disabled for 7.60
input type=submit name=save_button value=?_(Save to Drafts)
nbsp;
---
input type=submit name=cancel_button value=?_(Cancel)
/p
img src=static/newmess3_24x.gif class=imgedit ?DATE:NOW:STR
diff --git a/webcit/static/t/view_message.html b/webcit/static/t/view_message.html
index aa2150e..941f98b 100644
--- a/webcit/static/t/view_message.html
+++ b/webcit/static/t/view_message.html
@@ -16,9 +16,7 @@ onMouseOut=document.getElementById(msg?MAIL:SUMM:N).style.visibility=hidden
?!(COND:MAIL:SUMM:, 6)?_(CC:)?MAIL:SUMM:(X)??(X, 6)
?!(COND:MAIL:SUBJ, 7)p class=message_subject?_(Subject:) ?MAIL:SUMM:SUBJECT(X)/p??(X, 7)
p style=visibility: hidden; id=msg?MAIL:SUMM:N class=msgbuttons
-!-- temporarily disabled for 7.60
a href=display_enter?edit=?MAIL:SUMM:Nrecp=?MAIL:SUMM:TO(U)cc=?MAIL:SUMM:(U)subject=?MAIL:SUMM:SUBJECT(U, 0, , )force_room=_MAIL_span[/span?_(Edit)span]/span/a
---
?!(COND:ROOM:TYPE_IS, 8, #VIEW_BBS)
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(Reply)span]/span/a
a href=display_enter?references=?MAIL:SUMM:REFIDS(U)%7C?MAIL:SUMM:INREPLYTO(U)?replyquote=?MAIL:SUMM:Nrecp=%22?MAIL:SUMM:FROM(U)%22%3C?MAIL:SUMM:RFCA(U)%3E?subject=?MAIL:SUMM:SUBJECT(U, 0, Re: , Re:)span[/span?_(ReplyQuoted)span]/span/a
[Citadel Development] Re:
Mon Sep 06 2010 11:11:50 am EDT EDT from IGnatius T Foobar @ Uncensored Ok folks, commit 8f713e8bba92ebb93a9a486d81ec7e966583fd9e in branch stable-78x is the official 7.84 release of all components. tarballs have been built and uploaded. Did you push? Sam
[Citadel Development] Re: [PATCH] Allow save-to-drafts without recipients
I there a way to automaticaly push such a commit mail?
Mo Sep 06 2010 08:06:28 EDT von samjam @ Uncensored Betreff: [PATCH] Allow save-to-drafts without recipients
Allow save-to-drafts without recipients
--- citadel/msgbase.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-)
Still need to read X-Citadel-Room when resuming from drafts
diff --git a/citadel/msgbase.c b/citadel/msgbase.c
index cd4fd5e..d7f832a 100644
--- a/citadel/msgbase.c
+++ b/citadel/msgbase.c
@@ -4033,12 +4033,13 @@ void cmd_ent0(char *entargs)
/* In mailbox rooms we have to behave a little differently --
* make sure the user has specified at least one recipient. Then
* validate the recipient(s). We do this for the Mail room, as
- * well as any room which has the Mailbox view set.
+ * well as any room which has the Mailbox view set - unless it
+ * is the DRAFTS room which does not require recipients
*/
- if ( ( (CC-room.QRflags QR_MAILBOX) (!strcasecmp(CC-room.QRname[11], MAILROOM)) )
- || ( (CC-room.QRflags QR_MAILBOX) (CC-curr_view == VIEW_MAILBOX) )
- ) {
+ if ( ( ( (CC-room.QRflags QR_MAILBOX) (!strcasecmp(CC-room.QRname[11], MAILROOM)) )
+ || ( (CC-room.QRflags QR_MAILBOX) (CC-curr_view == VIEW_MAILBOX) )
+ ) (strcasecmp(CC-room.QRname[11], USERDRAFTROOM)) !=0 ) {
if (CC-user.axlevel AxProbU) {
strcpy(recp, sysop);
strcpy(cc, );
[Citadel Development] Re: others messages
Yes I did, but it has not been implemented.
[Citadel Development] Re: [PATCH] Allow save-to-drafts without recipients
*gna* git-am doesn't speak imap.
now I need to set up some fetchmail to retrieve patches into a maildir? st00pit shit.
Mo Sep 06 2010 16:01:19 EDT von dothebart @ Uncensored Betreff: Re: [PATCH] Allow save-to-drafts without recipients
I there a way to automaticaly push such a commit mail?
Mo Sep 06 2010 08:06:28 EDT von samjam @ Uncensored Betreff: [PATCH] Allow save-to-drafts without recipients
Allow save-to-drafts without recipients
--- citadel/msgbase.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-)
Still need to read X-Citadel-Room when resuming from drafts
diff --git a/citadel/msgbase.c b/citadel/msgbase.c
index cd4fd5e..d7f832a 100644
--- a/citadel/msgbase.c
+++ b/citadel/msgbase.c
@@ -4033,12 +4033,13 @@ void cmd_ent0(char *entargs)
/* In mailbox rooms we have to behave a little differently --
* make sure the user has specified at least one recipient. Then
* validate the recipient(s). We do this for the Mail room, as
- * well as any room which has the Mailbox view set.
+ * well as any room which has the Mailbox view set - unless it
+ * is the DRAFTS room which does not require recipients
*/
- if ( ( (CC-room.QRflags QR_MAILBOX) (!strcasecmp(CC-room.QRname[11], MAILROOM)) )
- || ( (CC-room.QRflags QR_MAILBOX) (CC-curr_view == VIEW_MAILBOX) )
- ) {
+ if ( ( ( (CC-room.QRflags QR_MAILBOX) (!strcasecmp(CC-room.QRname[11], MAILROOM)) )
+ || ( (CC-room.QRflags QR_MAILBOX) (CC-curr_view == VIEW_MAILBOX) )
+ ) (strcasecmp(CC-room.QRname[11], USERDRAFTROOM)) !=0 ) {
if (CC-user.axlevel AxProbU) {
strcpy(recp, sysop);
strcpy(cc, );
[Citadel Development] Re: Commit log refs/heads/master
Sep 3 2010 10:23am from Art Cancro a...@citadel.org to room_citadel_development@uncensored.citadel.org Subject: Commit log refs/heads/master Files: b6938b71c266f458180103090af0ab72e3d9616c citadel/citadel.h citadel/include/dtds/user-defs.h citadel/textclient/citadel.c citadel/textclient/routines.c citadel/user_ops.c citadel/utillib/citadel_ipc.c Removed the USscreenwidth and USscreenheight fields. Everywhere. Since these were the last two fields in the ctdluser data stru cture, we are able to simply remove them instead of replacing them with placeholders. cmd_getu() now returns 80x24 all the time , and cmd_setu() now ignores the supplied screen dimensions. 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. - Stu
[Citadel Development] Re: Commit log to refs/heads/master
Di Sep 07 2010 17:01:12 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 hm, pushing multiple revisions produces broken commit mails.
[Citadel Development] Re:
Wed Sep 08 2010 4:33:02 am EDT EDT from dothebart @ Uncensored MS-RFC-Violator uses the timestamp when it polled the messages from citadel via imap to show and sort them? WTF? Do you mean that that is how it finds new messages?
[Citadel Development] Re:
Mi Sep 08 2010 06:04:06 EDT von samjam @ Uncensored Betreff: Re: Wed Sep 08 2010 4:33:02 am EDT EDT from dothebart @ Uncensored MS-RFC-Violator uses the timestamp when it polled the messages from citadel via imap to show and sort them? WTF? Do you mean that that is how it finds new messages? it polls for new messages, all it finds will have the timestamp of that poll, not the timestamp they were sent, like in tbird or webcit.
[Citadel Development] Re: Commit log refs/heads/master
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 define a MIME type for the data, serialize it, and store it in the user's My Citadel Config room. So far it's worked really well -- we haven't had to modify the user record in years and it's still quite small. The user can modify it if they are so inclined, though. What kind of protected data did you have in mind?
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
Sun Sep 05 2010 2:24:33 pm EDT EDT from dothebart @ Uncensored Subject: Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
hm,
did you run that script in advance?
since its not clever to rename subdirectories (citadel/ to citadel-7.83) in a git workingcopy (and symlink citadel/ to it), I instead made it create the symlink to the citadel directory.
If you already have it the other way arround, it won't work for you then ;-)
Not at all.
Originally I did what you did, but it's not enough - ./buildpackage debian src doesn't work and ./buildpackage src produces different paths to originally (because tar follows the symlink before tar-ing).
With just your patch, clean "/.buildpackage debain" were failing and symlinks-to-self of citadel was created in the citadel folder and of libcitadel in the libcitadel folder which made builds fail.
Sam
diff --git a/citadel/buildpackages b/citadel/buildpackages
index 8b18185..e78cc71 100755
--- a/citadel/buildpackages
+++ b/citadel/buildpackages
@@ -29,7 +29,7 @@ else
fi
if test $done = false; then
cd ..
- ln -sf citadel citadel-$CITADEL_VERSION
+ #ln -sf citadel citadel-$CITADEL_VERSION
cd citadel-$CITADEL_VERSION
else
cd ../citadel-$CITADEL_VERSION
@@ -47,18 +47,17 @@ case $1 in
fi
if test $2 == src; then
- cd ..
- rm -rf tmp
- mkdir tmp
- cp -rL citadel-$CITADEL_VERSION tmp
- cd tmp/citadel-$CITADEL_VERSION
+ rm -fr ../tmp/citadel-$CITADEL_VERSION
+ mkdir -p ../tmp/citadel-$CITADEL_VERSION
+ cp -rL . ../tmp/citadel-$CITADEL_VERSION
+ cd ../tmp/citadel-$CITADEL_VERSION
rm -rf `find -name .svn ` svn*tmp config.log config.status
find -type f -exec chmod a-x {} \;
chmod a+x configure *.sh *.sh.in debian/rules debian/*inst* debian/rules mkinstalldirs
cd ..
tar -chzf citadel_${CITADEL_VERSION}.orig.tar.gz citadel-${CITADEL_VERSION}/ --exclude debian/*
pwd
- cd citadel-${CITADEL_VERSION}; debuild -S -sa -kw.goesg...@outgesourced.org
+ cd citadel-${CITADEL_VERSION} debuild -S -sa -kw.goesg...@outgesourced.org
else
fakeroot dpkg-buildpackage
fi
@@ -100,8 +99,8 @@ email=cita...@outgesourced.org
;;
sourcedist)
- cd ..; tar --exclude .svn --exclude debian/* -chvzf citadel-$CITADEL_VERSION.tar.gz citadel-$CITADEL_VERSION/
- ;;
+ cd ..; tar --exclude .svn --exclude debian/* -chvzf citadel-$CITADEL_VERSION.tar.gz --transform s/^citadel/citadel-${CITADEL_VERSION}/ citadel/
+;;
*)
echo Not yet implemented. we have: debian
;;
[Citadel Development] Re: Fw: [PATCH] Fake the old version number for the paths inside the tar files
hm,
did you run that script in advance?
since its not clever to rename subdirectories (citadel/ to citadel-7.83) in a git workingcopy (and symlink citadel/ to it), I instead made it create the symlink to the citadel directory.
If you already have it the other way arround, it won't work for you then ;-)
Sa Sep 04 2010 11:21:32 EDT von samjam @ Uncensored Betreff: Fw: [PATCH] Fake the old version number for the paths inside the tar files
This stops ./buildpackage debian
getting caught in symlink looks, and makes "./buildpackage src" and "debian src" work
--- forwarded message ---
Wed Sep 01 2010 8:45:15 am EDT EDT from "Sam Liddicott" s...@liddicott.com Subject: [PATCH] Fake the old version number for the paths inside the tar files
Helps for: ./buildpackes debian src and ./buildpackages sourcedist --- citadel/buildpackages | 17 - 1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/citadel/buildpackages b/citadel/buildpackages
index 8b18185..e78cc71 100755
--- a/citadel/buildpackages
+++ b/citadel/buildpackages
@@ -29,7 +29,7 @@ else
fi
if test $done = false; then
cd ..
- ln -sf citadel citadel-$CITADEL_VERSION
+ #ln -sf citadel citadel-$CITADEL_VERSION
cd citadel-$CITADEL_VERSION
else
cd ../citadel-$CITADEL_VERSION
@@ -47,18 +47,17 @@ case $1 in
fi
if test $2 == src; then
- cd ..
- rm -rf tmp
- mkdir tmp
- cp -rL citadel-$CITADEL_VERSION tmp
- cd tmp/citadel-$CITADEL_VERSION
+ rm -fr ../tmp/citadel-$CITADEL_VERSION
+ mkdir -p ../tmp/citadel-$CITADEL_VERSION
+ cp -rL . ../tmp/citadel-$CITADEL_VERSION
+ cd ../tmp/citadel-$CITADEL_VERSION
rm -rf `find -name .svn ` svn*tmp config.log config.status
find -type f -exec chmod a-x {} \;
chmod a+x configure *.sh *.sh.in debian/rules debian/*inst* debian/rules mkinstalldirs
cd ..
tar -chzf citadel_${CITADEL_VERSION}.orig.tar.gz citadel-${CITADEL_VERSION}/ --exclude debian/*
pwd
- cd citadel-${CITADEL_VERSION}; debuild -S -sa -kw.goesg...@outgesourced.org
+ cd citadel-${CITADEL_VERSION} debuild -S -sa -kw.goesg...@outgesourced.org
else
fakeroot dpkg-buildpackage
fi
@@ -100,8 +99,8 @@ email=cita...@outgesourced.org
;;
sourcedist)
- cd ..; tar --exclude .svn --exclude debian/* -chvzf citadel-$CITADEL_VERSION.tar.gz citadel-$CITADEL_VERSION/
- ;;
+ cd ..; tar --exclude .svn --exclude debian/* -chvzf citadel-$CITADEL_VERSION.tar.gz --transform s/^citadel/citadel-${CITADEL_VERSION}/ citadel/
+;;
*)
echo Not yet implemented. we have: debian
;;
[Citadel Development] Re: CDB_USETABLE
Nope. It's either there or it isn't. I suppose you could drop the table :)
[Citadel Development] Re: Commit log to refs/heads/master
Tue Sep 14 2010 1:22:03 pm EDT EDT from IGnatius T Foobar @ Uncensored Subject: Re: Commit log to refs/heads/master How is this information stored on disk? Which information? The id's of messages in rooms. Is it a list or a tree or a hash or a string?
[Citadel Development] Re: Commit log to refs/heads/master
Do Sep 16 2010 07:52:39 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master
Files: de30eda12a396c5aa82841e1edd207eaba9cd5b3 webcit/po/da.po webcit/po/de.po webcit/po/en_GBpo webcit/po/es.po webcit/po/et_EE.po webcit/po/fr.po webcit/po/hu.po webcit/po/it.po webcit/po/nl.po webcit/po/pt_BR.po webcit/po/ru.po webcit/po/webcit.pot branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs refresh translations
ok, now
wc_printf("img src="" /> if (!strcasecmp(bstr("sc"), "update")) { /* Translators: RSVP aka Répondez s'il-vous-plaît Is the term that the recipient of an ical-invitation should please answer this request. */ wc_printf(_("Your calendar has been updated to reflect this RSVP."));
gives you this po:
#. Translators: RSVP aka Répondez s'il-vous-plaît Is the term#. that the recipient of an ical-invitation should please#. answer this request.#: ../calendar.c:381msgid "Your calendar has been updated to reflect this RSVP."msgstr "u.A.w.g. wurde eingetragen."
which could look like this on launchpad:
https://translations.launchpad.net/ncmpc/trunk/+pots/ncmpc/de/6/+translate
(the blue I with the text behind)
so if there are more complicated terms like RSVP, this is the smart way to direct the translation into the right direction.
I'm going to upload those po's under bsd to launchpad now, and request license change for the rest.
[Citadel Development] Re: Commit log to refs/heads/master
So Sep 12 2010 17:25:32 EDT von "Wilfried Goesgens" dotheb...@citadel.org Betreff: Commit log to refs/heads/master Files: 4ee3c6035abd686a240fd117fdcd2bdcecd69d44 citadel/modules/rssclient/serv_rssclient.c branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs rewrite rss parser: branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs handle links more properly branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs properly catch CDATA stuff branches config description git-daemon-export-ok HEAD hooks info objects packed-refs refs have hash of namespaces which we "understand" ok, i've chopped stuff into pieces, and recombined it. tested it out with quiet a bunch of rss'es; i've had problems with feeds missing bodies, authors, subjects... most of them find a good string now. (oh, and ups, need to re-enable double-fetch detection)
[Citadel Development] Re: Patch to eliminate backtrace if client disconnects in client_write
Excellent feedback - would definitely be willing to provide. I've used Citadel for a long time, figure it's time to start contributing back :) Sat Sep 18 2010 07:53:45 AM EDT from dothebart @ Uncensored Subject: Re: Patch to eliminate backtrace if client disconnects in client_write Stu, since that backtrace was primarily intended to debug unconditional connection aborts, this is not the right way to change this. probably having a commandline switch to enable it in first place is the right solution for what you'd want here? Are you willing to provide such a patch?
[Citadel Development] Re: Wiki mode yet?
Fr Aug 27 2010 08:33:51 EDT von samjam @ Uncensored Betreff: Wiki mode yet? Should wiki mode be working yet? (I'm running svn trunk head) Yes, it should be working. There may be (but hopefuly aren't ;-) issues with creation, or the dark blue bar above with the icons letting you browse history jump back to the main page from sub-pages.
[Citadel Development] Re: Wiki mode yet?
Fri Aug 27 2010 8:41:46 am EDT EDT from dothebart @ Uncensored Subject: Re: Wiki mode yet? Fr Aug 27 2010 08:33:51 EDT von samjam @ Uncensored Betreff: Wiki mode yet? Should wiki mode be working yet? (I'm running svn trunk head) Yes, it should be working. There may be (but hopefuly aren't ;-) issues with creation, or the dark blue bar above with the icons letting you browse history jump back to the main page from sub-pages. I create a new room with default wiki view, and always it shows as: There is no page called 'home' here.Select the 'Edit this page' link in the room banner if you would like to create this page I click "Edit this Page" and put in some text and click post message but I am back to "There is no page called 'home' here" What do I do wrong? (When the wiki room is a personal mail folder, it doesn't even post a message that IMAP can even see)
[Citadel Development] Re: Git?
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.
[Citadel Development] Re: Git?
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?
[Citadel Development] Re: Citadel commit log: revision 8886
i'd also like to have a look at that 'save message to drafts folder via imap' thing...
[Citadel Development] Re: leak?
Thu Aug 26 2010 04:17:07 EDT from dothebart @ Uncensored Subject: leak? shouldn't void imap_rescan_msgids(void) call imap_free_msgids(); /* If there was already a map, free it */ before writing on it? Or do I miss something over here? no. its comparing the items in the list to ones loaded from disk.
[Citadel Development] Re: Guest mode
in general, since port 504 is open to the net, shouldn't everything be checked yet?
[Citadel Development] Re: Unusual SSL behavior, likely bug
if you compile citadel with '-D BIGBAD_IODBG' as one of your CFLAGS, it will write a transscript of what its doing on al IO chanels to /tmp/modulename_fd_random this could give us a chance to catch your incident. do you have some test system where you could try that out? (on a production system /tmp/ would run full verry quick)
[Citadel Development] Re: Unusual SSL behavior, likely bug
Aug 17 2010 11:05pm from dothebart @uncnsrd Subject: Re: Unusual SSL behavior, likely bug if you compile citadel with '-D BIGBAD_IODBG' as one of your CFLAGS, it will write a transscript of what its doing on al IO chanels to /tmp/modulename_fd_random this could give us a chance to catch your incident. do you have some test system where you could try that out? (on a production system /tmp/ would run full verry quick) I can populate a test system with data over the weekend, and will try it out! - Stu
[Citadel Development] Re: Citadel commit log: revision 8839
*gna* howto shoot yourself into the foot the smartest way. Mo Aug 16 2010 15:48:04 EDT von "dothebart" dotheb...@uncensored.citadel.org Betreff: Citadel commit log: revision 8839 r8839 | dothebart | 2010-08-16 15:48:03 -0400 (Mon, 16 Aug 2010) | 2 lines Changed paths: M /trunk/citadel/utils/setup.c * edit_value(): if no environment variable specified, use "" * set_str_val(): don't check NULL here, expect it to be non-null.
[Citadel Development] Re: Citadel commit log: revision 8825
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 that MacOS would also be affected, it became clear that this needed to be re-thought. Linux users will probably still want to listen on any ipv4 or ipv6 by omitting the listening address completely. OpenBSD and MacOS users will have to do that plus run a second copy of webcit listening on 0.0.0.0 to accept IPv4 connections. This implementation still *requires* the host to support IPv6, even if only IPv4 is in use. I don't think that's a problem -- pretty much all of the major operating systems have had IPv6 support for nearly a decade now. Next up: the Citadel server. This will add a bit more complexity because we can't just say run a second copy on 0.0.0.0 if they want to run both protocols.
[Citadel Development] Re: Citadel commit log: revision 8825
webcit 127.0.0.1 504 won't work for me anymore too. i'm getting: Can't connect to 127.0.0.1.504: Connection refused
[Citadel Development] Re: Citadel commit log: revision 8825
Citserver doesn't have IPv6 yet.
[Citadel Development] Re: Citadel commit log: revision 8834
gentlemen, please don't forget to 'make clean' your workingcopies. So Aug 15 2010 17:18:31 EDT von "dothebart" dotheb...@uncensored.citadel.org Betreff: Citadel commit log: revision 8834 r8834 | dothebart | 2010-08-15 17:18:31 -0400 (Sun, 15 Aug 2010) | 6 lines Changed paths: M /trunk/webcit/roomlist.c M /trunk/webcit/roomops.c M /trunk/webcit/roomops.h M /trunk/webcit/static/t/menu/advanced_roomcommands.html M /trunk/webcit/static/t/room/edit/tab_expire.html M /trunk/webcit/webcit.h * cleanup shuffle 'folders' struct (make clean!); Order and listorder are the same; follow this change in roomlist.c * remove unused entries from wcsession * streamline when we flush the rooms folder cache * remove old roomediting code * extract SaveRoomAide(SETA), GetCurrentRoomFlags(GETR), SetCurrentRoomFlags(SETR) into their own functions, use them all over the place; use folder struct instead of local structs / var to save state between GETR SETR * tab_expire.html: fix policy names we show.
[Citadel Development] Re: Citadel commit log: revision 8825
So Aug 15 2010 16:30:16 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8825 Citserver doesn't have IPv6 yet. yep, but for some reason webcit isn't able to connect to 127.0.0.1 anymore, aside of resolving 'localhost' to that. (it seems as if resolving localhost already is an issue in 7.8x)
[Citadel Development] Re: sending messages in optional anonymous rooms...
Not that anonymous after all? Not for someone with admin rights.
[Citadel Development] Re: CC WC bad..
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; in every function anyway, I'd rather do this the right way.
[Citadel Development] Re: CC WC bad..
I think the define is OK, there just should be a CCC which is set once, so the compiler can actualy see a pointer to CitContext so it can correctly enlist it in the dependency list
[Citadel Development] Re: CC WC bad..
the CCC also gives you a chance to have easy access to it once you're in gdb and wanting to watch some of its members. else you'll have to go up to some obscure frame, find out some obscure function local pointer, get your CC pointer thereof and watch your stuff there. Real inconvenient in comparison to print CCC-room
[Citadel Development] Re: Citadel commit log: revision 8716
ok, it seems as if that fixes the KMail imap list problem. one remaining is that we won't compile on *bsd (reported by debian/K Freebsd) because of threads.c this_thread-reltid = syscall(SYS_gettid);don't know how to solve this the best way, #ifdef LINUX won't work, any other ideas? how's that macro else called?
[Citadel Development] Re: Citadel commit log: revision 8703
Jul 21 2010 9:56am from ajc a...@uncensored.citadel.org to room_citadel_development@uncensored.citadel.org Subject: Citadel commit log: revision 8703 r8703 | ajc | 2010-07-21 12:56:29 -0400 (Wed, 21 Jul 2010) | 1 line Changed paths: M /branches/stable-78x/citadel/modules/imap/imap_fetch.c M /trunk/citadel/modules/imap/imap_fetch.c * imap_load_part() is expecting the desired_section to be a char*, not a ChrPtr. Fixed. This probably fixes Alpine. Also bac kported to stable. You guys beat me to the punch on trying to fix this one :) I'll give it a test and see if the issue is resolved. Thanks so much! - Stu
[Citadel Development] Re:
Di Jul 20 2010 17:06:33 EDT von scianos @ Uncensored 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. This is a regression from the previous branch. If you can hint as to the location of where partial fetch is implemented in the code (not familiar with the code base for IMAP in Citadel), I can try taking a look at it. most of it is done in modules/imap/imap_fetch.c if I get that correctly. msgbase.c may also be involved for loading messages from the disk.
[Citadel Development] Re:
Jul 20 2010 2:16pm from dothebart @uncnsrd Subject: Re:
[Citadel Development] Re:
Jul 20 2010 2:18pm from dothebart @uncnsrd Subject: Re: could you ngrep / tcpdum a non ssl'ed communication with a dummy password? http://www.citadel.org/doku.php/faq:mastering_your_os:net_sniff Sure... Will do tonight.
[Citadel Development] Re: Citadel commit log: revision 8671
Gaah, that was a pain in the ass to fix.
[Citadel Development] Re: Citadel commit log: revision 8674
* 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?
[Citadel Development] Re: QDIR the other way arround?
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.
[Citadel Development] Re: Citadel commit log: revision 8613
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.
[Citadel Development] Re: Citadel commit log: revision 8603
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.
[Citadel Development] Re: Citadel commit log: revision 8604
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.
[Citadel Development] Re: Citadel commit log: revision 8597
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.
[Citadel Development] Re: Citadel commit log: revision 8597
that seems to be if get_serv_info() fails?
it does...
serv_printf("IDEN %d|%d|%d|%s|%s", DEVELOPER_ID, CLIENT_ID, CLIENT_VERSION, ChrPtr(user_agent), ChrPtr(browser_host) ); StrBuf_ServGetln(Buf);
serv_puts("ICAL sgi|1"); StrBuf_ServGetln(Buf);
serv_puts("INFO"); StrBuf_ServGetln(Buf); if (GetServerStatus(Buf, NULL) != 1) {
maybe you'd like to add a debug statement here?? FreeStrBuf(Buf); return NULL; }
[Citadel Development] Re: Citadel commit log: revision 8597
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. :)
[Citadel Development] Re: Citadel commit log: revision 8597
Ok, here's the answer: The INFO command returned a *blank line*.
[Citadel Development] Re: Citadel commit log: revision 8599
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 greeting banner for errors other than 571. Now if it gets anything that doesn't start with 2XX, it'll throw an error to the user.
[Citadel Development] Re: Citadel commit log: revision 8597
Di Jun 01 2010 11:32:17 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8597 Ok, here's the answer: The INFO command returned a *blank line*. hm, theres not much way out in cmd_info; it might be cmd_iden barfed? maybe we'll find out.
[Citadel Development] Re: Citadel commit log: revision 8599
ah, yea that might be a good thing to do. Maybe 200 isn't the appropriate HTTP status for that situation either?
[Citadel Development] Re: Citadel commit log: revision 8599
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 anything interesting comes up.
[Citadel Development] Re: Citadel commit log: revision 8597
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 watchdog script, and put WebCit into the monitoring system at our data center. If WebCit becomes unresponsive it will send a text message to my phone and I can take a look at what's really going on.
[Citadel Development] Re: close button in addressbook popup gone..
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.
[Citadel Development] Re: close button in addressbook popup gone..
ah, great. We've got a bug against pkg-citadel - webcit that it has an old copy. Feivel will be glad to hear.
[Citadel Development] Re: Citadel commit log: revision 8597
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 lives right now. We had a watchdog timer event on Uncensored last night. I'm not sure it was actually deadlocked though; it may have just taken too long to respond but would have eventually responded anyway. I changed the timeout on the script from 5 seconds to 20 seconds. We'll see what happens now.
[Citadel Development] Re: Citadel commit log: revision 8571
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 in sock_puts (sock=0xb6cf5ff8, buf=0xb6cf1fbc READ 4000|4000) at clientsocket.c:331 #4 0x08096f99 in receive_spool (sock=0xb6cf5ff8, remote_nodename=0xb6cf602c dogpound2) at modules/network/serv_network.c:1829 #5 0x08097595 in network_poll_node (node=0xb6cf602c dogpound2, secret=0xb6cf712c friko, host=0xb6cf732c 69.212.163.244, port=0xb6cf722c 504) at modules/network/serv_network.c:2045 #6 0x0809770e in network_poll_other_citadel_nodes (full_poll=0) at modules/network/serv_network.c:2104 #7 0x0809b175 in network_do_queue (args=0x0) at modules/network/serv_network.c:2177 #8 0x08074114 in ctdl_internal_thread_func (arg=0x8ea5f80) at threads.c:849 #9 0x006b573b in start_thread () from /lib/libpthread.so.0 #10 0x003b1cfe in clone () from /lib/libc.so.6 So, we're hanging up on I/O again, and in this case it's locking up the networker. I'm going to make some changes to decouple network polling from network spooling, but the I/O problem still has to be fixed.
[Citadel Development] Re: Citadel commit log: revision 8571
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.
[Citadel Development] Re: Citadel commit log: revision 8567
If you have a Blogger account, it can be used as an OpenID provider too.
[Citadel Development] Re: Citadel commit log: revision 8567
Mi Mai 12 2010 08:28:34 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8567 If you have a Blogger account, it can be used as an OpenID provider too. hm, nope... Do you?
[Citadel Development] Re: Citadel commit log: revision 8567
I assume you've tested this with an actual OpenID account to make sure it still works?
[Citadel Development] Re: Citadel commit log: revision 8567
Di Mai 11 2010 22:53:18 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8567 I assume you've tested this with an actual OpenID account to make sure it still works? if phpmyid may be called that, yes. are there others to get a cheap test with?
[Citadel Development] RE: MacOS X compilation issues
Mon May 10 2010 04:18:23 AM EDT from dothebart @ Uncensored Subject: MacOS X compilation issues hm, its that line: memcpy(return_options, HKEY(SUBSCRIBED_STR) + 1); HKEY is a macro which should expand to 2 arguments; its in libcitadel.h; do you have that installed? is it recent enough? I definitely do, I checked out all trunk modules at once and the system has never had any Citadel related files before.
[Citadel Development] RE: MacOS X compilation issues
Mo Mai 10 2010 04:42:13 EDT von mcbridematt @ Uncensored Betreff: RE: MacOS X compilation issues Mon May 10 2010 04:18:23 AM EDT from dothebart @ Uncensored Subject: MacOS X compilation issues hm, its that line: memcpy(return_options, HKEY(SUBSCRIBED_STR) + 1); HKEY is a macro which should expand to 2 arguments; its in libcitadel.h; do you have that installed? is it recent enough? I definitely do, I checked out all trunk modules at once and the system has never had any Citadel related files before. Please try.. to have some use of HKEY in the main() check whether your libcitadel.h is the right one (if its in there) and if you edit that and add a syntax error if it wastes the whole compile try copying the HKEY macro into the imap_... if that helps, maybe explicityl add an include there? -
[Citadel Development] Re: Citadel commit log: revision 8562
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 session (and the thread) after each poll is complete. In other words, from a protocol point of view it looks exactly like every other service offered by the Citadel server. Oh, and it's totally b0rken when viewed in Internet Exploder. :(
[Citadel Development] Re: Citadel commit log: revision 8555
Uncensored will do an upgrade to svn head and automatically restart services at 2:30am US Eastern time.
[Citadel Development] Re: Citadel commit log: revision 8555
Hmm ... I don't think it happened. Dunno why. :(
[Citadel Development] Re: Citadel commit log: revision 8546
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 cycles.
[Citadel Development] Re: Citadel commit log: revision 8546
Fr Apr 30 2010 09:43:39 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8546 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 cycles. well, Readability is also a thing depending on what you're used to ;-P I'd be in for doing this with StrBuf so you're shure its fast, correct (no buffer cuts etc.), and readable.
[Citadel Development] Re: Citadel commit log: revision 8546
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 the client to do this. So we have to remember all possible buddies that the client *might* have in its roster, and delete them So, what I still need to have it do at the beginning of a session is: 1. Load the mortuary 2. Delete (from the hash table) any buddies who happen to be online *now* 3. Send roster-delete messages for all the others And yes, the list will grow forever. There's no way to avoid it.
[Citadel Development] Re: Citadel commit log: revision 8546
2. Delete (from the hash table) any buddies who happen to be online *now* Heh, Perfect! we just implemented Deleting ;-) Maybe we need to do this with a Hashkey now too.
