mailsync-list — discussion about development, config, bugs etc.

Re: [Mailsync-list] minor problems with mailsync

[Tomas P. <tp...@so...>]

On Mon, 7 Jun 2004 cil...@co... wrote:

> > > contrary to the documentation, multiple messages w/o an ID get deleted
> > > as duplicates! This is surely a bug.
>
> > I'm not sure if this is true... I think it only removes messages with
> > the same ID, not w/o ID.
>
> I have confirmed this behavior: multiple messages without a Message-ID are
> treated as duplicates.  This may be specific to MH, but is still a bug.

This is a bug and it is fixed in CVS. However...

> > > Finally, the "-t md5" command line option yields "abort".
>
> I think I've tracked this down: this option works fine PROVIDED mailsync is
> never run with the default "-t msgid" option, but fails if the sync file
> contains message ids.  (The msgid option works fine even if the sync file
> contains md5 data, but of course converts the format of this file to msgid
> data, which will then cause the md5 option to fail.)
>
> So long as this works, the first bug can be worked around -- although it could
> provide an unpleasant surprise to the unaware.

For a while I've been mixing msgid and md5 back and forth and it *did*
work for me - sometimes it was a bit weird but I had never experienced
data loss.

So it'd be nice if you could reproduce this with the version in CVS.
However...

MH specifically has a problem with the version in CVS. I'll have a look at
Michael's patch and try to integrate it one of these two days and I'll let
you know (posting to this list). So please hold your breath for two more
days and try the CVS version then ;-). OK?
*t

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

Re: [Mailsync-list] minor problems with mailsync

[<cil...@co...>]

> > contrary to the documentation, multiple messages w/o an ID get deleted
> > as duplicates! This is surely a bug.

> I'm not sure if this is true... I think it only removes messages with
> the same ID, not w/o ID. 

I have confirmed this behavior: multiple messages without a Message-ID are
treated as duplicates.  This may be specific to MH, but is still a bug.

> > Finally, the "-t md5" command line option yields "abort".

I think I've tracked this down: this option works fine PROVIDED mailsync is
never run with the default "-t msgid" option, but fails if the sync file
contains message ids.  (The msgid option works fine even if the sync file
contains md5 data, but of course converts the format of this file to msgid
data, which will then cause the md5 option to fail.)

So long as this works, the first bug can be worked around -- although it could
provide an unpleasant surprise to the unaware.

Re: [Mailsync-list] minor problems with mailsync

[Michael 'h. K. <mai...@zz...>]

I think, most of your problems are related to cclient rather than
mailsync, which I'm not really expert in (maybe Tomas will tell you
more, but he's not using MH, so it's not likely).

But you may want to look at the magic ~/.imaprc file. I remember, I had
to patch c-client at some point to make it work with ssh. Maybe I didn't
have to and, although I did, and you just can put something like 'set
ssh-path /usr/bin/ssh' or something like that into .imaprc. You will
have to check imap documentation. I gave up using ssh when I started to
sync with another imap account, so now I have two syncs: one as a
cronjob on the server, which syncs MH with a 'real' imap account and
another on my machine which syncs my local MH with the said imap
account. I didn't try to do without RSA, but imap over ssh was a pain,
anyway. Maybe I just don't understand the complexities of c-client ;-) I
wouldn't expect passwd option to feed password to ssh, anyway.

> Finally, the "-t md5" command line option yields "abort", a shame since I'm

I think it depends on the mailsync version you're using. Tomas knows
better (again). Maybe you should try CVS version to get this working,
but you shouldn't go for it, since it has hard time purging messages from
local MH stores.

> using MH (really nmh), and draft messages (and therefore also file copies of
> outgoing mail) have no Message-ID. This is a serious problem -- especially
> since, contrary to the documentation, multiple messages w/o an ID get deleted
> as duplicates! This is surely a bug.

I'm not sure if this is true... I think it only removes messages with
the same ID, not w/o ID. But I think, if you use md5, you'll have
duplicates for each modified draft message...

Love,
H

[Mailsync-list] minor problems with mailsync

[<cil...@co...>]

mailsync works great -- solves a longstanding problem for me.

The following features don't seem to be working:
* use of ssh to reach a remote imapd
* the md5 algorithm fails

Details:

The only way I could get ssh to be used was to replace rsh by a link to
ssh. Perhaps ssh is not "enabled" in my local c-client library? I didn't
compile it myself, but am using the SuSE RPM (5.1.1); is there any way to fix
this without recompiling?

