Re: test failures on 32 bit architectures.
David Bremner writes: > I know, I know, I don't use 32 bit architectures either. However... > > Looking at [1], it looks like there two tests consistently failing on 32 > bit architectures (and also mips64el, FWIW). Hmm. Somewhere between when I sent this message and now, some upgrade in debian unstable made these failures go away for me on i386. So maybe I'll wait a day or so for the autobuilders to catch up, and retry the more exotic architectures. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python-cffi: read version from notmuch version file
On Fri 19 Jun 2020 at 15:26 +0300, Frank LENORMAND wrote:
> On Fri Jun 19 12:46:28 2020, Floris Bruynooghe wrote:
>> This keeps it in sync with the main notmuch version which is less
>> confusing to users.
>> ---
>> bindings/python-cffi/setup.py | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/bindings/python-cffi/setup.py b/bindings/python-cffi/setup.py
>> index 37918e3d..1effcfc6 100644
>> --- a/bindings/python-cffi/setup.py
>> +++ b/bindings/python-cffi/setup.py
>> @@ -1,9 +1,17 @@
>> +import pathlib
>> +
>> import setuptools
>>
>>
>> +THIS_FILE = pathlib.Path(__file__).absolute()
>> +PROJECT_ROOT = THIS_FILE.parent.parent.parent
>> +with open(PROJECT_ROOT.joinpath('version')) as fp:
>> +VERSION = fp.read().strip()
>> +
>> +
>> setuptools.setup(
>> name='notmuch2',
>> -version='0.1',
>> +version=VERSION,
>> description='Pythonic bindings for the notmuch mail database using
>> CFFI',
>> author='Floris Bruynooghe',
>> author_email='f...@devork.be',
>> --
>> 2.27.0
>
> It seems that this strategy doesn't work well when the user runs
> `pip install .` in the `bindings/python-cffi` directory.
>
> Apparently all the files are copied to a temporary directory first:
>
> https://travis-ci.com/github/pazz/alot/jobs/351377760#L708-L710
>
> It doesn't happen with the original bindings, probably because the version
> number is stored in `bindings/python/notmuch/version.py`, which is also
> copied when `pip` runs.
Ouch, I only tested pip install -e, which does work. But indeed a plain
pip install no longer works which is pretty bad.
I guess we could either revert this and do the same sed hackery as the
other bindings, or copy the version file into bindings/python-cffi and
have it loaded in the same way as now. It would still have to be kept
in sync there sadly.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python/notmuch2 on PyPI
On Fri 19 Jun 2020 at 09:30 -0300, David Bremner wrote: > Patrick Totzke writes: >> Just to clarify: alot does not, and will not, depend on packages being on >> PyPI Ah, my bad. I got some github threads mixed up and assumed this had to do with alot. > Notmuch as a project does not currently distribute any binary packages, > whether for linux distros or for PyPi, or fancy new things like flatpaks > or snaps. Also fair enough, I think that's a very reasonable stance to take. I was really hoping to hear from Thore on their motivation and how they envision this to ideally work. I'm curious how much work the syncing is and how to keep it up to date etc. Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] completion: remove "setup" from the list of possible completions
It was <2020-06-20 sob 12:53>, when Reto wrote: > On Fri, Jun 19, 2020 at 12:40:49PM +0200, Łukasz Stelmach wrote: >> Having "setup" in the set requires entering three instad of two characters >> for "search". Since "setup" is rearly used it makes little sense to have >> it in the set and cripple UX for much more frequently used "search". > > I very much disagree with this patch. > The completions should contain all possible values, saving a single keystroke > is > certainly not a valid reason to remove a valid option from the completions. > > Write an alias into your bashrc if that bothers you so much... Then you can > save > much more keystrokes. I already have several aliases covering most of my use cases, however, I still use "notmuch search" from time to time and I came to a conclusion expressed in this patch. Of course, as a random user, I can only suggest and by no means insist on applying it. Kind regards, -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
test failures on 32 bit architectures.
I know, I know, I don't use 32 bit architectures either. However...
Looking at [1], it looks like there two tests consistently failing on 32
bit architectures (and also mips64el, FWIW).
T160-json: Testing --format=json output
FAIL Search message: json, 64-bit timestamp
--- T160-json.8.expected2020-06-22 12:29:35.053363072 +
+++ T160-json.8.output 2020-06-22 12:29:35.053363072 +
@@ -1,7 +1,7 @@
[
{
"authors": "Notmuch Test Suite",
-"date_relative": "the future",
+"date_relative": "1970-01-01",
"matched": 1,
"query": [
"id:msg-005@notmuch-test-suite",
@@ -13,7 +13,7 @@
"unread"
],
"thread": "XXX",
-"timestamp": 32472187200,
+"timestamp": 0,
"total": 1
}
]
T355-smime: Testing S/MIME signature verification and decryption
FAIL Verify signature on PKCS#7 SignedData message
expires: value not equal:
data[0][0][0]["crypto"]["signed"]["status"][0]["expires"] = 2145914603 !=
2611032858
I haven't tried to debug yet, but the first bug looks like a timestamp
overflowing 32 bits, becoming negative, and being clamped to 0.
No idea about the second.
[1]: https://buildd.debian.org/status/package.php?p=notmuch=experimental
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
