This will correct the current use of an undefined variable when
setting LD_LIBRARY_PATH in doc/Makefile.local
It is tempting to try to replace the use of test/export-dirs.sh, but
this is not as simple as it looks, as NOTMUCH_BUILDDIR is used to
locate sh.config, so probably cannot also sensibly be used to define
it.
Since set -u is used, without bash or perl, configure would fail.
This has gone unnoticed as (almost) everyone always had both
bash and perl installed (and in $PATH).
Thanks to FreeBSD ports this bug became visible; this change is
verbatim copy of `patch-configure` in FreeBSD ports tree.
The main idea is to replace the hack of copying version.txt into the
bindings source with a generated _notmuch_config.py file.
This will mean that the bindings only build after configuring and
building notmuch itself. Given those constraints, "pip install ."
should work.
In order to make it easier to keep the whitespace consistent in the
configure script, use the same style defined in devel/STYLE for
C/C++.
Specifically, a line should begin with zero or more tabs followed
by fewer than eight spaces.
Presumably this will be no more difficult for people editing configure
than for people editing the C and C++ code.
As discussed at [1] we have received reports that the implicit check
using cffi.FFI().verify() is not reliable in all environments. Since
we already use pkg-config, and the python dev package should include a
.pc file [2], add an extra check using pkg-config. On at least
Debian, we have to know which version of python dev files with are
looking for, so calculate that first.
[1]: id:87im1g35ey.fsf@tethera.netid:87im1g35ey.fsf@tethera.net,
[2]: checked on Debian and Fedora
The configure part is essentially the same as the other checks using
pkg-config. Since the optional inclusion of this feature changes what
options are available to the user, include it in the "built_with"
pseudo-configuration keys.
For portability; the realpath command (e.g. from GNU coreutils)
is not so common outside Linux systems.
The "$(cd emacs && pwd -P)" replaces that realpath(1) execution
suitably in this context (using just bash(1) builtins).
Starting from xapian 1.3.5, xapian switched default backend to glass.
From 00cdfe10 (build: drop support for xapian versions less than 1.4,
2020-04-22), we only support xapian 1.4.0+. Effectively, we don't need
to check for default xapian backend anymore.
Further more, from 99a7aac8 (test: drop use of db_ending, 2020-07-29),
our test framework has become independence from default xapian.
Let's drop it.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
On different distro, pytest is suffixed with different patterns.
On the other hand, `python3-pytest' could be invoked correctly,
via `python3 -m pytest', the latter is used by our tests, now.
Switch to `$python -m pytest` to fix address all incompatible naming.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
It is getting unwieldy to pass configuration options on the
sphinx-build command line, and I anticipate further use of
conditionals.
As far as I could tell, execing a string is the idiomatic way to
emulate include in Python.
These are less crucial since we stopped generating new database
versions and relied primarily on features. They also rely on a
pre-generated v1 database which happens to be chert format. This
backend is not supported by Xapian 1.5.
Also drop the tool gen-testdb.sh, which is currently broken, due to
changes in the testing infrastructure.
If https://dev.gnupg.org/T3464 is unresolved in the version of gpgme
we are testing against, then we should know about it, because it
affects the behavior of notmuch.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Certain tests involving timestamps > 32 bits cannot pass with the
current libnotmuch API. We will avoid this issue for now by disabling
those tests on "old" architectures with 32 bit time_t.
Checking existence of pyconfig.h to determine whether CFFI-based
notmuch bindings are buildable is not enough; for example Fedora 32
ships pyconfig.h in python3-libs package, but python3-devel is required
to be installed for the bindings to build.
Executing cffi.FFI().verify() is pretty close to what is done in
bindings/python-cffi/notmuch2/_build.py to get the c code part of the
bindings built.
Also tell users what the consequences of a "No" answer is when
python version is less than 3.5, cffi or setuptools is missing,
or no pytest >= 3.0 is available.
The notmuch2 CFFI-based Python interface is not buildable unless
python3 dev package and python3 setuptools are installed.
Check that these exist in configure (and disable notmuch2 bindings
build if not) so that build of these bindings don't fail when make(1)
is executed.
This is a simple hack to enable out-of-tree builds, a concern raised
by Tomi in id:m24kzjib9a.fsf@guru.guru-group.fi
This change at least enables "make check" to complete without error,
but I'm sure it could be improved. I am not expert enough in
setuptools to know how.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended by db per id:87d06usa31.fsf@powell.devork.be
We already report the minimum version for Glib, zlib, and Xapian
development libraries. For consistency, report it for GMime as well.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
When checking cryptographic signatures, Notmuch relies on GMime to
tell it whether the certificate that signs a message has a valid User
ID or not.
If the User ID is not valid, then notmuch does not report the signer's
User ID to the user. This means that the consumer of notmuch's
cryptographic summary of a message (or of its protected headers) can
be confident in relaying the reported identity to the user.
However, some versions of GMime before 3.2.7 cannot report Certificate
validity for X.509 certificates. This is resolved upstream in GMime
at https://github.com/jstedfast/gmime/pull/90.
We adapt to this by marking tests of reported User IDs for
S/MIME-signed messages as known-broken if GMime is older than 3.2.7
and has not been patched.
If GMime >= 3.2.7 and certificate validity still doesn't work for
X.509 certs, then there has likely been a regression in GMime and we
should fail early, during ./configure.
To break out these specific User ID checks from other checks, i had to
split some tests into two parts, and reuse $output across the two
subtests.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Xapian 1.4 is over 3 years old now (1.4.0 released 2016-06-24),
and 1.2 has been deprecated in Notmuch version 0.27 (2018-06-13).
Xapian 1.4 supports compaction, field processors and retry locking;
conditionals checking compaction and field processors were removed
but user may want to disable retry locking at configure time so it
is kept.
In case zlib not found by pkg-config(1) the pkg-config information
is resolved by attempting to print ZLIB_VERSION from from zlib
installation if it exists anyway.
If above done successfully compat/zlib.pc is written for forthcoming
pkg-config execution.
Since `set -u` is in effect (since 124a67e96, 2016-05-06),
expanding unset $PKG_CONFIG_PATH (would have) failed whenever tried.
Now it is changed to set as "$PKG_CONFIG_PATH:compat" if PKG_CONFIG_PATH
is set and is non-empty string, plain "compat" otherwise.
Zsh searches in the $fpath array for completion functions. By default
this includes $(prefix)/share/zsh/site-functions but not the existing
value. The prefix for zsh and notmuch isn't guaranteed to be the same
but it normally will be making this a better default for
zsh_completion_dir.
The entire python-cffi test suite is considered as a single test at
the level of the notmuch test suite. This might or might not be ideal,
but it gets them run.
Whitespace in $NOTMUCH_SRCDIR (and $PWD) may work in builds,
but definitely will not work in tests. It would be difficult
to make tests support whitespace in test filename paths -- and
fragile to maintain if done.
So it is just easier and safer to disallow whitespace there.
In case of out of tree build $NOTMUCH_SRCDIR differs from $PWD
(current directory). Extend this whitespace, and also previously
made unsafe characters check to $PWD too.
While check for GMime session key extraction support... was made
out of tree build compatible, related (and some unrelated) unsafe
characters are now checked in notmuch source directory path.
The known unsafe characters in NOTMUCH_SRCDIR are:
- Single quote (') -- NOTMUCH_SRCDIR='${NOTMUCH_SRCDIR}'
is written to sh.config in configure line 1328.
- Double quote (") -- configure line 521 *now* writes "$srcdir"
into generated c source file ($NOTMUCH_SRCDIR includes $srcdir).
- Backslash (\) could also be problematic in configure line 521.
- The added $ and ` are potentially unsafe -- inside double quotes
in shell script those have special meaning.
Other characters don't expand inside double quoted strings.
The extra flexibility of having both HAVE_EMACS (for yes, there is an
emacs we can use) and WITH_EMACS (the user wants emacs support) lead
to confusion and bugs. We now just force WITH_EMACS to 0 if no
suitable emacs is detected.
When using a promiscuous linker, _check_session_keys was working fine.
But some OSes (including some versions of Ubuntu) have set their
linker to always link in "--as-needed" mode, which means that the
order of the objects linked is relevant. If a library is loaded
before it is needed, that library will no longer be linked in the
final outcome. _check_session_keys.c was failing on those systems.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We never want ./configure to try to do something with an unassigned
variable. So, make the directory $TEMP_GPG at the start of the
testing of session-key handling, and clean it up afterwards as long as
the directory exists.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
There are a few changes bundled here:
* say "No." explicitly if there's a failure.
* try to avoid implying that gpgme-config is necessary to build
notmuch itself (it's not, though it may be useful if you need to
rebuild gmime).
* leave _check_session_keys and _check_session_keys.c around if
./configure fails, so that the user can play with it more easily
for debugging.
* let error messages show when _check_session_keys.c is built.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended by DB: use command -v instead of which.
GMime 3.0 and higher can extract session keys, but it will *not*
extract session keys if it was built with --disable-crypto, or if it
was built against GPGME version < 1.8.0.
Notmuch currently expects to be able to extract session keys, and
tests will fail if it is not possible, so we ensure that this is the
case during ./configure time.
Part of this feels awkward because notmuch doesn't directly depend on
gpg at all. Rather, it depends on GMime, and the current
implementation of GMime depends on GPGME for its crypto, and GPGME in
turn depends on gpg.
So the use of gpg in ./configure isn't actually introducing a new
dependency, though if a future version of GMime were ever to move away
from GnuPG, we might need to reconsider.
Note that this changeset depends on
id:20190506174327.13457-1-dkg@fifthhorseman.net , which supplies the
rfc822 message test/corpora/crypto/basic-encrypted.eml used in it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in
notmuch for about 1.5 years.
Comments and documentation no longer need to refer to GMime 2.6, so
clean them all up.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
