unknown error with mbsync

[gnu.fo...@gmail.com]

Hello dear mu4e users.

I know, this is a mu4e discussion group and my question is concerning an mbsync error. But as mbsync is so widely used with mu4e as I did myself the last 3 years, I thought this wouldn't know of a better group.

I use mu4e with mbsync for 3 years now private and at work. My mbsyncrc file hasn't been changed since the first day.

But now I had a fresh Kubuntu 18.04 install on my private laptop. I compiled mbsync and mu4e as I did every time. But now when I try to issue the initial mbsync

mbsync -c ~/.emacs.d/.mbsyncrc posteo && mu index

the following errors occur:

/home/stefan/.emacs.d/.mbsyncrc:6: unknown/misplaced keyword 'SSLType'
/home/stefan/.emacs.d/.mbsyncrc:8: unknown/misplaced keyword 'CertificateFile'

Do I miss anything?

Thanks and greetings

Stefan

[Christophe Troestler]

Hi,

On 17 September 2018 at 18:36 GMT, gnu.fo...@gmail.com wrote:
>
> […] mbsync -c ~/.emacs.d/.mbsyncrc posteo && mu index

> the following errors occur:
> /home/stefan/.emacs.d/.mbsyncrc:6: unknown/misplaced keyword 'SSLType'
> /home/stefan/.emacs.d/.mbsyncrc:8: unknown/misplaced keyword 'CertificateFile'

You do not give much information about the version (1.3.0 or Git?) or about the structure of your file. In my case, I am using mbsync 1.3.0 and SSLType and CertificateFile are part of IMAPAccount.

Hope it helps,
C.

[gnu.fo...@gmail.com]

Hello Christophe,

I pulled isync/mbsync from GIT. My .mbsyncrc looks like this:

IMAPAccount posteo
Host posteo.de
User user@posteo.de
PassCmd "gpg -q --for-your-eyes-only --no-tty -d ~/.emacs.d/.mbsyncpass.gpg"
Port 993
SSLType IMAPS
AuthMechs Login
CertificateFile /etc/ssl/certs/ca-certificates.crt

IMAPStore posteo-remote
Account posteo

MaildirStore posteo-local
Path ~/Maildir/posteo/
Inbox ~/Maildir/posteo/INBOX

Channel posteo
Master :posteo-remote:
Slave :posteo-local:
Patterns "Sent" "INBOX" "Trash" "Drafts" "Archiv"
Create Slave
Sync All
Expunge Both
SyncState *

I hope this clears the fog a bit.

[Christophe Troestler]

Hi,

On 18 September 2018 at 04:17 GMT, gnu.fo...@gmail.com wrote:
>
> I pulled isync/mbsync from GIT. My .mbsyncrc looks like this:
>
> IMAPAccount posteo
> Host posteo.de

> User us...@posteo.de

> PassCmd "gpg -q --for-your-eyes-only --no-tty -d ~/.emacs.d/.mbsyncpass.gpg"
> Port 993
> SSLType IMAPS
> AuthMechs Login
> CertificateFile /etc/ssl/certs/ca-certificates.crt

I have the same kind of setting. Maybe you want to check out version 1.3.0 instead of the HEAD — and report an issue?

Best,
C.