Also, the passwd option doesn't seem to work with ssh; it hangs unless I use
RSA authorization. But this is only a minor inconvenience, as is the previous
problem.

Finally, the "-t md5" command line option yields "abort", a shame since I'm
using MH (really nmh), and draft messages (and therefore also file copies of
outgoing mail) have no Message-ID. This is a serious problem -- especially
since, contrary to the documentation, multiple messages w/o an ID get deleted
as duplicates! This is surely a bug.

Comments and suggestions welcome.

Further wish list:

1. A way to specify the path to the remote imapd. Not all machines have an
   /etc/rimapd.

2. A way to force the use of ssh only, disabling rsh.

3. More general pattern matching in store definitions, or at least the ability
   to exclude certain mailboxes. (There's an easy workaround using symbolic
   links if both machines run UNIX.)

 

Re: [Mailsync-list] two build fixes

[Tomas P. <tp...@so...>]

On Sat, 5 Jun 2004, Michael 'hacker' Krelin wrote:

> > > +AC_CHECK_LIB(crypt,crypt)
> > >
> > >  AC_INET_FUNCS(,[
> > >   AC_MSG_ERROR([essential functions missing])
> >
> > So you check libcrypt here, but that won't automatically include it in
> > the "LIBS" when linking or will it?
>
> The default action of AC_CHECK_LIB is to add it to LIBS

Committed this part.
*t

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

[Mailsync-list] mh sync

[Michael 'h. K. <mai...@zz...>]

Yet another attempt on fix. Once again after such a long break in
digging mailsync I'm totally lost in all the mailbox open operations,
but this is what I had to do without using if(ismh) to get mh sync
properly. basically, mailbox_open makes mh mailboxes forget about
messages flagged for removal. So, I had to expunge mail before going any
further and not open it if it's already open. I have no clue if it will
break anything or not...

There's also a part of gcc3.4 fix here. I've upgraded to imap2004 (which
also requires tons of fixes in headers and code to compile even on gcc
3.anything). And imap2004, in addition to #undef max requires #undef min
;-) But we're talking about mh now...

Index: src/mailsync_main.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/mailsync_main.cc,v
retrieving revision 1.16
diff -u -r1.16 mailsync_main.cc
--- src/mailsync_main.cc	5 May 2003 17:09:43 -0000	1.16
+++ src/mailsync_main.cc	5 Jun 2004 19:48:23 -0000
@@ -21,6 +21,8 @@
 using std::make_pair;
 
 #include "c-client.h"
+#undef max
+#undef min
 
 #include "configuration.h"     // configuration parsing and setup
 #include "options.h"           // options and default settings
@@ -442,6 +444,19 @@
           if (success) removed_b++;
         }
 
+        //////////////////////// expunging emails /////////////////////////
+        
+        if (debug) printf( " Expunging messages\n" );
+
+        if (! (options.no_expunge || options.simulate) ) {
+          int n_expunged_a = store_a.mailbox_expunge( curr_mbox->first );
+          int n_expunged_b = store_b.mailbox_expunge( curr_mbox->first );
+          if (n_expunged_a) printf( "Expunged %d mail(s) in store %s\n"
+                                    , n_expunged_a, store_a.name.c_str() );
+          if (n_expunged_b) printf( "Expunged %d mail(s) in store %s\n"
+                                    , n_expunged_b, store_b.name.c_str() );
+        }
+
         //////////////////// copying messages ///////////////////////
         
         if (debug)
@@ -490,19 +505,6 @@
                   now_n, curr_mbox->first.c_str() );
         }
 
