Re: [PATCH 0/4] test: T380 rework
On Fri, Nov 24 2023, Michael J. Gruber wrote:
> So, with the key-value pairs sorted by both, I resumed testing for Python
> 3.1.13 and encountered failing T380 which gave me some a deja-vue due to
> its confusing messages:
>
> ```
> T380-atomicity: Testing atomicity
> cat: outcount: No such file or directory
> /builddir/build/BUILD/notmuch-0.38.1/test/T380-atomicity.sh: line 79: ((: i
> < : syntax error: operand expected (error token is "< ")
Minimal change would be to change line:
for ((i = 0; i < $outcount; i++)); do
as
for ((i = 0; i < ${outcount:=0}; i++)); do
that would change the empty ('') $outcount to be as '0', and also
return the same value (0) there in expression.
Then, at least the message is less confusing...
Tomi
> PASS "notmuch new" is idempotent under arbitrary aborts
> FAIL detected >10 abort points
> test -gt 10
> /builddir/build/BUILD/notmuch-0.38.1/test/test-lib.sh: line 701: test: -gt:
> unary operator expected
> ```
>
> And that is why this is a reply to the old thread where I suggested making
> this less confusing, because everything reported is not the actual failure,
> but the consequence of not safe-guarding against a failed test setup.
>
> The *real cause* is most likely that `import gdb` fails in `atomicity.py`
> because it's not ready for py 3.13 yet.
>
> But maybe it's time to reconsider some bits of the old series? We ended up
> discussing "echo vs printf" and never addressed the real issues here.
>
> Cheers,
> Michael
>
> P.S.: There are also a few lines like
> ```
> Error: database path
> '/builddir/build/BUILD/notmuch-0.38.1/test/tmp.T400-hooks/database.85' does
> not exist or is not a directory.
> ```
> sprinkled in the test output between PASS tests, apparently without making
> any test fail. I don't know whether I never noticed for a apassing test
> suite, or whether this is new.
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 0/4] test: T380 rework
So, with the key-value pairs sorted by both, I resumed testing for Python 3.1.13 and encountered failing T380 which gave me some a deja-vue due to its confusing messages: ``` T380-atomicity: Testing atomicity cat: outcount: No such file or directory /builddir/build/BUILD/notmuch-0.38.1/test/T380-atomicity.sh: line 79: ((: i < : syntax error: operand expected (error token is "< ") PASS "notmuch new" is idempotent under arbitrary aborts FAIL detected >10 abort points test -gt 10 /builddir/build/BUILD/notmuch-0.38.1/test/test-lib.sh: line 701: test: -gt: unary operator expected ``` And that is why this is a reply to the old thread where I suggested making this less confusing, because everything reported is not the actual failure, but the consequence of not safe-guarding against a failed test setup. The *real cause* is most likely that `import gdb` fails in `atomicity.py` because it's not ready for py 3.13 yet. But maybe it's time to reconsider some bits of the old series? We ended up discussing "echo vs printf" and never addressed the real issues here. Cheers, Michael P.S.: There are also a few lines like ``` Error: database path '/builddir/build/BUILD/notmuch-0.38.1/test/tmp.T400-hooks/database.85' does not exist or is not a directory. ``` sprinkled in the test output between PASS tests, apparently without making any test fail. I don't know whether I never noticed for a apassing test suite, or whether this is new. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T610 failing on Fedora rawhide
Am Fr., 24. Nov. 2023 um 14:57 Uhr schrieb David Bremner :
> Michael J Gruber writes:
>
> > Hi there,
> >
> > during my first tests for Python 3.13 (hooray...) I noticed that some
> tests
> > in T610 started to fail independent of that. It seems that with notmuch
> > 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()`
> > returns properties in a different order, while the tests expect a
> specific
> > order. So I'm wondering:
> > - Is there a particular order which the interface promises to deliver?
> > - If yes: What could cause it to be different?
> > If not there's some work to do making the tests independent of the order
> ...
> > This is not glib again, is it?
>
> Can you try the following patch?
>
> diff --git a/lib/string-map.c b/lib/string-map.c
> index e3a81b4f..99bc2ea2 100644
> --- a/lib/string-map.c
> +++ b/lib/string-map.c
> @@ -86,10 +86,14 @@ _notmuch_string_map_append (notmuch_string_map_t *map,
> static int
> cmppair (const void *pa, const void *pb)
> {
> +int cmp = 0;
> notmuch_string_pair_t *a = (notmuch_string_pair_t *) pa;
> notmuch_string_pair_t *b = (notmuch_string_pair_t *) pb;
>
> -return strcmp (a->key, b->key);
> +cmp = strcmp (a->key, b->key);
> +if (cmp == 0)
> + cmp = strcmp (a->value, b->value);
> +return cmp;
> }
>
> static void
>
So I guess we did not quite sort completely before, ey? ;-)
That patch makes T610 pass again, thanks. It's a good change independent of
any glibc promises, I think.
Glad we got this sorted out!
Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T610 failing on Fedora rawhide
* David Bremner: > Michael J Gruber writes: > >> during my first tests for Python 3.13 (hooray...) I noticed that some tests >> in T610 started to fail independent of that. It seems that with notmuch >> 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()` >> returns properties in a different order, while the tests expect a specific >> order. So I'm wondering: >> - Is there a particular order which the interface promises to deliver? >> - If yes: What could cause it to be different? >> If not there's some work to do making the tests independent of the order ... >> This is not glib again, is it? > > The order is the result of sorting the keys (property names) using the > system qsort. So the first is potentially explicable, but the second > suggests a strange (to me) collation order. Do you happen to know the > locale used by these runs? > > Ultimately the comparisons are done with strcmp (string-map.c). strcmp doesn't follow the locale. The qsort in glibc was never a stable sort, but it looked like that in many cases. The version currently in Fedora rawhide (from the upcoming glibc upstream version) shows non-stable sorting behavior in more cases. The test case uses identical sort keys (testkey1, testkey 3), which is why its output changes. Still this is useful feedback. Maybe our qsort was a mostly stable sort for so long that it's now part of the interface contract. Thanks, Florian ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T610 failing on Fedora rawhide
Michael J Gruber writes:
> Hi there,
>
> during my first tests for Python 3.13 (hooray...) I noticed that some tests
> in T610 started to fail independent of that. It seems that with notmuch
> 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()`
> returns properties in a different order, while the tests expect a specific
> order. So I'm wondering:
> - Is there a particular order which the interface promises to deliver?
> - If yes: What could cause it to be different?
> If not there's some work to do making the tests independent of the order ...
> This is not glib again, is it?
Can you try the following patch?
diff --git a/lib/string-map.c b/lib/string-map.c
index e3a81b4f..99bc2ea2 100644
--- a/lib/string-map.c
+++ b/lib/string-map.c
@@ -86,10 +86,14 @@ _notmuch_string_map_append (notmuch_string_map_t *map,
static int
cmppair (const void *pa, const void *pb)
{
+int cmp = 0;
notmuch_string_pair_t *a = (notmuch_string_pair_t *) pa;
notmuch_string_pair_t *b = (notmuch_string_pair_t *) pb;
-return strcmp (a->key, b->key);
+cmp = strcmp (a->key, b->key);
+if (cmp == 0)
+ cmp = strcmp (a->value, b->value);
+return cmp;
}
static void
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T610 failing on Fedora rawhide
David Bremner writes: > Michael J Gruber writes: > >> during my first tests for Python 3.13 (hooray...) I noticed that some tests >> in T610 started to fail independent of that. It seems that with notmuch >> 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()` >> returns properties in a different order, while the tests expect a specific >> order. So I'm wondering: >> - Is there a particular order which the interface promises to deliver? >> - If yes: What could cause it to be different? >> If not there's some work to do making the tests independent of the order ... >> This is not glib again, is it? > > The order is the result of sorting the keys (property names) using the > system qsort. So the first is potentially explicable, but the second > suggests a strange (to me) collation order. Do you happen to know the > locale used by these runs? > > Ultimately the comparisons are done with strcmp (string-map.c). OK, I misread the output (there seems to be some confusing line wrapping). The test with #= is not actually a key, just a line marker. The underlying problem seems to be the same: qsort behaving differently, or perhaps (but less likely, I think) different input to qsort from Xapian. We could force the output to be stable by sorting on lexicographic order (include the property value in the comparison). ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T610 failing on Fedora rawhide
Michael J Gruber writes: > during my first tests for Python 3.13 (hooray...) I noticed that some tests > in T610 started to fail independent of that. It seems that with notmuch > 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()` > returns properties in a different order, while the tests expect a specific > order. So I'm wondering: > - Is there a particular order which the interface promises to deliver? > - If yes: What could cause it to be different? > If not there's some work to do making the tests independent of the order ... > This is not glib again, is it? The order is the result of sorting the keys (property names) using the system qsort. So the first is potentially explicable, but the second suggests a strange (to me) collation order. Do you happen to know the locale used by these runs? Ultimately the comparisons are done with strcmp (string-map.c). ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
