Re: listing all the tags I've been using

2020-11-20 Thread Ralph Seichter
* Kim Minh Kaplan:

> notmuch search --output=tags '*'

That's much nicer than my idea. Thanks.

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: listing all the tags I've been using

2020-11-20 Thread Ralph Seichter
* Alan Schmitt:

> I'm trying to document the tags I'm using for notmuch [...]

The following should get you started (untested, from memory):

  notmuch dump | gawk -F '--' '{print $1}' | sort -u

Feel free to add some more AWK magic instead of the "sort -u" to
group/count by tag name.

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Clashes between "version" files and C++ keyword

2020-10-28 Thread Ralph Seichter
Building Notmuch on macOS is known to cause problems because the Notmuch
distribution archive contains two files named "version". These clash
with the  keyword as defined in C++20 [1] and will likely
become obvious on other platforms as well once Compilers adopt the new
standard.

The two affected files in the Notmuch Git tree are

  /bindings/python-cffi/version
  /version

I suggest to rename them both to version.txt. The attached patch can
then be applied to make the necessary build file changes.

-Ralph

[1] https://en.cppreference.com/w/cpp/20#New_headers

diff --git Makefile.global Makefile.global
index cd489ef2..8477468d 100644
--- Makefile.global
+++ Makefile.global
@@ -17,7 +17,7 @@ else
 DATE:=$(shell date +%F)
 endif
 
-VERSION:=$(shell cat ${srcdir}/version)
+VERSION:=$(shell cat ${srcdir}/version.txt)
 ELPA_VERSION:=$(subst ~,_,$(VERSION))
 ifeq ($(filter release release-message pre-release update-versions,$(MAKECMDGOALS)),)
 ifeq ($(IS_GIT),yes)
diff --git Makefile.local Makefile.local
index c65cee7c..dde7981b 100644
--- Makefile.local
+++ Makefile.local
@@ -19,7 +19,7 @@ endif
 
 # Depend (also) on the file 'version'. In case of ifeq ($(IS_GIT),yes)
 # this file may already have been updated.
-version.stamp: $(srcdir)/version
+version.stamp: $(srcdir)/version.txt
 	echo $(VERSION) > $@
 
 $(TAR_FILE):
diff --git bindings/python-cffi/setup.py bindings/python-cffi/setup.py
index b0060835..cda52338 100644
--- bindings/python-cffi/setup.py
+++ bindings/python-cffi/setup.py
@@ -1,6 +1,6 @@
 import setuptools
 
-with open('version') as fp:
+with open('version.txt') as fp:
 VERSION = fp.read().strip()
 
 setuptools.setup(
diff --git doc/conf.py doc/conf.py
index 94e266af..11bed51d 100644
--- doc/conf.py
+++ doc/conf.py
@@ -19,7 +19,7 @@ copyright = u'2009-2020, Carl Worth and many others'
 location = os.path.dirname(__file__)
 
 for pathdir in ['.', '..']:
-version_file = os.path.join(location,pathdir,'version')
+version_file = os.path.join(location,pathdir,'version.txt')
 if os.path.exists(version_file):
 with open(version_file,'r') as infile:
 version=infile.read().replace('\n','')
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Dependencies should include "realpath"

2020-10-20 Thread Ralph Seichter
* Tomi Ollila:

>> rsti_dir = os.path.abspath('emacs')
>
> Good suggestion, anyway, the simplest change would be just:
>
> -  printf "rsti_dir = '%s'\n" $(realpath emacs)
> +  printf "rsti_dir = '%s'\n" $(cd emacs && pwd -P)

Looks like "pwd -P" is part of the Open Group base spec for pwd, so it
should be available on supported platforms.

> Then, just for the record, I think open(rsti_dir+'/'+file) is fine,
> and I don't see it failing on any imaginable system notmuch work
> (now?;)

As they say, you have the right to your opinion. ;-) I don't think it is
"fine" at all. While rsti_dir+'/'+file may work, depending on the
platform used, os.path.join(rsti_dir, file) *will* work.

Quoting Python's "os" description, first sentence: "This module provides
a portable way of using operating system dependent functionality." I see
no viable reason not to use "os".

> I am even personally changing some os.path.join(...) commands to use
> that concatenation instead, just to reduce complexity and line count
> elsewhere...

I am sorry to hear that. There is nothing complex about using os.path,
and as far as I am concerned, correctness and ease of maintenance beats
a reduced line count every single time.

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Dependencies should include "realpath"

2020-10-17 Thread Ralph Seichter
* David Bremner:

> I'm not sure what an "overhaul" would involve.

Looking at conf.py, I find the following confusing:

  lines = ['.. include:: /../emacs/rstdoc.rsti\n\n'] # in the source tree
  for file in ('notmuch.rsti', 'notmuch-lib.rsti', 'notmuch-show.rsti', 
'notmuch-tag.rsti'):
  lines.extend(open(rsti_dir+'/'+file))
  rst_epilog = ''.join(lines)
  del lines

"lines" is of type List[str]. In a loop which uses "file" (a reserved
expression), open() returns file handles on success. The string (!) list
is then extended with file handles, and after the loop, members of the
list (one string, n file handles) are concatenated using an empty string.
What is the reasoning behind this code segment?

As for generating a config file with configure and then reading and
executing individual lines from Python: Why not write to doc/dyncf.py 
and use "from .dyncf import tags, rsti_dir" in conf.py?