-        //////////////////////// expunging emails /////////////////////////
-        
-        if (debug) printf( " Expunging messages\n" );
-
-        if (! (options.no_expunge || options.simulate) ) {
-          int n_expunged_a = store_a.mailbox_expunge( curr_mbox->first );
-          int n_expunged_b = store_b.mailbox_expunge( curr_mbox->first );
-          if (n_expunged_a) printf( "Expunged %d mail(s) in store %s\n"
-                                    , n_expunged_a, store_a.name.c_str() );
-          if (n_expunged_b) printf( "Expunged %d mail(s) in store %s\n"
-                                    , n_expunged_b, store_b.name.c_str() );
-        }
-
         if (options.delete_empty_mailboxes) {
           if (now_n == 0) {
             // add empty mailbox to empty_mailboxes
Index: src/store.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/store.cc,v
retrieving revision 1.8
diff -u -r1.8 store.cc
--- src/store.cc	1 Jun 2004 09:34:36 -0000	1.8
+++ src/store.cc	5 Jun 2004 19:48:23 -0000
@@ -467,7 +467,8 @@
 //////////////////////////////////////////////////////////////////////////
 {
   expunged_mails = 0; // is manipulated by the c-client callback mm_expunge
-  this->mailbox_open( mailbox_name, 0);
+  if(!stream)
+   this->mailbox_open( mailbox_name, 0);
   mail_expunge( this->stream );
   return expunged_mails;
 }

Love,
H

Re: [Mailsync-list] two build fixes

[Michael 'h. K. <mai...@zz...>]

> > > Index: acinclude/ac_with_cclient.m4
> > > ===================================================================
> > > RCS file: /cvsroot/mailsync/mailsync/acinclude/ac_with_cclient.m4,v
> > > retrieving revision 1.8
> > > diff -u -r1.8 ac_with_cclient.m4
> > > --- acinclude/ac_with_cclient.m4	2 Jun 2004 07:38:36 -0000	1.8
> > > +++ acinclude/ac_with_cclient.m4	5 Jun 2004 13:03:31 -0000
> > > @@ -85,7 +85,9 @@
> > >        AC_MSG_RESULT([yes])
> > >        CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
> > >       fi
> > > -
> > > +    fi
> > > +
> > > +    if test "${need_krb}" != "yes" -o "${HAVE_KRB5_GSSAPI}" = "yes" ; then
> > >       dnl
> > >       dnl Checking whether c-client was built with ssl support
> > >       dnl
> > 
> > OK, however this isn't correct either (?). We need to test for SSL whether
> > independently of the conditions you are testing for above!? Which means
> > I'd skip your added test alltogether and instead unindent the rest of the
> > tests...:
> 
> In fact, if the conditions aren't met we do not need to test anything
> anymore.

But, I have to admit, I don't like my code, anyway. It's lacking beauty.

Love,
H

Re: [Mailsync-list] two build fixes

[Michael 'h. K. <mai...@zz...>]

> > +AC_CHECK_LIB(crypt,crypt)
> >
> >  AC_INET_FUNCS(,[
> >   AC_MSG_ERROR([essential functions missing])
> 
> So you check libcrypt here, but that won't automatically include it in
> the "LIBS" when linking or will it?

The default action of AC_CHECK_LIB is to add it to LIBS

> > 2. The latest 'added verbosity' patch breaks build -- it only checks for
> > ssl if kerberos is required.
> >
> > Index: acinclude/ac_with_cclient.m4
> > ===================================================================
> > RCS file: /cvsroot/mailsync/mailsync/acinclude/ac_with_cclient.m4,v
> > retrieving revision 1.8
> > diff -u -r1.8 ac_with_cclient.m4
> > --- acinclude/ac_with_cclient.m4	2 Jun 2004 07:38:36 -0000	1.8
> > +++ acinclude/ac_with_cclient.m4	5 Jun 2004 13:03:31 -0000
> > @@ -85,7 +85,9 @@
> >        AC_MSG_RESULT([yes])
> >        CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
> >       fi
> > -
> > +    fi
> > +
> > +    if test "${need_krb}" != "yes" -o "${HAVE_KRB5_GSSAPI}" = "yes" ; then
> >       dnl
> >       dnl Checking whether c-client was built with ssl support
> >       dnl
> 
> OK, however this isn't correct either (?). We need to test for SSL whether
> independently of the conditions you are testing for above!? Which means
> I'd skip your added test alltogether and instead unindent the rest of the
> tests...:

In fact, if the conditions aren't met we do not need to test anything
anymore.

> ?
> *t [working without (broken) mouse, which turns out to be a rather
>     difficult feat: no copy/paste, various apps (mozilla!) not navigeable
>     without mouse etc.]

That's where pure tty comes in handy ;-)

Love,
H

Re: [Mailsync-list] two build fixes

[Tomas P. <tp...@so...>]

On Sat, 5 Jun 2004, Michael 'hacker' Krelin wrote:

> Two build fixes.
>
> 1. As I mentioned before, I had to set LIBS=-lcrypt to make it build.
>
> Index: configure.ac
> ===================================================================
> RCS file: /cvsroot/mailsync/mailsync/configure.ac,v
> retrieving revision 1.13
> diff -u -r1.13 configure.ac
> --- configure.ac	6 Jan 2004 19:58:08 -0000	1.13
> +++ configure.ac	5 Jun 2004 13:03:31 -0000
> @@ -17,6 +17,7 @@
>
>  AC_FUNC_STAT
>  AC_CHECK_FUNCS([getpass memset strchr strdup strerror strtoul])
> +AC_CHECK_LIB(crypt,crypt)
>
>  AC_INET_FUNCS(,[
>   AC_MSG_ERROR([essential functions missing])

So you check libcrypt here, but that won't automatically include it in
the "LIBS" when linking or will it?

> 2. The latest 'added verbosity' patch breaks build -- it only checks for
> ssl if kerberos is required.
>
> Index: acinclude/ac_with_cclient.m4
> ===================================================================
> RCS file: /cvsroot/mailsync/mailsync/acinclude/ac_with_cclient.m4,v
> retrieving revision 1.8
> diff -u -r1.8 ac_with_cclient.m4
> --- acinclude/ac_with_cclient.m4	2 Jun 2004 07:38:36 -0000	1.8
> +++ acinclude/ac_with_cclient.m4	5 Jun 2004 13:03:31 -0000
> @@ -85,7 +85,9 @@
>        AC_MSG_RESULT([yes])
>        CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
>       fi
> -
> +    fi
> +
> +    if test "${need_krb}" != "yes" -o "${HAVE_KRB5_GSSAPI}" = "yes" ; then
>       dnl
>       dnl Checking whether c-client was built with ssl support
>       dnl

OK, however this isn't correct either (?). We need to test for SSL whether
independently of the conditions you are testing for above!? Which means
I'd skip your added test alltogether and instead unindent the rest of the
tests...:

@@ -85,7 +85,9 @@
       AC_MSG_RESULT([yes])
       CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
      fi
-
+    fi

-      dnl
-      dnl Checking whether c-client was built with ssl support
-      dnl
+     dnl
+     dnl Checking whether c-client was built with ssl support
+     dnl
      [and so on until...]
-     fi

?
*t [working without (broken) mouse, which turns out to be a rather
    difficult feat: no copy/paste, various apps (mozilla!) not navigeable
    without mouse etc.]

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

[Mailsync-list] two build fixes

[Michael 'h. K. <mai...@zz...>]

Hello there,

Two build fixes.

1. As I mentioned before, I had to set LIBS=-lcrypt to make it build.

Index: configure.ac
===================================================================
RCS file: /cvsroot/mailsync/mailsync/configure.ac,v
retrieving revision 1.13
diff -u -r1.13 configure.ac
--- configure.ac	6 Jan 2004 19:58:08 -0000	1.13
+++ configure.ac	5 Jun 2004 13:03:31 -0000
@@ -17,6 +17,7 @@
 
 AC_FUNC_STAT
 AC_CHECK_FUNCS([getpass memset strchr strdup strerror strtoul])
+AC_CHECK_LIB(crypt,crypt)
 
 AC_INET_FUNCS(,[
  AC_MSG_ERROR([essential functions missing])

2. The latest 'added verbosity' patch breaks build -- it only checks for
ssl if kerberos is required.

Index: acinclude/ac_with_cclient.m4
===================================================================
RCS file: /cvsroot/mailsync/mailsync/acinclude/ac_with_cclient.m4,v
retrieving revision 1.8
diff -u -r1.8 ac_with_cclient.m4
--- acinclude/ac_with_cclient.m4	2 Jun 2004 07:38:36 -0000	1.8
+++ acinclude/ac_with_cclient.m4	5 Jun 2004 13:03:31 -0000
@@ -85,7 +85,9 @@
       AC_MSG_RESULT([yes])
       CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
      fi
-     
+    fi
+
+    if test "${need_krb}" != "yes" -o "${HAVE_KRB5_GSSAPI}" = "yes" ; then
      dnl
      dnl Checking whether c-client was built with ssl support
      dnl

Love,
H

[Mailsync-list] Re: (compilation fix) [was: Re: mailsync 5.1.2 released ?]

[Heiko R. <ro...@su...>]

On Wed, 2 Jun 2004, Tomas Pospisek wrote:

> On Tue, 1 Jun 2004, Heiko Rommel wrote:
> 
> > However, I had to add
> 
> Comitted, however I don't see the point of changing a string represented
> by "char*" to "unsigned char*", as c-client did. Do you?

No, sorry. I asked our maintainer of imap(-devel). He doesn't know either.

-- 
Heiko Rommel                             ro...@su...
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55

[Mailsync-list] (compilation fix) [was: Re: mailsync 5.1.2 released ?]

[Tomas P. <tp...@so...>]

On Tue, 1 Jun 2004, Heiko Rommel wrote:

> However, I had to add

Comitted, however I don't see the point of changing a string represented
by "char*" to "unsigned char*", as c-client did. Do you?
*t

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

[Mailsync-list] Re: mailsync 5.1.2 released ?

[Tomas P. <tp...@so...>]

On Tue, 1 Jun 2004, Heiko Rommel wrote:

> On Tue, 1 Jun 2004, Tomas Pospisek wrote:
>
> > Hallo Heiko,
> >
> > On Tue, 1 Jun 2004, Heiko Rommel wrote:
> >
> > > do I read it correctly that 5.1.2 is no release version ?
> >
> > Yes, it's "only" a CVS snapshot ("make dist").
> >
> > > If yes, what is missing for a release ?
> >
> > synchronizing mh boxes is still lacking. :-/
> > *t
> >
>
> Is the issue concerning mh new to 5.1.2 in a way that sth changed that breaks
> mh ?

I actually can't tell. I know there were problems, but I have difficulty
finding out exactly what they were. It seems to be difficult these days to
find a #mh user that actually runs mailsync...

We need a volounteer...
*t

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

Re: [Mailsync-list] this looks curious (not selectable mailbox)

[Michael 'h. K. <mai...@zz...>]

> Which means that:
> 
> a) configure did not find a working kerberos installation
> b) configure found out that c-client was built kerberos gssapi support
> 
> -> in order to link mailsync against c-client we need a working kerberos
>    installation which we don't have here.
> 
> Am I correct? I guess that could be made clearer in the respective
> acinclude file ac_with_cclient.m4. Instead of:
> 
>     if test "${need_krb}" = "yes" -a "${HAVE_KRB5_GSSAPI}" != "yes" ; then
>      ifelse([$2], , :, [$2])
>     else
>      if test "${need_krb}" = "yes" ; then
>       CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
>      fi
> 
> we could write:
> 
> 
>     if test "${need_krb}" = "yes"; then
>      dnl
>      dnl Checking if the necessary kerberos installation is available in
>      dnl order to be able to link against c-client
>      dnl
>      AC_MSG_CHECKING([if the necessary kerberos installation is available in order to be able to link against c-client])
>      if test "${HAVE_KRB5_GSSAPI}" = "yes"; then
>       AC_MSG_RESULT([yes])
>       CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
>      else
>       AC_MSG_RESULT([no])
>       ifelse([$2], , :, [$2])
>      fi
>     fi
> 
> is that correct? Michael? (Jak bilo v Moskve? Kako je bilo u Moskvi
> (trying my serbian here...)?)

Agreed. Sorry for disappearing. I've had connectivity problems in Moscow
-- it took me a couple of days to resolve (buying the new HDD,
reinstalling the system, finding out that upling port is also dead...).
After wasting so much time, no wonder I didn't have minute...

Love,
H

Re: list instead of vector [was: Re: [Mailsync-list] gcc 3.4.0]

[Michael 'h. K. <mai...@zz...>]

> On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:
> 
> > And, while we're at it... I just wondered why vector and not list? The
> > latter should be a bit more efficient when filling in initially and this
> > is mostly how mailsync works with these vectors.
> 
> Mhh - well, while were at that one could use "slist"s (single linked
> lists) - would work just as well. I'm accepting patches... ;-)

Got it ;-)

Love,
H

Re: [Mailsync-list] gcc 3.4.0

[Michael 'h. K. <mai...@zz...>]

On Mon, May 31, 2004 at 08:03:56PM +0200, Tomas Pospisek wrote:
> On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:
> 
> > Troubles compiling with gcc 3.4.0 seem to be related to gcc, not
> > mailsync. Here is the troublesome line:
> >
> > /usr/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_bvector.h:522:
> > error: `Max' is not a member of `std'
> >
> > 	      const size_type __len = size() + std::max(size(), __n);
> >
> > And here is the root of all evil:
> >
> > /usr/include/c-client/misc.h:#define max Max
> >
> > I have no clue if #undef after c-client.h would break it or not.  My
> > guess is not, because `grep 'max[[:space:]]*(' /usr/include/c-client/ -r` output:
> 
> Have you asked Mark about it yet, or checked the latest c-client if it's
> "fixed" there?

Of course not. Haven't asked, haven't checked, that is.

> > Doesn't look as if it's used in #defines. Although, if the patch
> > attached work (if I don't forget to attach it, that is), then, I think
> > the complaint should go to c-client instead, as this #undef would be
> > more suitable in c-client headers instead.
> 
> Um, well unless max is some reserved C/C++ keyword (I'm offline right now
> and can't check that) then I guess what we're seeing here is a plain
> namespace collision - both STL and c-client define "max" and so we end up
> in a mess. So unless one of either doesn't step back (STL probably won't,
> Mark might), we have to deal with it, either by undefining max after
> including c-client's headers or by not including STL's namespace
> ("using std::...").

one can't escape #define that easily. STL may define max, but it
definitely doesn't #define it.

> It could also be that it's a gcc's STL headers bug...

I don't think so. #defining things like max should inevitably lead to
problems...

Love,
H

[Mailsync-list] Re: mailsync 5.1.2 released ?

[Heiko R. <ro...@su...>]

On Tue, 1 Jun 2004, Tomas Pospisek wrote:

> Hallo Heiko,
> 
> On Tue, 1 Jun 2004, Heiko Rommel wrote:
> 
> > do I read it correctly that 5.1.2 is no release version ?
> 
> Yes, it's "only" a CVS snapshot ("make dist").
> 
> > If yes, what is missing for a release ?
> 
> synchronizing mh boxes is still lacking. :-/
> *t
> 

Is the issue concerning mh new to 5.1.2 in a way that sth changed that breaks
mh ?  Otherwise I'd like to check 5.1.2 in into our dist nevertheless. 5.1.2
has all the fixes that I proposed and many more.
However, I had to add

--- src/msgid.cc
+++ src/msgid.cc
@@ -81,7 +81,7 @@
         char addr[4096];
 
         if (envelope->date)
-          str = string(envelope->date);
+          str = string((char*)(envelope->date));
         if (envelope->subject)
           str += string(envelope->subject);
         if (envelope->message_id)


since the ENVELOPE definition in /usr/include/imap/mail.h changed a bit which broke gcc 3.3 with

-------------------
In file included from /usr/include/stdio.h:28,
                 from msgid.cc:2:
/usr/include/features.h:133:1: warning: this is the location of the previous definition
msgid.cc: In constructor `MsgId::MsgId(ENVELOPE*)':
msgid.cc:84: error: invalid conversion from `unsigned char*' to `const char*'
msgid.cc:84: error:   initializing argument 1 of `std::basic_string<_CharT, 
   _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = 
   char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
make[2]: *** [msgid.o] Error 1
make[2]: Leaving directory `/usr/src/packages/BUILD/mailsync-5.1.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/mailsync-5.1.1'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.13661 (%build)
----------------------
 
-- 
Heiko Rommel                             ro...@su...
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55

[Mailsync-list] Re: mailsync 5.1.2 released ?

[Tomas P. <tp...@so...>]

Hallo Heiko,

On Tue, 1 Jun 2004, Heiko Rommel wrote:

> do I read it correctly that 5.1.2 is no release version ?

Yes, it's "only" a CVS snapshot ("make dist").

> If yes, what is missing for a release ?

synchronizing mh boxes is still lacking. :-/
*t

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------

Re: [Mailsync-list] Re: mail sync question

[Tomas P. <tp...@so...>]

On Mon, 31 May 2004, Tomas Pospisek wrote:

> I've added this localy. It should get commited tomorrow.

Committed.
*t

--
-----------------------------------------------------------------------
     Tomas Pospisek
     http://sourcepole.com -   Linux & Open Source Solutions
------------------------------------------------------------------------

Re: [Mailsync-list] Re: mail sync question

[Tomas P. <tp...@so...>]

On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:

> On Tue, May 11, 2004 at 07:12:20PM +0200, Tomas Pospisek wrote:
> > On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:
> >
> > > > > > But it doesn't generate PACKAGE* macros in config.h which prevents
> > > > > > mailsync from compiling (unless you either
> > > > [...]
> > > > > Is there any way that configure could check the version of automake,
> > > > > and bomb out if it's too early?
> > > >
> > > > If there isn't an easy way, I'm just going to document that fact in the
> > > > README.
> > >
> > > It's easy to check automake --version output in autogen.sh, but... What
> > > are our exactl requiremenets? I'm totally lost now. autoconf 2.53 and
> > > automake 1.6?
> >
> > Akkana Peck reported success with automake 1.6, so that's what I've
> > commited to the README.
>
> I'd recommend this:
>
> Index: autogen.sh
> ===================================================================
> RCS file: /cvsroot/mailsync/mailsync/autogen.sh,v
> retrieving revision 1.2
> diff -u -r1.2 autogen.sh
> --- autogen.sh  17 Feb 2003 14:38:47 -0000      1.2
> +++ autogen.sh  11 May 2004 17:24:06 -0000
> @@ -1,4 +1,5 @@
>  #!/bin/sh
> +(automake --version | head -1 | grep -q ' 1\.[678]') || (echo "automake
> 1.6 or above is required";exit 1)
>  aclocal -I acinclude     && \
>  autoheader               && \
>  automake -a              && \

I've added this localy. It should get commited tomorrow.
*t

--
-----------------------------------------------------------------------
     Tomas Pospisek
     http://sourcepole.com -   Linux & Open Source Solutions
------------------------------------------------------------------------

Re: [Mailsync-list] gcc 3.4.0

[Tomas P. <tp...@so...>]

On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:

> Troubles compiling with gcc 3.4.0 seem to be related to gcc, not
> mailsync. Here is the troublesome line:
>
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_bvector.h:522:
> error: `Max' is not a member of `std'
>
> 	      const size_type __len = size() + std::max(size(), __n);
>
> And here is the root of all evil:
>
> /usr/include/c-client/misc.h:#define max Max
>
> I have no clue if #undef after c-client.h would break it or not.  My
> guess is not, because `grep 'max[[:space:]]*(' /usr/include/c-client/ -r` output:

Have you asked Mark about it yet, or checked the latest c-client if it's
"fixed" there?

> Doesn't look as if it's used in #defines. Although, if the patch
> attached work (if I don't forget to attach it, that is), then, I think
> the complaint should go to c-client instead, as this #undef would be
> more suitable in c-client headers instead.

Um, well unless max is some reserved C/C++ keyword (I'm offline right now
and can't check that) then I guess what we're seeing here is a plain
namespace collision - both STL and c-client define "max" and so we end up
in a mess. So unless one of either doesn't step back (STL probably won't,
Mark might), we have to deal with it, either by undefining max after
including c-client's headers or by not including STL's namespace
("using std::...").

It could also be that it's a gcc's STL headers bug...

Any expert here?
*t

--
-----------------------------------------------------------------------
     Tomas Pospisek
     http://sourcepole.com -   Linux & Open Source Solutions
------------------------------------------------------------------------

list instead of vector [was: Re: [Mailsync-list] gcc 3.4.0]

[Tomas P. <tp...@so...>]

On Tue, 11 May 2004, Michael 'hacker' Krelin wrote:

> And, while we're at it... I just wondered why vector and not list? The
> latter should be a bit more efficient when filling in initially and this
> is mostly how mailsync works with these vectors.

Mhh - well, while were at that one could use "slist"s (single linked
lists) - would work just as well. I'm accepting patches... ;-)
*t

--
-----------------------------------------------------------------------
     Tomas Pospisek
     http://sourcepole.com -   Linux & Open Source Solutions
------------------------------------------------------------------------

Re: [Mailsync-list] this looks curious (not selectable mailbox)

[Tomas P. <tpo...@so...>]

On Mon, 17 May 2004, Eric S. Johansson wrote:

> Michael 'hacker' Krelin wrote:
>
> >
> > Can you send more of config.log?
>
> see attached

So I see in the log that:

 configure:5232: checking for krb5-config
 configure:5241: result: not found
 [...]
 configure:5507: checking whether c-client built with kerberos gssapi support
 configure:5522: result: yes
 configure:5537: error: a working c-client installation is required for building mailsync

Which means that:

a) configure did not find a working kerberos installation
b) configure found out that c-client was built kerberos gssapi support

-> in order to link mailsync against c-client we need a working kerberos
   installation which we don't have here.

Am I correct? I guess that could be made clearer in the respective
acinclude file ac_with_cclient.m4. Instead of:

    if test "${need_krb}" = "yes" -a "${HAVE_KRB5_GSSAPI}" != "yes" ; then
     ifelse([$2], , :, [$2])
    else
     if test "${need_krb}" = "yes" ; then
      CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
     fi

we could write:


    if test "${need_krb}" = "yes"; then
     dnl
     dnl Checking if the necessary kerberos installation is available in
     dnl order to be able to link against c-client
     dnl
     AC_MSG_CHECKING([if the necessary kerberos installation is available in order to be able to link against c-client])
     if test "${HAVE_KRB5_GSSAPI}" = "yes"; then
      AC_MSG_RESULT([yes])
      CCLIENT_LIBS="${CCLIENT_LIBS} ${KRB5_GSSAPI_LIBS}"
     else
      AC_MSG_RESULT([no])
      ifelse([$2], , :, [$2])
     fi
    fi

is that correct? Michael? (Jak bilo v Moskve? Kako je bilo u Moskvi
(trying my serbian here...)?)
*t

--
-----------------------------------------------------------------------
     Tomas Pospisek
     http://sourcepole.com -   Linux & Open Source Solutions
------------------------------------------------------------------------

[Mailsync-list] Your Commission Statement and Stats

[Your S. <you...@ti...>]

Important Message to MY Downline,


I just received an urgent warning email from the accounts department of the
online business that you joined a few months back. They told me that you
have not yet confirmed acceptance of your last months stats or money earned.


If you don't do this immediately then not only will you miss being paid
out, it will also mean I don't get paid my over rides which will be very sad
as I am owed $12,152USD this month.

Please, simply visit this link and log into your account and accept your
stats statement and collect your earnings so I can get mine too. 

Please, click here: 
http://ftbb.captureform.biz/capture/ftbb/affiliates.htm



Many Thanks In Advance

Ken










Please note:
------------------------------------------------------------------------

This is an automatic email delivered to my downline via e-soft ware. If you
feel that I've breached your privacy or you would simply prefer not to
receive any further reminders, please click this link or copy this URL into
your browser>> http://ftbb.captureform.biz/capture/ftbb/removeme.htm and you
will be immediately and automatically unsubscribed from my downline list.

If this email has been received in error please accept my apologies.

Re: [Mailsync-list] this looks curious (not selectable mailbox)

[Eric S. J. <es...@ha...>]

Tomas Pospisek wrote:

> On Tue, 11 May 2004, Eric S. Johansson wrote:
> 
> 
>>Eric S. Johansson wrote:
>>
>>
>>>00000023 SELECT Archive
>>>00000023 NO SELECT failed: Can't open Archive: not a selectable mailbox
>>>Error: SELECT failed: Can't open Archive: not a selectable mailbox
>>>00000008 NOOP
>>>00000008 OK NOOP completed.
>>>[Reusing connection to 10.51.64.3/user="rjager"]
>>>00000009 SELECT Archive.DirectUpdate
>>>* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
>>>* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
>>>Flags permitted.
>>>* 0 EXISTS
>>>* 0 RECENT
>>>* OK [UIDVALIDITY 1084305556] UIDs valid
>>>* OK [UIDNEXT 1] Predicted next UID
>>>00000009 OK [READ-WRITE] Select completed.
>>>
>>>
>>>on one hand, it seems to barf on the higher level directory structure
>>>but then it seems to be able to access the actual mailbox.  Is
>>>transferring or is it totally confused?
>>
>>Archive/Inguide: [Reusing connection to 10.51.64.44/user="rjager"]
>>Error: SELECT failed: Can't open Archive: not a selectable mailbox
>>[Reusing connection to 10.51.64.3/user="rjager"]
>>[Mailbox is empty]
>>[Reusing connection to 10.51.64.44/user="rjager"]
>>
>>and after a while, it ceases to operate it appears.  The mailbox in
>>question is quite full and not corrupted.
>>
>>(knew I should have waited before posting)
> 
> 
> I'm not sure what you are trying to sync here. Could the problem be that
> you have differing directory structures? One mail store has got folders
> with messages /and/ subfolders whereas the other one doesn't support that
> concept or similar?
> *t

it's a simple hierarchy.  There is a folder called Archive which 
contains nothing but more folders which are mbx formatted mailboxes. 
So, Archive/Inguide refers to a specific mbx formatted mailbox.

I was hoping I could use one general template for moving user accounts 
of with varying mailbox hierarchies.  In the example that's failing, 
here's what I was using.

And by the way, when you simulate, why does it generate the mail boxes? 
  I will say though that it does interpret the hierarchy correctly and 
generate the right mailboxes on the destination side.  it just can't 
transfer anything.

store rjager.original {
         server {10.51.64.44/user=rjager/notls}
         ref {10.51.64.44}
         pat *
         passwd nsm
         }

store rjager.new {
         server {10.51.64.3/user=rjager/notls}
         ref {10.51.64.3}
         pat *
         passwd nsm
         }

channel generic.move rjager.original rjager.new {
         msinfo {10.51.64.3/user=rjager/notls}msinfo
         passwd nsm
}