Re: xfstests can't be installed by running make install

[Dave Chinner <david@fromorbit.com>]

On Tue, Jul 17, 2018 at 10:15:47PM +0200, Florian Weimer wrote:
> * Eryu Guan:
> 
> > This problem here doesn't seem the same as the bug above, Fedora 28 has
> > glibc-2.27, which contains the fix for above bug, and the bug is about
> > trailing "/". But the problem here is we're asking for all lower case
> > filenames but wildcard returns upper case names too. e.g.
> >
> > [root@fedoravm tmp]# pwd
> > /root/tmp
> > [root@fedoravm tmp]# ls -l
> > total 4
> > -rw-r--r--. 1 root root   0 Jul 17 10:51 aaa
> > -rw-r--r--. 1 root root   0 Jul 17 10:51 AAA
> > -rw-r--r--. 1 root root 273 Jul 17 10:50 Makefile
> > drwxr-xr-x. 1 root root   0 Jul 15 14:59 testdir
> > [root@fedoravm tmp]# cat Makefile
> > STRING1 = $(wildcard $(CURDIR)/[a-z]*/)
> > STRING2 = $(wildcard ./[a-z]*/)
> > STRING3 = $(wildcard $(CURDIR)/[a-z]*/.)
> > STRING4 = $(wildcard $(CURDIR)/[a-z]*)
> > default:
> >         @echo STRING1="$(STRING1)"
> >         @echo STRING2="$(STRING2)"
> >         @echo STRING3="$(STRING3)"
> >         @echo STRING4="$(STRING4)"
> > [root@fedoravm tmp]# make
> > STRING1=/root/tmp/aaa /root/tmp/AAA /root/tmp/testdir/ /root/tmp/Makefile
> > STRING2=./aaa ./AAA ./testdir/ ./Makefile
> > STRING3=/root/tmp/testdir/.
> > STRING4=/root/tmp/aaa /root/tmp/AAA /root/tmp/testdir /root/tmp/Makefile
> > [root@fedoravm tmp]#
> >
> > STRING4 is asking for all lower file names, but both "AAA" and
> > "Makefile" are returned.
> 
> This is related to this glibc bug:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
> 
> The bug mentions the regular expression [0-9], but it also affects
> patterns like [a-z].  I have not yet looked at fnmatch and glob in
> detail, but based on the report here (and a quick test with “echo
> [a-z]*”), they are affected by the same issue.
> 
> This is ultimately caused by a locale data update which was backported
> into Fedora 28 (glibc 2.27) and its derivatives.  Upstream glibc only
> has this change for version 2.28 (not yet released).  It's currently
> not considered a release blocker, if it's even considered a bug at
> all.

So what you are saying (i.e. "not a bug") is that we should expect
widespread regex breakage in custom scripts when distros roll out
glibc 2.28 because it will break assumptions people have coded into
their scripts and custom code for the past 20+ years?

That sounds like fun. :/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com