> > > BTW, I have so far run the test suite 68 times in a row without failures
> > > on a Debian s390x host. The file system is ext4, mounted relatime. It
> > > would be interesting to know what file system is yielding the failures
> > > Michael is seeing.
>
...
> So I'll try out a bit more, and
Tomi Ollila venit, vidit, dixit 2022-02-14 23:53:54:
> On Mon, Feb 14 2022, David Bremner wrote:
>
> > Tomi Ollila writes:
> >
> >>
> >> Looked notmuch-new.c -- time_t (seconds since epoch) is used as timestamp
> >> comparisons (which would indicate the subsecond resolution most fs' provide
> >>
On Mon, Feb 14 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> Looked notmuch-new.c -- time_t (seconds since epoch) is used as timestamp
>> comparisons (which would indicate the subsecond resolution most fs' provide
>> is not used)...
>>
>> ... and if so, I wonder why some of our tests
On Mon, Feb 14 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> Looked notmuch-new.c -- time_t (seconds since epoch) is used as timestamp
>> comparisons (which would indicate the subsecond resolution most fs' provide
>> is not used)...
>>
>> ... and if so, I wonder why some of our tests
Tomi Ollila writes:
>
> Looked notmuch-new.c -- time_t (seconds since epoch) is used as timestamp
> comparisons (which would indicate the subsecond resolution most fs' provide
> is not used)...
>
> ... and if so, I wonder why some of our tests are not failing all the time
> for everyone...?
Not
On Sun, Feb 13 2022, Tomi Ollila wrote:
> On Sat, Feb 12 2022, David Bremner wrote:
>
>> Tomi Ollila writes:
>>
>>>
>>> Does such a change hide "buggy" functionality ?
>>
>> We mostly don't use add_message, call notmuch new via NOTMUCH_NEW in
>> T050-new.sh. So I think it would mostly not hide
On Sat, Feb 12 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> Does such a change hide "buggy" functionality ?
>
> We mostly don't use add_message, call notmuch new via NOTMUCH_NEW in
> T050-new.sh. So I think it would mostly not hide bugs in notmuch
> new. OTOH, I'm surprised the same
Am Sa., 12. Feb. 2022 um 22:10 Uhr schrieb David Bremner :
> Tomi Ollila writes:
>
> >
> > Does such a change hide "buggy" functionality ?
>
> We mostly don't use add_message, call notmuch new via NOTMUCH_NEW in
> T050-new.sh. So I think it would mostly not hide bugs in notmuch
> new. OTOH, I'm
Tomi Ollila writes:
>
> Does such a change hide "buggy" functionality ?
We mostly don't use add_message, call notmuch new via NOTMUCH_NEW in
T050-new.sh. So I think it would mostly not hide bugs in notmuch
new. OTOH, I'm surprised the same issues with timestamps don't show up
there, if that is
Am Sa., 12. Feb. 2022 um 21:45 Uhr schrieb Tomi Ollila :
> On Sat, Feb 12 2022, David Bremner wrote:
>
> > Tomi Ollila writes:
> >
> >> On Sat, Feb 12 2022, Michael J. Gruber wrote:
> >>
> >> Only thing that came into mind are directory timestamps... if directory
> >> (m)time is same as before
On Sat, Feb 12 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>> On Sat, Feb 12 2022, Michael J. Gruber wrote:
>>
>> Only thing that came into mind are directory timestamps... if directory
>> (m)time is same as before notmuch will not scan it for files...
>>
>> ... following that if the
David Bremner writes:
> Tomi Ollila writes:
>
>> On Sat, Feb 12 2022, Michael J. Gruber wrote:
>>
>> Only thing that came into mind are directory timestamps... if directory
>> (m)time is same as before notmuch will not scan it for files...
>>
>> ... following that if the granularity of
Tomi Ollila writes:
> On Sat, Feb 12 2022, Michael J. Gruber wrote:
>
> Only thing that came into mind are directory timestamps... if directory
> (m)time is same as before notmuch will not scan it for files...
>
> ... following that if the granularity of directory timestamp were 1 second,
> then
On Sat, Feb 12 2022, Michael J. Gruber wrote:
> David Bremner venit, vidit, dixit 2022-02-12 01:03:00:
>> Michael J Gruber writes:
>>
>> > Hi there,
>> >
>> > I'm trying to package notmuch for Redhat's enterprise linux and clones
>> > (EPEL, extra packages for enterprise linux).
>> >
>> > This
Michael J Gruber writes:
>>
>> It's hard to see what can go wrong (maybe perl doesn't work?), but
>> failing to generate a message should be a fatal error. Maybe try
>> something like
I was unclear. I meant "should" as in "in a perfect world", not as a
prediction about the current code. So we
David Bremner venit, vidit, dixit 2022-02-12 01:03:00:
> Michael J Gruber writes:
>
> > Hi there,
> >
> > I'm trying to package notmuch for Redhat's enterprise linux and clones
> > (EPEL, extra packages for enterprise linux).
> >
> > This looks mostly fine, including the tests, except for
Michael J Gruber writes:
> Hi there,
>
> I'm trying to package notmuch for Redhat's enterprise linux and clones
> (EPEL, extra packages for enterprise linux).
>
> This looks mostly fine, including the tests, except for intermittent
> failures on epel-8-s390x. They look like the below, or in
Michael J Gruber venit, vidit, dixit 2022-02-11 14:55:32:
> Hi there,
>
> I'm trying to package notmuch for Redhat's enterprise linux and clones
> (EPEL, extra packages for enterprise linux).
>
> This looks mostly fine, including the tests, except for intermittent
> failures on epel-8-s390x.
Hi there,
I'm trying to package notmuch for Redhat's enterprise linux and clones
(EPEL, extra packages for enterprise linux).
This looks mostly fine, including the tests, except for intermittent
failures on epel-8-s390x. They look like the below, or in tests
following those, and apparantly all
19 matches
Mail list logo
