Austin Ray writes:
> I can confirm this fixes the leak on my end. Thanks!
>
>> I'm slightly worried that ASAN tests will prove to be flaky.
>
> If I recall correctly, the Chromium project runs ASAN in their CI
> pipelines and it's pretty stable. Hopefully that's some evidence towards
> their
I can confirm this fixes the leak on my end. Thanks!
> I'm slightly worried that ASAN tests will prove to be flaky.
If I recall correctly, the Chromium project runs ASAN in their CI
pipelines and it's pretty stable. Hopefully that's some evidence towards
their stability.
Austin
--
Revert commit 8370e3cfe2dd8a79323613c2bbf2f11db6134dac, and remark the
corresponding test as broken. Also update the expected output of the
broken test to show excludes active in the user defined saved searches.
---
emacs/notmuch-hello.el| 2 +-
Initially only use in notmuch-hello-insert-alltags. This is a more
narrow resolution of [1], which (unlike [2]) does not disable exclude
processing for regular saved searches.
[1]: id:87wox1vovj.fsf@len.workgroup
[2]: id:20220105010606.2034601-2-da...@tethera.net
---
emacs/notmuch-hello.el | 12
The previous fix applied to master was too broad, and turned of
excludes for all counts in notmuch hello. This made the message counts
potentially inflated compared to the searches that actually show up
for saved searches. This fix treats "all tags" as a special case, but
leaves the behaviour of
Gregor Zattler writes:
> I confirm, the bug does not show up in my test case from
> message id:877ep0kx52.fsf@len.workgroup
>
> Thanks for this bug fix and for notmuch in general, Gregor
Hey, thanks for checking. I think the fix may have broken something
else, since now the counts displayed have
Hi David, Tomi, notmuch developers,
* David Bremner [2022-01-20; 15:51]:
> Tomi Ollila writes:
>> Yes, I can reproduce -- only "spam" is seen
>>
>> To look what happened I ran (in notmuch source dir):
>>
>> $ NOTMUCH_CONFIG=/tmp/.notmuch-config strace -f -e trace=execve,read,write
>> -o ttt