Am Do., 24. Aug. 2023 um 17:10 Uhr schrieb David Bremner <david@tethera.net>:
>
> David Bremner <david@tethera.net> writes:
>
> > I just saw this when running in debian's "sbuild" isolated build
> > environment. So my current guess is that this has to do with HOME
> > pointing somewhere nonexistent. Is that also the case in COPR?
> >
> > d
>
> I realized that we override HOME inside the tests anyway, so emacs
> should think there is some writable HOME in any case. I did notice that
> the tests trigger a bunch of emacs native compilation (because the
> caching happens in the temporary $HOME, which gets blown away every
> time).

Also, $HOME is set in all my build envs (pass or fail), and
permissions are the same. Bummer.

It took more runs to get some fails now, and archs vary, so I still
think its a time out. And no way to get it locally so far.

ENOLISP (for me) but could it be the case that notmuch-test-wait can
abort its while loop too early if the first buffer write takes longer
than the timeout, or if some other process writes (because the process
parameter is nil)? Is something different for emacs 29 in this regard?
Any clues from sbuild?

Michael
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org