Maybe I am off on a tangent, though. It would help me if I knew what
problem you were actually trying to solve?`

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Dependencies should include "realpath"

2020-10-16 Thread Ralph Seichter
* David Bremner:

> Do you have a suggested replacement? I guess some inline perl with "use
> Cwd 'realpath'" would probably work, although I haven't tested it.

At a quick glance, that particular section of "configure" is run by
doc/conf.py to generate three lines of Python code and store the result
as sphinx.config, correct? If so, my preferred choice would be to use
Python to figure out the absolute path, e.g. like so:

  rsti_dir = os.path.abspath('emacs')

This shows the generated result, and I assume that emacs is a directory
in the source tree? I also wonder if an absolute directory path is really
required for the doc-build to work.

The segment of conf.py which uses the generated config file does not
look convincing to me anyway. Apparently the original author did not
like it either, which is why the segment is labelled as "hacky". It
should probably be overhauled, and not only because it uses the
statement open(rsti_dir+'/'+file) which will potentially fail, depending
on the build platform.

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Dependencies should include "realpath"

2020-10-16 Thread Ralph Seichter
Since this issue just came up related to my MacPorts port: The list of
dependencies for notmuch should include "realpath". configure [1] relies
on realpath to generate the value for rsti_dir.

[1] 
https://git.notmuchmail.org/git?p=notmuch;a=blob;f=configure;h=40e8b2559e86b40985ef2c6dc142eb0104c3ddb6;hb=45193bab16c728ba892a5d45fc62ef59e2a6ef85#l1539

While Linux usually comes with realpath included, macOS does not, and
I am not quite sure about BSD variants.

-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] completion: remove "setup" from the list of possible completions

2020-06-23 Thread Ralph Seichter
* Tomi Ollila:

> You're wrong and I am right... ;)

"I'm sorry, if you were right, I would agree with you." (Dr. M. Sayer) :-)

> note that I also have no notmuch-* commands in my PATH, so 'notm'
> expands to 'notmuch ' ! \o/ FTW ;)

I like aliases like "nme" for "Notmuch in Emacs".

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] completion: remove "setup" from the list of possible completions

2020-06-20 Thread Ralph Seichter
* Tomi Ollila:

> imo.the completions should primarily provide convenience to the
> interactive user, to see all possible options (also those
> seldomly.used) one can use help and namual pages...

"Can use" being the operative term, not "should have to use". I would
not want completion to omit certain commands, based on somebody else's
notion of what is convenient, which in turn forces me to use other means
of figuring out a seldom-used command I may or may not be aware of.

If this means entering three characters instead of two, then three
characters it is. Alternatively, make it a configurable option, with
"convenient=false" being the default. I vote against the change.

First world problems... ;-)

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Python 3.x bindings support which versions, exactly?

2020-05-24 Thread Ralph Seichter
* David Bremner:

> That's another reason for me to get a release out the door soon.

Given how long ago the old Python bindings were written, I can wait a
bit longer for the improved version. ;-) Still, I am looking forward to
the next Notmuch release.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Python 3.x bindings support which versions, exactly?

2020-05-24 Thread Ralph Seichter
* David Bremner:

> The new bindings (modulename= notmuch2) should work with any python
> recent 3.x. They still have a few rough edges afaiu, but definitely
> new projects should target the new bindings.

Alas, there are no release archives available yet which contain the new
bindings. I was hoping to add Python 3.8 support for the Gentoo Linux
package I maintain, but our ebuilds rely on tagged releases of the
packaged software.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Python 3.x bindings support which versions, exactly?

2020-05-24 Thread Ralph Seichter
Hello,

having examined the source code, I assume that Notmuch's Python bindings
should support Python 3.x for any given 'x'. However, reading the Travis
logs at https://travis-ci.org/notmuch/notmuch and .travis.yml, the CI
tests apparently run on Ubuntu 18.04 and use only Python 3.6.

While I hope there won't be any problems with Python 3.7, 3.8 and 3.9,
I wanted to ask here first if anybody has tested this yet?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: How to use notmuch on several devices

2020-02-29 Thread Ralph Seichter
* moonmaill...@firemail.cc:

> I just wonder, how to keep the inboxes the same/in sync and export/
> import notmuch configuration and how to use it on a new device?

Personally, I find http://www.muchsync.org useful for this task.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Attach public key and encrypt by default

2019-12-17 Thread Ralph Seichter
* Carolyn Knight-Serrano:

> would it be possible to add or configure in support for automatically
> adding your gpg public key to messages?

As already mentioned, adding several KB of GPG key to the body of each
of your messages would be very impolite, and it might get you flagged as
a spammer.

A possible alternative is Autocrypt (https://autocrypt.org/) which uses
the message header, but the most bandwidth-friendly method is still a
URL pointing to your self-hosted key material. Also there are publicly
available key servers like http://pgp.mit.edu , with their own pros and
cons.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Syncing of IMAP accounts

2019-12-16 Thread Ralph Seichter
* Nicolas Bock:

> I am using offlineimap to sync my email for use with notmuch.

Try muchsync (http://www.muchsync.org) instead.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Workaround for Exchange-corrupted PGP/Mime structure

2019-11-20 Thread Ralph Seichter
* Carl Worth:

> What would anyone think about a workaround where notmuch-emacs could
> grub around inside a "multipart/mixed" structure looking for child
> parts that look like they really should have been a part of a
> "multipart/encrypted" container?

Personally, I see no reason to spend any effort in Notmuch to fix
whatever Exchange has screwed up this week. Microsoft has more than
enough resources to clean up their own messes, don't you think?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch, Emacs and pinentry -- oh my

2019-11-13 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> This hypothetical subcommand would just protect the index. [...] you
> will be able to read your mail without access to your long-term secret
> key material [...]

That sounds useful, as does the idea of (un)locking the index. As you
may have seen on the GnuPG mailing list, I have not yet cracked the nut
of pass phrase input in Emacs.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch, Emacs and pinentry -- oh my

2019-11-11 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> Have you considered running gpg-agent in a dedicated terminal window,
> and handling the gpg-agent prompts from that window?

I tried that by setting GPG_TTY to a fixed terminal, but while this
seemed to work on the first call, the second time I was prompted for a
password it was echoed, in cleartext, to the terminal. Is there a better
method to achieve what you proposed?

> To be clear about your threat model here: [...]

Barring break-ins, nobody but me is logging in on that particular
server, so intercepting gpg-agent would be difficult. Access to the
Notmuch index would not be any easier, unless somebody physically
removed the hard drives.

The lock/unlock operations to seems interesting, and, if it was based on
strong encryption, I would feel more comfortable. Are you thinking of
protecting just the index or the whole Maildir store? The latter would
not work for me, because Dovecot needs to access the data, and if only
the index is protected, I'd still need to decrypt messages within Emacs.

Currently, decryption happens in whatever MUA I am using at that time,
i.e. mostly Notmuch/Emacs and alternatively Thunderbird/Enigmail.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch, Emacs and pinentry -- oh my

2019-11-08 Thread Ralph Seichter
* David Bremner:

> My only (not always popular advice) w.r.t. pinentry is to use a
> graphical pinentry if at all possible.

I only access the server with a terminal, and that's where Emacs is
running in. Curses is as graphical as it gets. ;-)

> Not all Emacs binaries have support for emacs-pinentry built
> in. Reading gpg passphrases (or root passwords) into the same
> emacs as runs a mail or irc client makes me nervous personally [...]

See https://www.gnu.org/software/emacs/news/NEWS.26.1, section "The
pinentry.el library has been removed.", remarks about minibuffer
vs. graphical pinentry programs.

I have tried 'epa-pinentry-mode' with both loopback and nil, and I tried
both with and without 'allow-emacs-pinentry' in gpg-agent.conf. It does
not seem to make a difference what I try, though.

As for the nuclear option of decoding on indexing: That worries me more
than using Emacs with some form of pinentry and gpg-agent.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Notmuch, Emacs and pinentry -- oh my

2019-11-07 Thread Ralph Seichter
Not being quite sure if this is the correct mailing list to ask, here we
go anyway:

Using Emacs as a Notmuch client, I occasionally come across email that
is signed and/or encrypted. I am then prompted to a) decide if I trust
the signator or b) to enter my PGP secret key's password.

Alas, in these cases I can tell that Emacs expects input of me, but it
only uses the bottom most two lines to do so, meaning that I cannot
quite read what is expected of me. Assuming that pinentry is involved, I
tried switching between pinentry-curses and pinentry-tty in my shell
profile, but the result is unreadable in both cases. If I use commands
like "pgp -d ..." in the shell, both pinentry variants work fine (in the
case of curse, the prompt is smack in the middle of my terminal window,
as expected).

I have enabled 'allow-emacs-pinentry' in my gpg.conf, but that does not
resolve the issue either, so I would be grateful for advice. Thanks.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Missing in 0.29.2 notmuch-dump.c: Fix output file being closed twice

2019-10-24 Thread Ralph Seichter
* David Bremner:

> That push was pushed to master, but not release. I guess at the time
> it didn't seem serious enough to warrant a point release?

I did not expect a point release for that patch in particular. However,
given that the patch fixed a SIGABRT situation, I have assumed to see it
included in whatever release came next. Version 0.29.2 happens to be the
first release since the bugfix was accepted three months ago, hence my
moderate disappointment that the fix is missing.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Missing in 0.29.2 notmuch-dump.c: Fix output file being closed twice

2019-10-23 Thread Ralph Seichter
Folks,

On July 23, in message <20190723203002.31110-1-ab...@monksofcool.net>,
I submitted a patch that appears to be missing from release 0.29.2.
In <87ef2frw15@tethera.net> David Bremner wrote that the fix was
supposed to be pushed, so I am a bit confused.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Indentation style

2019-07-30 Thread Ralph Seichter
* Tomi Ollila:

> I like mixed tabs and spaces. for example cursor moves faster...

If that's the case, you're just not using the right keys to move around
the source code. :-) In Vim, keys like W/B, +/- etc. ignore whitespaces
anyway, and Emacs has equivalents. Rumour has it there are other editors
out in the wild, but then, some people believe anything... ;-)

I am aware this is a sensitive subject, but looking at the last 35+
years, I personally found that the only reliable way to avoid whitespace
related hassle is to stick to spaces only. I am not in a position to
decide this, of course, but I am glad that Python [1] even comes with a
command line option which turns mixed indentation into errors, making it
easy to spot these situations.

-Ralph

[1] https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Indentation style (was: [PATCH] notmuch-dump.c: Fix output file being closed twice)

2019-07-28 Thread Ralph Seichter
* David Bremner:

> I did have to revert one unrelated whitespace change.

I knew I might run afoul of that the minute I read "Indent is 4 spaces
with mixed tab/spaces and a tab width of 8" in the code style notes. ;-)

In my experience, it is error-prone to mix tabs and spaces. Perhaps it
would be useful to change to all spaces? Also, with an added editor mode
line, supporting that style would be more convenient (for Emacs and Vim
at least).

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] notmuch-dump.c: Fix output file being closed twice

2019-07-23 Thread Ralph Seichter
Fixed: If the output file for a dump was non-writeable, gzclose_w()
was called twice on the output file handle, resulting in SIGABRT.
---
 notmuch-dump.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/notmuch-dump.c b/notmuch-dump.c
index 505c1469..ca73d003 100644
--- a/notmuch-dump.c
+++ b/notmuch-dump.c
@@ -329,13 +329,15 @@ notmuch_database_dump (notmuch_database_t *notmuch,
}
 }
 
-if (gzclose_w (output) != Z_OK) {
+ret = gzclose_w (output);
+if (ret) {
fprintf (stderr, "Error closing %s: %s\n", name_for_error,
 gzerror (output, NULL));
ret = EXIT_FAILURE;
-   output = NULL;
+output = NULL;
goto DONE;
-}
+} else
+output = NULL;
 
 if (output_file_name) {
ret = rename (tempname, output_file_name);
-- 
2.21.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] notmuch-dump.c: Fix output file being closed twice (V2)

2019-07-23 Thread Ralph Seichter
This is version 2 of the patch, sorry for that. I had sent an older
version by mistake.

-Ralph


___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] notmuch-dump.c: Fix output file being closed twice

2019-07-23 Thread Ralph Seichter
Fixed: If the output file for a dump was non-writeable, gzclose_w()
was called twice on the output file handle, resulting in SIGABRT.
---
 notmuch-dump.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/notmuch-dump.c b/notmuch-dump.c
index 505c1469..78282661 100644
--- a/notmuch-dump.c
+++ b/notmuch-dump.c
@@ -329,11 +329,12 @@ notmuch_database_dump (notmuch_database_t *notmuch,
}
 }
 
-if (gzclose_w (output) != Z_OK) {
+ret = gzclose_w (output);
+output = NULL;
+if (ret) {
fprintf (stderr, "Error closing %s: %s\n", name_for_error,
 gzerror (output, NULL));
ret = EXIT_FAILURE;
-   output = NULL;
goto DONE;
 }
 
-- 
2.21.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: SIGABRT if "notmuch dump" output file is not writeable

2019-07-23 Thread Ralph Seichter
* David Bremner:

> that's a message / abort from deep within libz. So odds of our being
> able to fix it are pretty small.

Based on a quick glance on notmuch_database_dump() in notmuch-dump.c, it
seems to me that SIGABRT occurs in line 351:

  350: if (ret != EXIT_SUCCESS && output)
  351:   (void) gzclose_w (output);

gzclose_w(output) has already been called in line 332, before Notmuch
attempts to rename the temp file to the output file. At that point,
'output' should be set to null as it is being checked later, but that
erroneously only happens in case the close operation fails.

The rename in line 341 fails because of permission/ownership issues,
'ret' contains the error code for that, 'output' is still non-null, so
gzclose_w is called again -- ergo boom.

I have not tested or debugged this so far, it is just a Mark-I-Eyeball
analysis. I think I got it right, though. If you agree, I can provide a
fix, which I will actually test.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: SIGABRT if "notmuch dump" output file is not writeable

2019-07-22 Thread Ralph Seichter
* David Bremner:

> I agree it's a bit ugly to look at.

Ah, euphemisms. ;-) Personally, I associate "double free or corruption
(!prev)" with memory trouble or situations where a library cannot
recover from an error state and needs to bail out using abort(). Not
being able to (over)write an existing file is not that serious, IMO.

> Do you see any database corruption or more serious issues?

No, and I don't expect any, as I am assuming that "notmuch dump" will
only ever read the DB.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Bug: SIGABRT if "notmuch dump" output file is not writeable

2019-07-22 Thread Ralph Seichter
This is what happens when calling "notmuch dump" (version 0.29.1) with
an output file that is not writeable (tested with FISH and BASH):

  root > touch /tmp/out
  root > ls -l /tmp/out
  -rw-r--r-- 1 root root 0 Jul 22 20:36 /tmp/out

  nonroot > notmuch dump --output=/tmp/out
  Error renaming /tmp/out.kuZ9t5 to /tmp/out: Operation not permitted
  double free or corruption (!prev)
  fish: “notmuch dump --output=/tmp/out” terminated by signal SIGABRT (Abort)

While it is understood that Notmuch cannot write to the specified output
file, I don't think this should result in something as harsh as SIGABRT.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Notmuch support for GnuPG Web Key Directory

2019-07-10 Thread Ralph Seichter
You may have followed a recent discussion on the GnuPG mailing list
regarding poisoned keys on SKS key servers, and possible alternatives.

I have set up a Web Key Directory (see https://wiki.gnupg.org/WKD),
which is easy to do, and now I am wondering about Notmuch support for
WKD. Has anybody considered this, and perhaps even compiled a list of
necessary steps to implement it?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 2/2] test: replace use of gdb with LD_PRELOAD shims in T070-insert.sh

2019-06-24 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> Do you think we could go ahead and apply these patches on master now
> anyway, and fix them up subsequently to make sure they apply to MacOS?

I still have not been able to set up any macOS based tests, because
contractual work has kept me busy. I suggest you go ahead with the
changes, and should I run into any unexpected issues in future builds,
I'll speak up. I don't want to slow you folks down.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] configure: fix mktemp call for macOS

2019-06-16 Thread Ralph Seichter
Add missing template to mktemp, as required by macOS / OS X.

Signed-off-by: Ralph Seichter 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 8b80f0e0..6e73b22e 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
 return 0;
 }
 EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX"); then
 printf 'No.\nCould not make tempdir for testing session-key support.\n'
 errors=$((errors + 1))
 elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c 
${gmime_ldflags} -o _check_session_keys \
-- 
2.22.0

(This obsoletes id:87r27z63uk@ra.horus-it.com)
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] configure: fix mktemp call for macOS

2019-06-15 Thread Ralph Seichter
* Tomi Ollila:

> First, it would be better if
>
> TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX")
>
> worked, then the behaviour on Linux would not change.

I'm trying to figure out if I can override $TMPDIR during the MacPorts
configure phase. According to the documentation, modifying environment
variables should work, but I am not quite there yet.

Corollary: I suggest we go for the method shown above for the time
being. I am not a fan of hardcoding paths either.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] configure: fix mktemp call for macOS

2019-06-14 Thread Ralph Seichter
* David Bremner:

> TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX")
>
> (borrowed from test/test-lib.sh). This avoids hardcoding the temporary
> directory.

I had the same thought at first, but I want to ensure that the path
length does not cause trouble anymore.

  > uname -v
  Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; 
root:xnu-4903.261.4~2/RELEASE_X86_64
  > echo $TMPDIR
  /var/folders/m_/w5lk3r_1495dhnl4l0s96pr0gn/T/

That's my MacBook Pro with macOS 10.14.5 (Mojave). AFAIK, older versions
can have longer names. Also, I am concerned with accumulating clutter.

  > grep clean_tmps_dirs /etc/defaults/periodic.conf
  daily_clean_tmps_dirs="/tmp"

The /tmp directory will, with default settings, be cleaned periodically
by the OS, while $TMPDIR (which is user-specific) will not.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] configure: fix mktemp call for macOS

2019-06-11 Thread Ralph Seichter
The mktemp call in configure is incompatible with /usr/bin/mktemp as
shipped with macOS, where it fails due to a missing parameter. I added
the missing template, and the call is now working with both Apple's
and GNU coreutils' mktemp.

Signed-off-by: Ralph Seichter 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 8b80f0e0..feebafcc 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
 return 0;
 }
 EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d /tmp/notmuch.XX); then
 printf 'No.\nCould not make tempdir for testing session-key support.\n'
 errors=$((errors + 1))
 elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c 
${gmime_ldflags} -o _check_session_keys \
-- 
2.21.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] doc: Makefile: stop build notmuch-emacs.info when not have emacs

2019-06-11 Thread Ralph Seichter
* Doan Tran Cong Danh:

> I don't know if this is a _good_ fix for this issue.

Did you see id:20190611005024.22814-2-da...@tethera.net ?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Ye olde Apple mktemp

2019-06-10 Thread Ralph Seichter
* Ralph Seichter:

> The following local patch solves the issue for me [...]

Well, it does solve the mktemp call failing due to a missing
parameter. There is however additional fun [1] to be had once mktemp
succeeds:

-snip-
Checking for GMime session key extraction support... gpg: can't connect to the 
agent: File name too long
gpg: error getting the KEK: No agent running
gpg: error reading '[stdin]': No agent running
gpg: import from '[stdin]' failed: No agent running
No.
*** Error: Could not extract session keys from encrypted message.

This is likely due to your GMime having been built against a old
version of GPGME.

Please try to rebuild your version of GMime against a more recent
version of GPGME (at least GPGME 1.8.0).
Your current GPGME development version is: 1.13.0-unknown
-snip-

I found a GNUPGHOME length limit mentioned in a Debian bug [2] and other
places; looks like the Notmuch build is running into that limit. That
configure does not regcognize GPGME 1.13.0 is of course only a minor
issue, but the GnuPG error breaks the build.

-Ralph

[1] 
https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/88616/steps/install-port/logs/stdio
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 2/2] test: replace use of gdb with LD_PRELOAD shims in T070-insert.sh

2019-06-10 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> Perhaps Ralph Seichter (explicitly cc'ed above) could comment on how
> it'll affect homebrew?

MacPorts, actually. ;-) I have not yet been able to look into this patch
series, but I hope to be able to do so soonish.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Ye olde Apple mktemp

2019-06-10 Thread Ralph Seichter
Another quirk that occurs during the configuration phase on older macOS
versions (when they were still called OS X, actually) in the MacPorts
build farm:

  Checking for GMime session key extraction support...
  usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
 mktemp [-d] [-q] [-u] -t prefix
  No.

Hooray for that ancient mktemp binary. :-/ The following local patch
solves the issue for me:

diff --git a/configure b/configure
index 8b80f0e0..fa715946 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
 return 0;
 }
 EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d -t /tmp); then
 printf 'No.\nCould not make tempdir for testing session-key support.\n'
 errors=$((errors + 1))
 elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c 
${gmime_ldflags} -o _check_session_keys \

Alas, "mktemp -d -t /tmp" is incompatible with GNU coreutils' mktemp,
while "mktemp -d -p /tmp" is not understood by Apple's variant because
of the "-p". I don't know what syntax would be universally acceptable.

Is there a way to pass platform-dependent parameters to mktemp with the
current build mechanics?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build

2019-06-09 Thread Ralph Seichter
MacPorts CI builds were successful as well. Thank you for the prompt
fix, David.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build

2019-06-09 Thread Ralph Seichter
* David Bremner:

> Attempt #2; we need to delay expansion of INFO_TEXI_FILES until
> WITH_EMACS is defined.

Works nicely for my local builds. Now I need to wait for the CI builds
to run.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build

2019-06-09 Thread Ralph Seichter
* David Bremner:

> The following seems to fix the problem, but I haven't tested it
> extensively.

As shown in https://monksofcool.net/tmp/6bmjUFL.log , your suggestion
results in notmuch-emacs.info being generated but unfortunately not
installed when Notmuch is built --with-emacs. Obviously that's better
than a build failure for --without-emacs, but it is not quite ideal
either. ;-)

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Bug: Attempt to install notmuch-emacs.info during --without-emacs build

2019-06-09 Thread Ralph Seichter
MacPorts CI builds report the following [1]:


DEBUG: system:  cd 
"/opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/notmuch-0.29"
 && ./configure --prefix=/opt/local --with-docs --without-emacs --without-ruby
[...]
Checking if emacs (>= 24) is available... No (so will not byte-compile emacs 
code)
[...]
/opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/notmuch-0.29/doc/index.rst:7:
 WARNING: toctree contains reference to excluded document 'notmuch-emacs'
WARNING: "texinfo_documents" config value references unknown document 
notmuch-emacs
[...]
install -m0644 doc/_build/texinfo/notmuch-address.info 
doc/_build/texinfo/notmuch-compact.info doc/_build/texinfo/notmuch-config.info 
doc/_build/texinfo/notmuch-count.info doc/_build/texinfo/notmuch-dump.info 
doc/_build/texinfo/notmuch-emacs-mua.info 
doc/_build/texinfo/notmuch-insert.info doc/_build/texinfo/notmuch-new.info 
doc/_build/texinfo/notmuch-reindex.info doc/_build/texinfo/notmuch-reply.info 
doc/_build/texinfo/notmuch-restore.info doc/_build/texinfo/notmuch-search.info 
doc/_build/texinfo/notmuch-show.info doc/_build/texinfo/notmuch-tag.info 
doc/_build/texinfo/notmuch.info doc/_build/texinfo/notmuch-hooks.info 
doc/_build/texinfo/notmuch-properties.info 
doc/_build/texinfo/notmuch-search-terms.info 
doc/_build/texinfo/notmuch-emacs.info 
/opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/destroot/opt/local/share/info
install: doc/_build/texinfo/notmuch-emacs.info: No such file or directory
make: *** [install-info] Error 71


Why is the build trying to install texinfo/notmuch-emacs.info even
though --without-emacs was specified during configuration and Emacs was
not found during the sanity checks?

[1] Full build log available at https://paste.z0k.xyz/8352cabdee6f.txt

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch release 0.29 now available

2019-06-07 Thread Ralph Seichter
* David Bremner:

> Yes, there was a brief discussion [...]

Thanks. As I expected, it was my lack of attention that led to me being
caught unawares. ;-)

> I guess xz compression is something packagers will have to deal with.

Of course, no worries. I am not miffed in any way, especially because it
only amounts to adding a single option to my Portfile. I just wanted to
make sure this was deliberate on your end before I open my pull request.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch release 0.29 now available

2019-06-07 Thread Ralph Seichter
* David Bremner:

> https://notmuchmail.org/releases/notmuch-0.29.tar.xz

As the maintainer of Notmuch in MacPorts, I wonder why you chose to
switch from a classical tarball to a .tar.xz archive? Did I miss some
discussion on this mailing list?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: feature request: caching message arrival time

2019-06-03 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> Since notmuch actually knows when it recieved the message [...]

Not meaning to complicate things, but Notmuch does not receive messages
at all. ;-) One needs to rely on some software to populate the Maildir
tree (Dovecot LMTP in my case, Postfix or some other MTA for local
delivery in other cases). Any software transporting the raw messages
can, and sometimes must, manipulate the header data, and the order in
which files within the Maildir tree are created is also not determined
by Notmuch.

As an example: My nightly backup script disables local delivery for the
duration of the backup process. Once reactivated, delivery of queued
messages resumes, but it is not guaranteed to happen in the order of
arrival. So even the local MTA, although trusted, might induce issues in
terms of delivery time.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: feature request: caching message arrival time

2019-06-01 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> I'm working on Autocrypt integration for notmuch right now [...]

Woot! :-)

> I'm happy to explain more about my use case if people are interested
> too.

I'm interested. Right now I frankly don't know what knowing when a
message was first seen by Notmuch might be useful for. That makes it
a bit difficult for me to contemplate your questions.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [FEATURE] indexing arbitrary headers

2019-05-30 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> I just wanted to point out that this specific request has now been
> added to notmuch, thanks to David Bremner!

Thanks indeed! I am very much looking forward to this feature.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Two "latest" releases available for download

2019-05-02 Thread Ralph Seichter
I just realised that https://notmuchmail.org/releases/ holds both
LATEST-notmuch-0.28.2.tar.gz and LATEST-notmuch-0.28.3.tar.gz, which
seems to be one "latest" too many?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-20 Thread Ralph Seichter
* David Bremner:

> Right, I think that point is clear now, that we're just talking about
> changing the warning messages.

Indeed. I am actually quite surprised how many reactions there were
about this minor issue. I'm using the new.ignore settings you suggested,
and I can live with that. The warning messages surprised me, is all.

> I'm not saying I'm going to work on it, but I think I understand the
> feature-request.

I'd appreciate a change at some point in the future, time permitting,
but I would not begrudge you spending your energy on more important
issues.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-20 Thread Ralph Seichter
* Eric:

> I think that there will be lots of people (and organisations) who get
> collections of email from elsewhere and want to add them all to their
> own single collection for reference, archival, and research purposes.

And how would dropping individual mail files into "cur" instead of any
old folder limit that?

> So that those emails would be forced into the IMAP folder structure,
> making them visible (and possible distracting) there when viewed with
> a traditional mail client?

I don't know why you talk about "forced", and it is not an IMAP folder
structure anyway. I have configured Dovecot to use a Maildir store
specifically to allow Notmuch as a client in addition to IMAP. Other
storage types like Multi-dbox would be more efficient for IMAP users.

In my setup, I could circumvent Dovecot's LDA and have Postfix drop off
mail directly in that same Maildir structure, but I want to enable users
to use Sieve scripts. This works because Dovecot and Postfix have very
similar ideas about how a Maildir store should look like.

My point is: Maildir has a defined structure. I'm not against Notmuch
supporting a wider range of layouts, but I think Notmuch should not
complain about perfectly legitimate non-mail files found outside the
Maildir scope.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-19 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> as far as maildir goes, i think notmuch probably *shouldn't* be
> looking at stuff in …/tmp/ -- right?

You're right, I don't see why Notmuch would peek into "tmp".

> I'd be sad if those files went away, but perhaps you're right that
> we should only be looking at are things within any cur/ and new/
> subfolders within the message archive.

I don't mean to reduce Notmuch usability to get rid of a few unwanted
messages on stderr. What I suggest is to consider all files outside of
"cur" and "new" to be legitimate non-mail files by default. If Notmuch
chooses to inspect them and detects valid messages, then fine, but the
default assumption should be non-mail.

Think about how the files get there. You manually dumping some *.eml
files in a directory is not exactly typical, IMO. ;-) I expect that in
the majority of cases there is some MTA or fetchmail-like process
storing mail files in a Maildir structure (flat, tree, or mixed like
Dovecot does).

I think that altering Notmuch's expectations about files outside of
well-known subdirectories should be possible without sacrificing its
flexibility.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-19 Thread Ralph Seichter
* David Bremner:

> So the leading '/' isn't there to match for top level files.

That's unexpected, so quite in tune with the thread subject. ;-)

> ignore=/(^|/)dovecot[-.]/;/(maildirfolder|subscriptions)$/;

I'll try that, thanks.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-19 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> Why is "non-mail file found" in my maildir such a low priority?

Because I do not agree with Notmuch's notion of what a non-mail file
is. All files the Dovecot server uses for its own metadata are placed
outside of "cur", "new", and "tmp".

My understanding of the Maildir structure is that only these three
subfolders in a given directory may contain mail files, so I expect
Notmuch, as a default behaviour, to ignore whatever is stored outside
of these subfolders.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-19 Thread Ralph Seichter
* Ralph Seichter:

> ignore=//dovecot[[:punct:]]/;/(maildirfolder|subscriptions)$/;

Odd. I am currently adding this entry to some users' config files, and
the expression //dovecot[[:punct:]]/ does not seem to work in all
cases. Based on notmuch-search-terms(7) I assumed that Notmuch used
POSIX.2 regular expressions, does it not?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-19 Thread Ralph Seichter
* David Bremner:

> Are there warnings that you want to suppress that are not handleable
> with the new.ignore facility?

Sorry, I misunderstood your question, and new.ignore is sufficient for
my current purposes:

  [new]
  ignore=//dovecot[[:punct:]]/;/(maildirfolder|subscriptions)$/;

Thank you for pointing this feature out to me.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-18 Thread Ralph Seichter
* David Bremner:

> I guess if you have a simple way of distinguishing the cases which you
> want to consider as errrors, we can revisit the idea.

Personally, I'd go with these decreasing levels of severity:

  Fatal: Execution must stop immediately to prevent damage, error
  message may or may not be displayed before exiting the process.

  Error: Serious trouble, program may or may not be able to recover,
  user intervention required.

  Warning: Minor trouble, program will recover without user
  intervention.

  Notice: Inform the user of a less-than-ideal situation (non-mail file
  found, deprecated functionality used, etc). Program will ignore the
  cause and carry on.

I don't know if this is a fit for Notmuch, but it would be great if I
could prevent warnings and notices from being reported by using a
command line option.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unexpected output of "notmuch new --quiet"

2019-04-18 Thread Ralph Seichter
* David Bremner:

> I could imagine more levels of quiet, but I don't know if it is worth
> the trouble.

I currently redirect stderr to /dev/null because the actual number of
these "ignoring non-mail file" notices is much higher, but that means I
don't get to see actual errors which is quite a disadvantage.

An option like --veryquiet or --errorsonly would be helpful, but I can
understand you asking if it would be worth the effort. For somebody like
me who uses Dovecot as a backend it would be. ;-)

> Could it maybe a wrapper script or hook invoked by notmuch new?

Ah! The post-new hook called umask and caused the output. Thanks.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Unexpected output of "notmuch new --quiet"

2019-04-17 Thread Ralph Seichter
Hi folks,

I can't help but wonder why text like

  Note: Ignoring non-mail file: /home/foo/.maildir/.private/dovecot-uidlist
  Note: Ignoring non-mail file: /home/foo/.maildir/.work/dovecot.index.log
  0022

is written when I run "notmuch new --quiet"?

Only error conditions should be reported to stderr, so why are lines 1
and 2 written to stderr? Notes are not errors. Also, why is line #3,
which represents the current umask value, written to stdout?

I'm aware that the man page states "--quiet: Do not print progress or
results.", but the output shown above is still unexpected. Perhaps
somebody here can enlighten me. ;-)

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Autocrypt support

2019-04-11 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> [...] if you'd like to help me strategize about next steps for getting
> autocrypt support into notmuch itself, i'd welcome the collaboration.

I'd be willing to help if you think I can actually be of use to you. ;-)
I have, as of today, not even looked at the Notmuch architecture and
source code. I do know a reasonable amount about GnuPG, RFC 5322 et al,
though.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Autocrypt support

2019-04-11 Thread Ralph Seichter
I'm not quite sure if this is a question of Notmuch's Emacs client or of
Emacs in general, but I am trying to find information on Autocrypt
support (see https://autocrypt.org/).

The Enigmail addon for Thunderbird supports Autocrypt, and I wondered
if/how Notmuch might be persuaded to support it as well?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Synchronize tags across machines without a mail server

2019-03-19 Thread Ralph Seichter
* Dan Čermák:

> Ralph Seichter  writes:
>
>> * Pierre Neidhardt:
>>
>>> muchsync (http://www.muchsync.org/): Requires our own mail server if I
>>> understand correctly.
>>
>> No. If you have a machine A with notmuch already set up, and want to
>> sync to machine B, you only need SSH access from B to A (plus notmuch
>> and muchsync installed on B).
>
> That's correct if you are fine with machine B only syncing with machine
> A via muchsync and no longer with your mail servers via IMAP (or at
> least I don't know a way how to make that work).

Sorry for quoting the whole history here, but I don't see how your
comment relates to me stating that muchsync does not require a "mail
server"? If the MTA can deliver into Maildir (like Postfix can), one
does not need an IMAP server at all.

Muchsync can perform both content and metadata synchronisation, which
takes care of my needs. I run it as a background job on my notebook. An
IMAP server can be in the mix somewhere, but is not needed. That's all I
am trying to say.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Synchronize tags across machines without a mail server

2019-03-19 Thread Ralph Seichter
* Pierre Neidhardt:

> muchsync (http://www.muchsync.org/): Requires our own mail server if I
> understand correctly.

No. If you have a machine A with notmuch already set up, and want to
sync to machine B, you only need SSH access from B to A (plus notmuch
and muchsync installed on B).

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: how do i split my email view (AKA I got a new job)

2019-03-10 Thread Ralph Seichter
* Antoine Beaupré:

> How can I make that "All tags" junk disappear?

If it bugs you that much, you can use the "this page" link in "Customize
Notmuch or this page".

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch release 0.28.3 now available

2019-03-06 Thread Ralph Seichter
* David Bremner:

> https://notmuchmail.org/releases/notmuch-0.28.3.tar.gz

I'm looking at https://notmuchmail.org/releases/ right now, and I don't
see any files for version 0.28.3. I made sure it is not a caching issue
on my end.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Reply to content of "List-Post" header?

2019-03-03 Thread Ralph Seichter
* Gregor Zattler:

> my procmmail scripts recognize mailing list headers and in the end
> there is a list of all mailing lists I ever got mails from [...]

Interesting method. I don't use procmail, but I wrote a small shell
script that scans my existing Maildir storage for List-Post headers and
extracts the addresses.

This works, in a fashion, but I wonder if/how it would be possible to
make Notmuch understand List-Post natively? Or is this something that
needs to be solved in Emacs' message composition?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Reply to content of "List-Post" header?

2019-03-02 Thread Ralph Seichter
* Brian Sniffen:

> You can set message-subscribed-addresses or its cousins; then
> message-to-list-only will work for you.

Ah, that's what was missing, thank you.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Reply to content of "List-Post" header?

2019-03-02 Thread Ralph Seichter
* Gregor Zattler:

> I do "R" for reply-to-all and then C-c C-l for message-to-list-only
> which reduces the To: and Cc: to the mailing list address.

I tried both "C-c C-l" and "M-x message-to-list-only" on several
messages, but it does not seem to have any effect. I don't see any
error reports, but nothing happens.

> I don't know how this works, though. I assume it evaluates List-
> headers.

According to http://www.gnus.org/manual/big-message.html , Emacs Message
mode processes the "Mail-Followup-To" header, which seems to be a rarity
these days. "List-Post" et al apparently don't factor into it.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Reply to content of "List-Post" header?

2019-03-01 Thread Ralph Seichter
Either my search-fu is lacking today, or there is really not much
information to be found about this:

Using Notmuch with Emacs, the keys "r" and "R" are bound to "reply to
sender" and "reply to all", respectively. Neither is what I require when
it comes to mailing lists. Is there any way to "reply to list", i.e. to
only the address specified in the "List-Post" header?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: How do you synchronize your notmuch tags across multiple machines?

2018-12-17 Thread Ralph Seichter
* Dan Čermák:

> I have found muchsync, but unfortunately very little reports about how
> well it works, which isn't necessarily a bad thing.

Muchsync works well for me, although I only need to sync between two
machines. It is quite fast after the initial synchronisation, and I
did not have any problems yet. I reported a small error in the
documentation, but that should be fixed by now.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: finding file by size

2018-11-06 Thread Ralph Seichter
* Mark Janes:

> I'd like to find and delete the dozens of messages that were sent to
> me years ago with 50MB attachments.

I'm not sure about using Notmuch itself, but this should work:

  find /path/to/maildir -type f -size +50M | xargs rm

Each message in Maildir is stored in a single file, after all.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: EMACS error "Package html2text is obsolete"

2018-11-05 Thread Ralph Seichter
* Istvan Marko:

> It defaults to shr as long as emacs was compiled with libxml.

Thanks Istvan, that was the clue I needed. I rebuilt EMACS using libxml2
and now rendering HTML works.

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


EMACS error "Package html2text is obsolete"

2018-11-02 Thread Ralph Seichter
Hello list,

I tried to access https://notmuchmail.org/pipermail/notmuch/ several
times today, but it always resulted in a connection error, so I am
now trying the mailing list.

When I open a HTML message in the EMACS UI, the error message "Package
html2text is obsolete!" is displayed. Is it possible to configure
Notmuch to use SHR/EWW instead of html2text?

-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch