Ship a new debian package for the notmuch2 CFFI-based Python interface
to notmuch.
Unlike the notmuch python module, the new notmuch2 module is no longer
arch-independent, because it builds and ships a shared object in
addition to the python code.
This patch encourages new downstream development
Daniel Kahn Gillmor writes:
> Another fix to the docstrings, this time for the English part of the
> docstrings, not the Python class name. No functional changes here.
>
> Signed-off-by: Daniel Kahn Gillmor
pushed,
d
___
notmuch mailing list
Daniel Kahn Gillmor writes:
> There is no functional change here, just a fix to a typo in the
> docstrings.
>
> Signed-off-by: Daniel Kahn Gillmor
pushed.
d
___
notmuch mailing list
notmuch@notmuchmail.org
Signed-off-by: Daniel Kahn Gillmor
---
debian/elpa-notmuch.lintian-overrides | 4
1 file changed, 4 insertions(+)
create mode 100644 debian/elpa-notmuch.lintian-overrides
diff --git a/debian/elpa-notmuch.lintian-overrides
b/debian/elpa-notmuch.lintian-overrides
new file mode 100644
index
Another fix to the docstrings, this time for the English part of the
docstrings, not the Python class name. No functional changes here.
Signed-off-by: Daniel Kahn Gillmor
---
bindings/python-cffi/notmuch2/_database.py | 28 +++---
bindings/python-cffi/notmuch2/_errors.py | 2
There is no functional change here, just a fix to a typo in the
docstrings.
Signed-off-by: Daniel Kahn Gillmor
---
bindings/python-cffi/notmuch2/__init__.py | 2 +-
bindings/python-cffi/notmuch2/_database.py | 4 ++--
bindings/python-cffi/notmuch2/_tags.py | 2 +-
3 files changed, 4
See lintian informational tag
symbols-file-missing-build-depends-package-field for hints about this
minor metadata update.
Signed-off-by: Daniel Kahn Gillmor
---
debian/libnotmuch5.symbols | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/libnotmuch5.symbols
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Makes it clear that the "Legacy Display" part of an encrypted message
with protected headers can (and indeed, should) be of content-type
text/plain, though some clients still generate the Legacy Display part
as content-type
These tests were an attempt to establish that the content of the
"Legacy Display" part is the same as the actual protected headers of
the message. But this is more conservative than we need to be.
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
section 5.3 makes clear
