Hello,
With the patch now in master, the documentation for Emacs (‘Tips and
Tricks for using Notmuch with Emacs’) needs to be updated:
https://notmuchmail.org/emacstips/#index5h2
‘notmuch-search-interactive-region’ is mentioned in the second block of
Elisp.
Also, could we mark the old function a
On Mon, May 20 2019, Leo Vivier wrote:
> Hello,
>
> With the patch now in master, the documentation for Emacs (‘Tips and
> Tricks for using Notmuch with Emacs’) needs to be updated:
> https://notmuchmail.org/emacstips/#index5h2
>
> ‘notmuch-search-interactive-region’ is mentioned in the second blo
The current 2 minute timeout is reasonable, but to exercise the test
suite or induce timeout failures, we might want to make it shorter.
This makes it configurable so you can run (for example):
make check NOTMUCH_TEST_TIMEOUT=10s
We stick with the default of 2m.
Signed-off-by: Daniel Kahn Gi
When a parallel build fails (or when it times out, if timeout is
present), the test suite should not blithely succeed. Catch these
failures and at least report them.
Signed-off-by: Daniel Kahn Gillmor
---
test/notmuch-test | 5 +
1 file changed, 5 insertions(+)
diff --git a/test/notmuch-te
On Sat 2019-05-11 20:45:59 -0600, David Bremner wrote:
> To the best of my understanding, this original behaviour was what
> Carl's homebrew parser produced. With commit 86f89385 Austin switched
> to using GMime (2.6). This produced arguably worse results, but since
> the input was bad, we could li
Thanks for catching this, Bremner.
On Fri 2019-05-10 07:45:18 -0300, David Bremner wrote:
> In a debian stretch neither gnu parallel nor moreutils parallel
> successfully completes the tests.
I have confirmed this misbehavior on debian stretch with moreutils
parallel. on stretch (with gmime 3.0
On Mon, May 20 2019, Daniel Kahn Gillmor wrote:
> The current 2 minute timeout is reasonable, but to exercise the test
> suite or induce timeout failures, we might want to make it shorter.
> This makes it configurable so you can run (for example):
>
> make check NOTMUCH_TEST_TIMEOUT=10s
>
> We
On Mon, May 20 2019, Daniel Kahn Gillmor wrote:
> Thanks for catching this, Bremner.
>
> On Fri 2019-05-10 07:45:18 -0300, David Bremner wrote:
>> In a debian stretch neither gnu parallel nor moreutils parallel
>> successfully completes the tests.
>
> I have confirmed this misbehavior on debian st
Tomi Ollila writes:
> On Mon, May 20 2019, Daniel Kahn Gillmor wrote:
>
>> The current 2 minute timeout is reasonable, but to exercise the test
>> suite or induce timeout failures, we might want to make it shorter.
>> This makes it configurable so you can run (for example):
>>
>> make check N
David Bremner writes:
> To the best of my understanding, this original behaviour was what
> Carl's homebrew parser produced. With commit 86f89385 Austin switched
> to using GMime (2.6). This produced arguably worse results, but since
> the input was bad, we could live with it. Now with GMime 3.0
Daniel Kahn Gillmor writes:
> 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
The Ubuntu linker prefers --as-needed. This is nice, but it means
that our _check_session_key.c configure-time script (introduced by me
in 30c4fa3702f90572afcd1984dbd7aba70f2b4fd9) fails on xenial.
In the course of debugging the reason, i found several other
infelicities in the error cases in han
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 libra
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 aroun
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
---
configure | 10 +++---
1 fil
On Mon 2019-05-20 16:46:23 -0300, David Bremner wrote:
> I pushed this, and broke travis. Can you please have a look at
>
> https://travis-ci.org/notmuch/notmuch/builds/534979532
Sorry about this, the flaw was a difference between the ubuntu and
debian linker default behavior.
I've responded ov
On Mon 2019-05-20 21:55:05 +0300, Tomi Ollila wrote:
> On Mon, May 20 2019, Daniel Kahn Gillmor wrote:
>> b) we should have a clearer sense of which tests completed and which
>> did not
>> […]
>> if someone else wants to
>> improve the test suite to handle (b) that would be great.
>
> Simplest
Daniel Kahn Gillmor writes:
> When using a promiscuous linker, _check_session_keys was working fine.
>
cleanup series pushed, with one minor change. For reasons that Tomi can
explain, we use "command -v" instead of "which" in scripts.
d
___
notmuch ma
Tests appear to be hanging when run under GNU timeout on debian
stretch. To aid in diagnosing this or similar problems, it's handy to
be able to disable timeout from the command line at will.
Signed-off-by: Daniel Kahn Gillmor
---
test/notmuch-test | 9 +++--
1 file changed, 7 insertions(+)
On Mon 2019-05-20 13:27:03 -0400, Daniel Kahn Gillmor wrote:
> c) we should avoid the timeout hanging :)
I dug into this today, and i'm reporting back my findings.
I have what appears to be a fix (see below), but i don't understand it,
so i'm not advocating for it.
To be clear: my two test case
On Mon 2019-05-20 19:49:02 -0400, Daniel Kahn Gillmor wrote:
> However, i tried selectively upgrading all the versions of all of these
> packages *except for gdb* to the version in buster (or to the version
> from backports, in the case of the kernel). and i'm *still* seeing the
> problem on the s
This is an empirical fix for a strange interaction we're seeing
between gdb 7.12-6 on debian stretch, GNU timeout, and parallel from
moreutils, reported by Bremner in id:87ef56io5d@tethera.net.
The problem manifested itself as several concurrent test suite
subprocesses getting stopped by SIGTT
Daniel Kahn Gillmor writes:
>
> A marginally cleaner patch be to consistently use gdb with either one
> of:
>
> * -tty /dev/null
> * < /dev/null
>
> in all of T050, T060, and T070. But T070 can't use "< /dev/null"
> because it needs stdin. And when i tried to use "-tty /dev/null" in
> T050 an
On Mon, May 20 2019, Daniel Kahn Gillmor wrote:
>
> A marginally cleaner patch be to consistently use gdb with either one
> of:
>
> * -tty /dev/null
> * < /dev/null
This looks like a good read:
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_21.html
and is used to speculate below.
I also
24 matches
Mail list logo
