[PATCH] Prefer /dev/shm over /tmp in utime family tests

[Adhemerval Zanella]

On 10/03/2021 05:55, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 08/03/2021 14:43, Florian Weimer wrote:
>>> * Adhemerval Zanella via Libc-alpha:
>>>
>>>> What instead we make libsupport to use builddir as the temporary base
>>>> directory instead? So all temporary files, directories, pipe, etc. would
>>>> be created and tests against a user-defined directory instead of a system
>>>> one.
>>>
>>> It doesn't solve the issue with file system variance.  It's worse than
>>> /tmp because that's more likely to be on tmpfs.  If we move the
>>> directory into the build tree, everyone using XFS (that has the
>>> forgetful VFS bug fixed) will end up with lots of FAILs.
>>
>> But it gives to the user at least a way to avoid the issue by
>> specifying where to run and create all the files (even it is a loop
>> device). I really think that having a buggy FS is not the best way to
>> check glibc functionality, where part of tests will use a different
>> system (where there is no direct requirement such as POSIX semaphore
>> due its implementation).
> 
> I want to avoid artificial barriers to new contributors, and additional
> complications for my own work.
> 
> To provide some context: it is difficult for me to contribute to GCC
> because the Dejagnu logs are hard to interpret and contain quite a few
> expected failures which are not marked as such.  We have some problems
> with flaky tests, pretty much like everyone else, but the proposal here
> is to add tests that fail consistently on common distributions.  Quite
> frankly, I find that approach rather hostile.

But it is rather different than using a clunky test framework where you 
don't have a better option. It is a fundamental flaw in the kernel, where
users *should* be warned about and kernel developer should fix is asap, 
not gloss over. 

The idea of providing y2038 interfaces *now* is to actually stress the
possible scenarios where it would fail and warn users and developers of
potential issues.  

I have tested it on different system, mostly based on Debian but also
one on SuSE. So this is more specific a RHEL issue that used XFS as
base and what I would expect is RHEL to fix asap instead of hiding it
on glibc testsuite.

Sorry, but I am unconvinced that we should handle it different than
what we do it now.