| Age | Commit message (Collapse) | Author |
|---|
|
- build against gmime 3.0 by preference
- drop gmime-2.4-dev, no longer supported upstream
|
|
|
|
|
|
|
|
These are from Tomi, split from the previous commit
|
|
|
|
|
|
|
|
|
|
It's a bit crazy to require emacs 24 installed just to build, when it
isn't required to run.
|
|
This is needed for consistent beheviour between notmuch built against
gmime-2.6 and gmime-3.0 w.r.t. error reporting.
|
|
|
|
|
|
|
|
|
|
This is likely not strictly necessary given that notmuch-emacs is a
transitional package. But having a simple consistency until we
eventually remove the transitional notmuch-emacs package seems ok too,
and fewer arbitrary lintian warnings will make real lintian warnings
more visible.
|
|
|
|
|
|
Some things that might be interesting (and are acceptable and
supported under 4.0.0, though not required) are:
* supporting DEB_BUILD_OPTIONS tag nodoc wihle tagging build-deps (we
could put python-sphinx into <!nodoc>, for example)
* splitting out Build-Depends-Arch from Build-Depends
|
|
Resolves lintian binary-control-field-duplicates-source
|
|
This actually happened in 0.24.x.
|
|
merge 32 bit compilation fix
|
|
|
|
The problem shows up on 32 bit architectures where sizeof(time_t) !=
sizeof(gint64). Upcasting the 32 bit time_t to a 64 bit integer
should hopefully be safe.
|
|
|
|
notmuch 0.25~rc0 release
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
based on the same patch from dkg as the previous commit.
|
|
gmime 3.0 knows how to select the correct GMimeCryptoContext
automatically, so a bunch of the code in notmuch can be dropped in
that case.
The #ifdef removal of the crypto stuff is better than #define aliasing
in gmime-extra.h for this stuff. When built against gmime 3.0:
* it reduces compiled code, and
* it avoids initializing unused gpgme contexts
(based on a patch from dkg)
|
|
These are due to (excessively?) fancy macro definitions in gmime-extra.h
|
|
Silently ignoring signed/encrypted parts seems like the wrong idea,
and it also complicates future gmime-3.0 compatibility changes.
|
|
There are some cases like remote usage where this might cause
problems, but those users can easily customize the variable. The
inconvenience seems to be outweighed by the security benefit for most
users.
|
|
- removed 7 trailing dots -- to make those lines subsection headers
- converted some (mime type) text to monospace
- removed one extra space
|
|
When compiling as C code (instead of C++) against gmime 3.0, gcc gives
errors like the following:
error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive]
so use explicit *_NONE values instead.
|
|
gmime 3.0 no longer offers a means to set the path for gpg.
Users can set $PATH anyway if they want to pick a
differently-installed gpg (e.g. /usr/local/bin/gpg), so this isn't
much of a reduction in functionality.
The one main difference is for people who have tried to use "gpg2" to
make use of gpg 2.1, but that isn't usefully co-installable anyway.
|
|
The reply-to munging code might behave differently whether there's an
exact match on the strings or not, or whether the string is a raw
addr-spec instead of an name-addr. These tests cover those variations
(i also had to tweak json output further below when this new test was
added).
|
|
In some (bad!) cases, "notmuch reply" might fail, or might even
segfault. If this happens, it indicates a bug, and the test suite
should notice it.
|
|
Apparently it moved from "name" to "key_id" in gmime-3.0
|
|
The "key_id" field seems to used for userid in gmime-3.0, while the
keyid is dropped in the fingerprint field if the full fingerprint is
not available.
|
|
In gmime 3.0 this function is "transfer none", so no deallocation is
needed (or permitted)
|
|
The iterator is gone, so we need a new loop structure.
|
|
We need to rewrite the loop for gmime-3.0; move the loop body to its
own function to avoid code duplication. Keep the common exit via
"goto DONE" to make this pure code movement. It's important to note
that the existing exit path only deallocates the iterator.
|
|
This changes return type in gmime 3.0
|
|
Both the enum and the values are renamed in GMime 3.0.
|
