mutt-kz March 2014

mutt-kz@lists.fedoraproject.org

3 participants
3 discussions

x509 error
by Ludwig 06 Mar '14

06 Mar '14

Forgive me if this is OT. For the past few days my IMAP connection has been dropping every twenty seconds or so. This is what .muttdebug0 ends with: [2014-03-05 11:43:29] 4> a0083 NOOP [2014-03-05 11:43:29] SSL error: error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table [2014-03-05 11:43:29] Connection to [mail.domain.tld] closed [2014-03-05 11:43:31] imap_cmd_step: Error reading server response. [2014-03-05 11:43:31] Mailbox closed I doubt it’s related to the recent GnuTLS bug because I compiled with OpenSSL instead. In case it’s any use: Compile options: -DOMAIN +DEBUG +HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_POP +USE_IMAP -USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME +EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE +NOTMUCH -MIXMASTER Is this even a mutt problem? I can’t think of anything relevant that changed lately. My system is Darwin [hostname] 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 Thanks.

1 2

Interesting mutt patches for mutt-kz
by Suvayu Ali 06 Mar '14

06 Mar '14

Hi everyone, Since mutt-kz aims toward more features than typical mutt, I was wondering if it would be possible to include the following patches. https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec665d… This patch lets you create mulitpart/alternative message parts in the compose screen. Here is a usage description by the author: > The <group-alternatives> binding for the componse menu (where you press > 's' to send) combines selected attachments into a multipart/alternative > group. The <move-up> and <move-down> bindings then allow you to change > their order. https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec665d… This patch allows regular expression based transformation of email subjects when displayed in the index. It can be useful to get rid of mailing list tags (e.g. [list-name]), or trim long subject lines. Caveat: I failed to apply the subjectrx patch some time back, but I did not attempt to fix it. Maybe it is possible with small changes. WDYT? -- Suvayu Open source is the future. It sets us free.

2 2

bug: [s]ave function adds bogus pathnames into the notmuch DB
by Selene Scriven 06 Mar '14

06 Mar '14

After updating to the latest mutt-kz in git, I noticed some strange behavior. I was getting weird results for folder-based queries. After some investigation, I narrowed it down to the [s]ave and purge functions in mutt-kz. I'm running git rev be196028c755d3ffff184e9781ac933fbacbd562 (Thu Jan 2 15:15:55 2014 +0100). Steps to reproduce the issue: - Open a virtual folder in mutt-kz. - [s]ave a message to a different Maildir. (original gets marked as [D]eleted) - Purge deleted messages. Mutt-kz then prints an error. It's a bit hard to catch before the screen redraws, but it looks like... "Writing notmuch://?query=(folder:INBOX or (... (...older:in...ror: A Xapian exception occurred flushing database: Can't commit during a transaction" At this point, I can query notmuch directly to see the broken pathname. 'notmuch search folder:$HOME' works, but I prefer this for more detail: > nm-files id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local === id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local === thread:000000000003ff58 Today 10:31 [1/1] H&R Block; Appointments available now – give us a call (unread) /home/selene/mail//home/selene/mail/receipts//new/1392149990.21796_1.mutt Messages: 1 After running 'notmuch new', the database updates by adding the correct pathname: > nm-files id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local === id:3f06c38c-d6f9-4c78-a27b-527d0c4352fd@xtinmta06.xt.local === thread:000000000003ff58 Today 10:31 [1/1] H&R Block; Appointments available now – give us a call (unread) /home/selene/mail//home/selene/mail/receipts//new/1392149990.21796_1.mutt /home/selene/mail/receipts/new/1392149990.21796_1.mutt Messages: 1 This gets weird if the message is ever moved again, because the broken pathname shows up forever unless the DB gets dumped, rebuilt from scratch, and restored (which takes ~3 hours for me). Notmuch never detects the error or removes the bogus path. For reference, here is the script I used above: > cat bin/local/nm-files #!/bin/sh # show the files associated with each message for a given search for ID in $( notmuch search --output=messages $* ); do echo "=== $ID ===" notmuch search --output=summary $ID notmuch search --output=files $ID echo done echo -n "Messages: " ; notmuch search $* | wc -l -- Selene

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

mutt-kz March 2014