As reported in id:87h7pxiek3.fsf@tethera.net, the previous version of
the test is flaky. There is some so-far undebugged interaction between
openssl and gpgsm that causes the keys to fail to import. As a
potential workaround, use the key as exported by gpgsm, and eliminate
openssl from this particular pipeline.
As discussed in the thread starting at [1], the fully qualified domain
name is a bit tricky to get reproducibly, might reveal information
people prefer to keep private, and somewhat unlikely to provide
reliable mail routing.
The new approach of $current_username@localhost is better for the
first two considerations, and probably at least as good as a test mail
address.
[1]: id:87sfyibqhj.fsf@tethera.net
These are failing on (surprisingly) the Debian amd64
autobuilder. There were also previous reports of failures on Ubuntu
s390x. Fixing this may require changing the way the default is
calculated.
This is just a regular character in docstrings (as it is fairly often
used in lisp identifiers and buffer names) but is the start of
emphasis in rst. This change is needed to quell a noisy warning when
including notmuch-tree.rsti
This is a bit of a cheat, since the format does not actually
change. On the other hand it is fairly common to do something like
this to shared libary SONAMEs when the ABI changes in some subtle way.
It does rely on the format-version argument being early enough on the
command line to generate a sensible error message.
This new command for notmuch-tree-mode is analogous to
notmuch-search-filter-by-tag, bound to "t" in notmuch-search-mode; it
gets therefore the same "t" keybinding in notmuch-tree-mode (replacing
the current assignment to notmuch-search-by-tag).
This is more robust against crashes when the expected output is also
generated by notmuch. In the case where the expected output is
explicit, it seems like overkill.
A common bug in tests is that the code used to generate the EXPECTED
file fails, generating no output. When the code generating the OUTPUT
file fails in the same way, the test passes, even though there is a
failure being hidden. Add a new test function that guards against
this.
We need to special case the config section "built_with" because it is
not (currently) handled by the library. This seems consist with the
other sub-sub-commands 'list' and 'set'.
This highlights a bug reported by several users, including
Mohsin Kaleem [1].
The inconsistent use of test_begin_subtest_known_broken is because
some of these tests pass even though the database cannot be
located. This problem is left for a future commit.
[1]: id:87bl9lx864.fsf@kisara.moe
Notmuch 0.32 corresponds to libnotmuch 5.4 as indicated by docstrings;
however, the minor number wasn't bumped. Any libnotmuch downstream
consumer using the LIBNOTMUCH_CHECK_VERSION macro to support multiple
versions won't be able to access the new 5.4 functions.
Signed-off-by: Austin Ray <austin@austinray.io>
Both notmuch_database_open() and notmuch_database_open_verbose()'s
documentation state they call notmuch_database_open_with_config() with
config_path=NULL; however, their implementations pass an empty string.
The empty string is the correct value to maintain their original
behavior of not loading the user's configuration so their documentation
is incorrect.
The intent of the 'notmuch-jump-key' face is to allow users/themes to
differentiate the text of the minibuffer prompt from the keys that are
associated with jump actions. Commit 5cc106b0 correctly introduced the
'notmuch-jump-key' face for keys, but mistakenly applied it to the
prompt as well.
When mm-text-html-renderer is set to 'w3m, the variable playing the
role of a regular expression for blocked images is
w3m-ignored-image-url-regexp. We bind it when the renderer is not
'shr.
It was assumed the destructor of notmuch_rb_database_type did return a
notmuch_status_t because that's what notmuch_database_close returns, and
that value was checked by notmuch_rb_database_close in order to decide
if to raise an exception.
It turns out notmuch_database_destroy was called instead, so nothing was
returned (void).
All the destroy functions are void, and that's what we want.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
BSD xargs does not have the -d option. Here we use tr to convert
newlines to NUL characters, then pass -0 to xargs (which BSD does
support).
I looked at passing -z to 'git ls-files', but I did not find a BSD
grep option to turn on NUL deliminted line processing.
Mathias Beyer [1] points out that this note is redudant since Xapian
no longer builds with the problematic versions of Xapian.
[1]: id:20210207124404.yldgtzjrsagacrl4@hoshi
