Subject: bug#76550: 30.1; Test failure for fns-tests-collate-strings with musl libc

From: Ulrich Müller <[email-masked]>
Date: Wed, 26 Feb 2025 15:44:43 +0100

>>>>> On Wed, 26 Feb 2025, Eli Zaretskii wrote:

> If you insist to not have this test fail (is it really a problem?),
> then why not do it cleanly?

Tests are enabled in Gentoo, so we have to disable any failing tests
in our ebuild. IIUC the only method is via EXCLUDE_TESTS which operates
on the file level, i.e. disabling one specific test isn't even possible.
So yes, it is a problem.

> But okay, matching the system-configuration string might also be okay,

In fact, I went with the documentation of system-type in the lispref
manual:

| If you need to make a finer distinction than ‘system-type’ allows for,
| you can test ‘system-configuration’, e.g., against a regexp."

> just add a comment there explaining why we do that.

Sure, can do.

> And please install the change on master, not on the release branch.

Why? I don't see how disabling this test could break anything. (And I'd
really like to have it fixed in the next release.)

>> >> Presumably, the most specific feature check would be for the
>> >> return value of newlocale(3), depending on its second argument.
>> >> Then again, newlocale is called by str_collate (in sysdep.c),
>> >> which in turn is called by string-collate-equalp.
>> >> 
>> >> Effectively, the test checks for the exact feature that we need,
>> >> in order to decide whether the test should be called. :) IMHO it
>> >> is pretty much pointless.
>> 
>> > Sorry, you lost me here.
>> 
>> The test succeeds with glibc, where newlocale checks validity of the
>> locale. And it fails with musl, where newlocale's checks are lenient.
>> So one could say that the test is for a feature of the C library but
>> not for any feature of Emacs.

> Ah, but the code which calls newlocale depends on that validity check.

> Maybe Paul has some comments or suggestions.