[Yuri D'Elia]

I'm using the head from git, it works.

From the error, I suspect you're lacking the libssl-dev package.
Probably your build doesn't support SSL and the related config options.

Install libssl-dev and re-run configure/make.

[gnu.fo...@gmail.com]

Thanks all.

I had to install libssl-dev and libsasl2-dev and than reconfigure.

[Christophe Troestler]

On 20 September 2018 at 19:02 GMT, gnu.fo...@gmail.com wrote:
>
> Thanks all.
>
> I had to install libssl-dev and libsasl2-dev and than reconfigure.

Maybe you nonetheless want to open an issue for isync suggesting that an error message along the line “You cannot use 'SSLType' without compiling mbsync with SSL support” would be clearer?

Best,
C.

[Joe Corneli]

Hi, I moved to a new computer recently (Mac OS X 10.13.6) and notice
that Mu4e seems slower now than on my old computer (Ubuntu 17.10). In
particular, when I start Mu4e, fetch mail, and search for
date:1d..now, it says "Searching" for quite a while before the list of
mail appears. If I again fetch mail and do the same search, it's
faster than it was.

My guess: maybe indexing is slower for some reason?

This leads me to a quite simple idea: Is there an easy way to remove
old email from the local database, but not cause it to be deleted from
the server? If that's exactly what "mu remove" does, OK! But I
thought I should check. "mu help remove" gives a one-line summary
that sounds like it is the right thing, but I'm not 100% confident.

Joe

[Philipp Ittershagen]

Joe Corneli <holtze...@gmail.com> writes:

> Hi, I moved to a new computer recently (Mac OS X 10.13.6) and
> notice that Mu4e seems slower now than on my old computer
> (Ubuntu 17.10). In particular, when I start Mu4e, fetch mail,
> and search for date:1d..now, it says "Searching" for quite a
> while before the list of mail appears. If I again fetch mail
> and do the same search, it's faster than it was.

How many mails does this command match for you? Does it also take
that long when executed in a terminal? E.g. try running

$ time mu find date:1d..now

> This leads me to a quite simple idea: Is there an easy way to
> remove old email from the local database, but not cause it to be
> deleted from the server? If that's exactly what "mu remove"
> does, OK! But I thought I should check. "mu help remove" gives
> a one-line summary that sounds like it is the right thing, but
> I'm not 100% confident.

I suspect this removes the mail entry from the database, yes. But
the next run of "mu index" should re-populate the database again
with all the contents from the Maildir and the mail will appear
again in your search. Even if you manage to delete the mail from the database, I think
this is an ugly workaround to a potentially non-existent problem.

If you really want to limit indexing, I would consider subscribing
(and therefore indexing) only to a subset of the mailboxes on the
IMAP server. But you will need to configure your IMAP
synchronization software (isync/offlineimap) for that.


Philipp

[Joe Corneli]

On Fri, Sep 21, 2018 at 12:16 PM Philipp Ittershagen <p...@shgn.de> wrote:
>
>
> Joe Corneli <holtze...@gmail.com> writes:
>
> > Hi, I moved to a new computer recently (Mac OS X 10.13.6) and
> > notice that Mu4e seems slower now than on my old computer
> > (Ubuntu 17.10). In particular, when I start Mu4e, fetch mail,
> > and search for date:1d..now, it says "Searching" for quite a
> > while before the list of mail appears. If I again fetch mail
> > and do the same search, it's faster than it was.
>
> How many mails does this command match for you? Does it also take
> that long when executed in a terminal? E.g. try running
>
> $ time mu find date:1d..now

At the moment I got 186 messages that way. The query seemed quicker
in the terminal -- however I wasn't directly able to reproduce the
slow loading time in Emacs when I tried it just now!

sys 0m0.016s

In Emacs, via

(defmacro measure-time (&rest body)
"Measure the time it takes to evaluate BODY."
`(let ((time (current-time)))
,@body
(message "%.06f" (float-time (time-since time)))))

(measure-time (mu4e-headers-search-bookmark "date:1d..now"))

I got 0.003536.

I turned on logging, and in the *mu4e-log* buffer I found a big s-exp
containing all of my contacts. Maybe newer versions of mu4e are doing
more with contacts when retrieving mail than the old version?

(I trashed the old hard drive so I can't compare!)

> If you really want to limit indexing, I would consider subscribing
> (and therefore indexing) only to a subset of the mailboxes on the
> IMAP server. But you will need to configure your IMAP
> synchronization software (isync/offlineimap) for that.

I've done at in the past, but got lazy about it! I should
reconfigure accordingly.

[Eduardo Mercovich]

Hi Joe.

> [...] Is there an easy way to remove old email from the local
> database, but not cause it to be deleted from the server? [...]

Don't forget the .noupdate flag also, if that helps to quicker
indexing...


--
Eduardo Mercovich

Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.
(Anónimo)

[Joe Corneli]

Maybe this is a clue about the source of the time-sink. Is it easy to
get mu to return a a report similar to these when I run
"mu4e-update-mail-and-index"?

$ mu index
indexing messages under /Users/joe/Maildir [/Users/joe/.mu/xapian]
| processing mail; processed: 21375; updated/new: 0, cleaned-up: 0
cleaning up messages [/Users/joe/.mu/xapian]
- processing mail; processed: 21409; updated/new: 0, cleaned-up: 26
elapsed: 24 second(s), ~ 892 msg/s
\ processing mail; processed: 21409; updated/new: 0, cleaned-up: 26
elapsed: 25 second(s), ~ 856 msg/s

Immediately after:

$ mu index
indexing messages under /Users/joe/Maildir [/Users/joe/.mu/xapian]
| processing mail; processed: 21375; updated/new: 0, cleaned-up: 0
cleaning up messages [/Users/joe/.mu/xapian]
- processing mail; processed: 21383; updated/new: 0, cleaned-up: 0
elapsed: 1 second(s), ~ 21383 msg/s
\ processing mail; processed: 21383; updated/new: 0, cleaned-up: 0
elapsed: 2 second(s), ~ 10691 msg/s

> --
> You received this message because you are subscribed to the Google Groups "mu-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Dirk-Jan C. Binnema]

On Thursday Sep 27 2018, Joe Corneli wrote:

> Maybe this is a clue about the source of the time-sink. Is it easy to
> get mu to return a a report similar to these when I run
> "mu4e-update-mail-and-index"?
>
> $ mu index
> indexing messages under /Users/joe/Maildir [/Users/joe/.mu/xapian]
> | processing mail; processed: 21375; updated/new: 0, cleaned-up: 0
> cleaning up messages [/Users/joe/.mu/xapian]
> - processing mail; processed: 21409; updated/new: 0, cleaned-up: 26
> elapsed: 24 second(s), ~ 892 msg/s
> \ processing mail; processed: 21409; updated/new: 0, cleaned-up: 26
> elapsed: 25 second(s), ~ 856 msg/s
>
> Immediately after:
>
> $ mu index
> indexing messages under /Users/joe/Maildir [/Users/joe/.mu/xapian]
> | processing mail; processed: 21375; updated/new: 0, cleaned-up: 0
> cleaning up messages [/Users/joe/.mu/xapian]
> - processing mail; processed: 21383; updated/new: 0, cleaned-up: 0
> elapsed: 1 second(s), ~ 21383 msg/s
> \ processing mail; processed: 21383; updated/new: 0, cleaned-up: 0
> elapsed: 2 second(s), ~ 10691 msg/s

At least on Linux, the seconds is expected to be much faster, since the
kernel caches many things during the first round.

If it's much faster when you were using Ubuntu, the problem's likely to
be something Mac specific... perhaps the file-system or something else.

From an earlier comment:
,----
| This leads me to a quite simple idea: Is there an easy way to remove

| old email from the local database, but not cause it to be deleted from

| the server? If that's exactly what "mu remove" does, OK! But I
| thought I should check. "mu help remove" gives a one-line summary
| that sounds like it is the right thing, but I'm not 100% confident.

`----

mu cleanup removes messages from the database for which there are
no longer corresponding files in the file system.

mu doesn't know anything about remote servers; that's done by mbsync or
offlineimap or .... mu4e (not mu) can ask these programs to do their
thing, but that's about as far as the integration goes.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C