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

[Zorro Lang]

On Thu, Jul 19, 2018 at 06:21:05PM +0200, Florian Weimer wrote:
> * Zorro Lang:
> 
> > I was trying to change all these things to [:digit:], [:lower:], [:upper:],
> > [:alpha:] and [:alnum:]. But there're many, and the worse thing is there're
> > many things like [1-9], [3-8], [1-9a-f], [0-9a-f-] etc...
> 
> I finally found a summary of the old discussion I tried to recall:
> 
> 
> 
> Ten years on, and we still haven't solved this.
> 
> I think it's time to implement the Rational Range Interpretation
> across all GNU tools.

Thanks Florian, I saw this patch from your team:
https://www.sourceware.org/ml/libc-alpha/2018-07/msg00620.html

I've sent a patch to fstests@, try to avoid this problem:
https://marc.info/?l=fstests=153199466428997=2

We already exported LANG=C and LC_ALL=C, I'm trying to change the
"[a-z]" to "[:lower:]" in Makefile for bypassing this confused
issue. (But yes, I need to wait reviewing :)

> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Florian Weimer]

* Zorro Lang:

> I was trying to change all these things to [:digit:], [:lower:], [:upper:],
> [:alpha:] and [:alnum:]. But there're many, and the worse thing is there're
> many things like [1-9], [3-8], [1-9a-f], [0-9a-f-] etc...

I finally found a summary of the old discussion I tried to recall:



Ten years on, and we still haven't solved this.

I think it's time to implement the Rational Range Interpretation
across all GNU tools.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[spagoveanu]

On Mon, Jul 16, 2018 at 07:48:26AM -0400, Paul Smith wrote:
> On Mon, 2018-07-16 at 15:30 +0800, Zorro Lang wrote:
> > > [root@fedoravm tmp]# ls -l
> > > total 4
> > > -rw-r--r--. 1 root root 206 Jul 15 14:58 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]*/)
> > > default:
> > >  @echo STRING1="$(STRING1)"
> > >  @echo STRING2="$(STRING2)"
> > > [root@fedoravm tmp]# make
> > > STRING1=/root/tmp/testdir/ /root/tmp/Makefile
> > > STRING2=./testdir/ ./Makefile

This is the same bug I've reported (with a working fix) in

http://lists.gnu.org/archive/html/bug-make/2018-06/msg9.html

The '[a-z] matching uppercase chars because of LC_COLLATE' aggravating
"feature" is a red herring here; './[a-z]*/' shouldn't match 'makefile'
either; it should only match directories.

> > > [root@fedoravm tmp]#
> 
> GNU make uses the system libc version of the glob(3) and fnmatch(3)
> functions to implement its wildcard function on any system which
> provides GNU libc.
> 
> So, if there's a change which introduces a problem with wildcard it is
> more likely to be related to the GNU libc implementation of glob() or
> fnmatch().

There is a bug in glibc's glob() implementation. Here is a simple test
case that's doing the exactly same things gnu make is doing to trigger it
(use the GLOB_ALTDIRFUNC extension mechanism and set dirent.d_type
to DT_UNKNOWN). The bug can also be triggered without GLOB_ALTDIRFUNC
by using a filesystem without support for the d_type field (eg. minix fs).

$ cc -Wall -O2 glob_onlydir.c -o glob_onlydir
$ mkdir -p test/dir
$ touch test/file
$ ./glob_onlydir 'test/*'
test/dir
test/file
$ cat glob_onlydir.c
#include 
#include 
#include 
#include 
static void *my_readdir(void *v){
struct dirent *d = readdir(v);
if(d) d->d_type = DT_UNKNOWN;
return d;
}
int main(int ac, char **av){
int i, j;
glob_t g = {0};
g.gl_opendir = (void*(*)(const char*))opendir;
g.gl_closedir = (void(*)(void*))closedir;
g.gl_stat = (int(*)(const char*, void*))stat;
g.gl_lstat = (int(*)(const char*, void*))lstat;
g.gl_readdir = my_readdir;
for(i = 1; i < ac; i++)
if(glob(av[i], GLOB_ONLYDIR|GLOB_ALTDIRFUNC, 0, ) == 0)
for(j = 0; j < g.gl_pathc; j++)
printf("%s\n", g.gl_pathv[j]);
return 0;
}

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Zorro Lang]

On Wed, Jul 18, 2018 at 06:12:05PM +0800, Zorro Lang wrote:
> On Wed, Jul 18, 2018 at 10:47:09AM +0200, Florian Weimer wrote:
> > * Zorro Lang:
> > 
> > > On Wed, Jul 18, 2018 at 08:04:05AM +0200, Florian Weimer wrote:
> > >> * Zorro Lang:
> > >> 
> > >> >> > > This is related to this glibc bug:
> > >> >> > > 
> > >> >> > >   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
> > >> >> 
> > >> 
> > >> > A stranger thing is:
> > >> > egrep [A-Z] match ABCD and bcd, but not match 'a'...
> > >> 
> > >> That's the same issue as [0-9] not matching ９.
> > >> 
> > >> > I already can't understand the new rules ...
> > >> 
> > >> The range operator matches characters according to their collation
> > >> weight, and sincce the weight of 'a' is less than the weight of 'A',
> > >> 'a' is not included in the [A-Z] range.
> > >
> > > How to define/calculate the *weight* in your context? Why you say the
> > > weight of 'a' is less than the weight of 'A'
> > 
> > This is a concept from POSIX collation, based on a locale definition:
> > 
> > I hope this link is reasonably stable:
> > 
> > 
> > 
> > Basically, collation is in alternative way of sorting strings,
> > different from codepoint order, and it is specifically designed to
> > take cultural conventions into account.  Traditionally, most regular
> > expression range expression such as [a-z] follow collation order,
> > although this is not required by POSIX for non-C/non-POSIX locales.
> > 
> > >> This could be fixed by including all characters with the same primary
> > >> weight as the endpoints (so that [ā-ẑ] and [a-z] would end up being
> > >> the same).  It makes the behavior more logical, but it doesn't fix
> > >> existing scripts.
> > >
> > > We find that the $LANG will affect how glibc deal with the wildcard.
> > > We all test on LANG=en_US.UTF=8, but if I set export LANG=C, then
> > > [a-z] and [A-Z] are all as expected, and xfstests make install works.
> > 
> > Right, this is expected: POSIX requires the behavior you need for the
> > "C" locale.
> 
> I was trying to change all these things to [:digit:], [:lower:], [:upper:],
> [:alpha:] and [:alnum:]. But there're many, and the worse thing is there're
> many things like [1-9], [3-8], [1-9a-f], [0-9a-f-] etc...
> 
> So I have to stop, and think about if there's a better way? How about we
> fix the Makefile issue by change [a-z] to [[:lower:]], then export LANG=C
> in xfstests/check file, and recommand export it in local.file?
> 
> Please tell me, if you have better idea.

Another way maybe we can define SED_PROG="LC_ALL=C sed",
GREP_PROG="LC_ALL=C grep" etc ... But Makefile still need to be fixed
singly.


> 
> Thanks so much,
> Zorro
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Zorro Lang]

On Wed, Jul 18, 2018 at 10:47:09AM +0200, Florian Weimer wrote:
> * Zorro Lang:
> 
> > On Wed, Jul 18, 2018 at 08:04:05AM +0200, Florian Weimer wrote:
> >> * Zorro Lang:
> >> 
> >> >> > > This is related to this glibc bug:
> >> >> > > 
> >> >> > >   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
> >> >> 
> >> 
> >> > A stranger thing is:
> >> > egrep [A-Z] match ABCD and bcd, but not match 'a'...
> >> 
> >> That's the same issue as [0-9] not matching ９.
> >> 
> >> > I already can't understand the new rules ...
> >> 
> >> The range operator matches characters according to their collation
> >> weight, and sincce the weight of 'a' is less than the weight of 'A',
> >> 'a' is not included in the [A-Z] range.
> >
> > How to define/calculate the *weight* in your context? Why you say the
> > weight of 'a' is less than the weight of 'A'
> 
> This is a concept from POSIX collation, based on a locale definition:
> 
> I hope this link is reasonably stable:
> 
> 
> 
> Basically, collation is in alternative way of sorting strings,
> different from codepoint order, and it is specifically designed to
> take cultural conventions into account.  Traditionally, most regular
> expression range expression such as [a-z] follow collation order,
> although this is not required by POSIX for non-C/non-POSIX locales.
> 
> >> This could be fixed by including all characters with the same primary
> >> weight as the endpoints (so that [ā-ẑ] and [a-z] would end up being
> >> the same).  It makes the behavior more logical, but it doesn't fix
> >> existing scripts.
> >
> > We find that the $LANG will affect how glibc deal with the wildcard.
> > We all test on LANG=en_US.UTF=8, but if I set export LANG=C, then
> > [a-z] and [A-Z] are all as expected, and xfstests make install works.
> 
> Right, this is expected: POSIX requires the behavior you need for the
> "C" locale.

I was trying to change all these things to [:digit:], [:lower:], [:upper:],
[:alpha:] and [:alnum:]. But there're many, and the worse thing is there're
many things like [1-9], [3-8], [1-9a-f], [0-9a-f-] etc...

So I have to stop, and think about if there's a better way? How about we
fix the Makefile issue by change [a-z] to [[:lower:]], then export LANG=C
in xfstests/check file, and recommand export it in local.file?

Please tell me, if you have better idea.

Thanks so much,
Zorro

> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Florian Weimer]

* Zorro Lang:

> On Wed, Jul 18, 2018 at 08:04:05AM +0200, Florian Weimer wrote:
>> * Zorro Lang:
>> 
>> >> > > This is related to this glibc bug:
>> >> > > 
>> >> > >   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
>> >> 
>> 
>> > A stranger thing is:
>> > egrep [A-Z] match ABCD and bcd, but not match 'a'...
>> 
>> That's the same issue as [0-9] not matching ９.
>> 
>> > I already can't understand the new rules ...
>> 
>> The range operator matches characters according to their collation
>> weight, and sincce the weight of 'a' is less than the weight of 'A',
>> 'a' is not included in the [A-Z] range.
>
> How to define/calculate the *weight* in your context? Why you say the
> weight of 'a' is less than the weight of 'A'

This is a concept from POSIX collation, based on a locale definition:

I hope this link is reasonably stable:



Basically, collation is in alternative way of sorting strings,
different from codepoint order, and it is specifically designed to
take cultural conventions into account.  Traditionally, most regular
expression range expression such as [a-z] follow collation order,
although this is not required by POSIX for non-C/non-POSIX locales.

>> This could be fixed by including all characters with the same primary
>> weight as the endpoints (so that [ā-ẑ] and [a-z] would end up being
>> the same).  It makes the behavior more logical, but it doesn't fix
>> existing scripts.
>
> We find that the $LANG will affect how glibc deal with the wildcard.
> We all test on LANG=en_US.UTF=8, but if I set export LANG=C, then
> [a-z] and [A-Z] are all as expected, and xfstests make install works.

Right, this is expected: POSIX requires the behavior you need for the
"C" locale.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Zorro Lang]

On Wed, Jul 18, 2018 at 08:04:05AM +0200, Florian Weimer wrote:
> * Zorro Lang:
> 
> >> > > This is related to this glibc bug:
> >> > > 
> >> > >   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
> >> 
> 
> > A stranger thing is:
> > egrep [A-Z] match ABCD and bcd, but not match 'a'...
> 
> That's the same issue as [0-9] not matching ９.
> 
> > I already can't understand the new rules ...
> 
> The range operator matches characters according to their collation
> weight, and sincce the weight of 'a' is less than the weight of 'A',
> 'a' is not included in the [A-Z] range.

How to define/calculate the *weight* in your context? Why you say the
weight of 'a' is less than the weight of 'A'

> 
> This could be fixed by including all characters with the same primary
> weight as the endpoints (so that [ā-ẑ] and [a-z] would end up being
> the same).  It makes the behavior more logical, but it doesn't fix
> existing scripts.

We find that the $LANG will affect how glibc deal with the wildcard.
We all test on LANG=en_US.UTF=8, but if I set export LANG=C, then
[a-z] and [A-Z] are all as expected, and xfstests make install works.

Thanks,
Zorro

> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Zorro Lang]

On Wed, Jul 18, 2018 at 11:47:49AM +0800, Zorro Lang wrote:
> On Wed, Jul 18, 2018 at 11:15:15AM +0800, Zorro Lang wrote:
> > 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
> 
> Hi Florian,
> 
> Sorry I just saw your internal reply in Red Hat. If you'd like to talk
> about this issue at here, I have to say this change is radical.
> 
> Before, we can do this:
> # echo abcd > testfile
> # echo ABCD >> testfile
> # egrep  [a-z] testfile
> abcd
> 
> But now it becomes this suddently:
> # echo abcd > testfile
> # echo ABCD >> testfile
> # egrep  [a-z] testfile
> abcd
> ABCD

A stranger thing is:
egrep [A-Z] match ABCD and bcd, but not match 'a'...

I already can't understand the new rules ...

> 
> I'm afraid that we will get many complaints from customers ... And of
> course it will break many cases and tools.
> 
> Thanks,
> Zorro
> 
> > > 
> > > 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.
> > > 
> > > I dimly recall earlier discussions regarding this matter quite some
> > > time ago, perhaps in the POSIX context.  GNU grep appears to have a
> > > workaround for [0-9], but not [a-z].  Cc:ing Jim Meyering in case he
> > > has any insights.
> > 
> > JFYI:
> > 
> > I reported this bug to glibc bugzilla too, and I got some responses
> > as below:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=23420#c1
> > 
> > Hmm... is Fedora glibc much different with upstream ... Need more
> > investigate.
> > 
> > Thanks,
> > Zorro
> > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Florian Weimer]

* Zorro Lang:

>> > > This is related to this glibc bug:
>> > > 
>> > >   https://sourceware.org/bugzilla/show_bug.cgi?id=23393
>> 

> A stranger thing is:
> egrep [A-Z] match ABCD and bcd, but not match 'a'...

That's the same issue as [0-9] not matching ９.

> I already can't understand the new rules ...

The range operator matches characters according to their collation
weight, and sincce the weight of 'a' is less than the weight of 'A',
'a' is not included in the [A-Z] range.

This could be fixed by including all characters with the same primary
weight as the endpoints (so that [ā-ẑ] and [a-z] would end up being
the same).  It makes the behavior more logical, but it doesn't fix
existing scripts.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Dave Chinner]

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
da...@fromorbit.com

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Florian Weimer]

* 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.

I dimly recall earlier discussions regarding this matter quite some
time ago, perhaps in the POSIX context.  GNU grep appears to have a
workaround for [0-9], but not [a-z].  Cc:ing Jim Meyering in case he
has any insights.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Zorro Lang]

On Tue, Jul 17, 2018 at 03:24:08PM +1000, Dave Chinner wrote:
> On Sun, Jul 15, 2018 at 03:11:10PM +0800, Eryu Guan wrote:
> > On Sun, Jul 15, 2018 at 03:43:20PM +1000, Dave Chinner wrote:
> > > On Thu, Jul 12, 2018 at 12:39:21AM +0800, Eryu Guan wrote:
> > > > The "wildcard" part is supposed to find all subdirs in tests dir, e.g.
> > > > "tests/ext4 tests/generic tests/xfs ...", files shouldn't be included.
> > > > So we get subdir list and go into each subdir and do install there.
> > > > 
> > > > But the same "wildcard" expression returns files too on fedora 28, e.g.
> > > > "tests/Makefile tests/ext4 tests/generic tests/xfs ...", as a result,
> > > 
> > > Should *never* return tests/Makefile, because that does not match
> > > the [a-z]* regex - it's a lowercase first character match, not
> > > uppercase. And the *only* things that should be in tests/ is the
> > > Makefile and all the test subdirs, so it shouldn't be matching the
> > > wrong thing. i.e. how are we getting tests/ as a result in the
> > > TESTS_SUBDIRS set?
> > 
> > That's why I think it's a bug of make. I did the following test on
> > Fedora 28 with make-4.2.1-6.fc28.x86_64.
> > 
> > [root@fedoravm tmp]# rpm -q make
> > make-4.2.1-6.fc28.x86_64
> > [root@fedoravm tmp]# pwd
> > /root/tmp
> > [root@fedoravm tmp]# ls -l
> > total 4
> > -rw-r--r--. 1 root root 206 Jul 15 14:58 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]*/)
> > default:
> > @echo STRING1="$(STRING1)"
> > @echo STRING2="$(STRING2)"
> > [root@fedoravm tmp]# make
> > STRING1=/root/tmp/testdir/ /root/tmp/Makefile
> > STRING2=./testdir/ ./Makefile
> > [root@fedoravm tmp]#
> 
> So make 4.2.1 on fedora 28 has broken regex matching?
> 
> I just ran this on a debian based test machine:
> 
> $ make --version
> GNU Make 4.1
> 
> $ make
> STRING1=/home/dave/tmp_make/testdir/
> STRING2=./testdir/
> $
> 
> That works, but it's old. I just upgraded it to the lastest unstable
> package (4.2.1-1.1), which also upgraded glibc to 2.27-5. Looks like
> the make version matches fedora 28, but:
> 
> $ make --version
> GNU Make 4.2.1
> 
> $ make
> STRING1=/home/dave/tmp_make/testdir/
> STRING2=./testdir/
> $
> 
> the regex behaves correctly. So this looks like it might be
> something isolated to the fedora 28 distro package build or glibc
> version?

>From my testing:
1) make-4.2.1-4 built by glibc-2.26 works fine with glibc-2.26-27.
2) make-4.2.1-7 built by glibc-2.27 reproduce this bug with glibc-2.27-30.
3) make-4.2.1-4 built by glibc-2.26 reproduce this bug with glibc-2.27-30.
   Downgrade make forcibly by:
   # rpm -e --nodeps make
   # yum install make-4.2.1-4.xxx.rpm

Thanks,
Zorro

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Eryu Guan]

On Mon, Jul 16, 2018 at 07:48:26AM -0400, Paul Smith wrote:
> On Mon, 2018-07-16 at 15:30 +0800, Zorro Lang wrote:
> > > [root@fedoravm tmp]# ls -l
> > > total 4
> > > -rw-r--r--. 1 root root 206 Jul 15 14:58 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]*/)
> > > default:
> > >  @echo STRING1="$(STRING1)"
> > >  @echo STRING2="$(STRING2)"
> > > [root@fedoravm tmp]# make
> > > STRING1=/root/tmp/testdir/ /root/tmp/Makefile
> > > STRING2=./testdir/ ./Makefile
> > > [root@fedoravm tmp]#
> 
> GNU make uses the system libc version of the glob(3) and fnmatch(3)
> functions to implement its wildcard function on any system which
> provides GNU libc.
> 
> So, if there's a change which introduces a problem with wildcard it is
> more likely to be related to the GNU libc implementation of glob() or
> fnmatch().
> 
> Unless you've somehow compiled GNU make to use its internal version of
> GNU glob()/fnmatch() instead of the system version.
> 
> I filed a bug about this with GNU libc a long time ago, and it was
> apparently fixed in GNU libc 2.19 in 2014.  So, I'm not sure why you've
> just started seeing it now.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=10278

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.

Thanks,
Eryu

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul Smith]

On Mon, 2018-07-16 at 15:30 +0800, Zorro Lang wrote:
> > [root@fedoravm tmp]# ls -l
> > total 4
> > -rw-r--r--. 1 root root 206 Jul 15 14:58 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]*/)
> > default:
> >  @echo STRING1="$(STRING1)"
> >  @echo STRING2="$(STRING2)"
> > [root@fedoravm tmp]# make
> > STRING1=/root/tmp/testdir/ /root/tmp/Makefile
> > STRING2=./testdir/ ./Makefile
> > [root@fedoravm tmp]#

GNU make uses the system libc version of the glob(3) and fnmatch(3)
functions to implement its wildcard function on any system which
provides GNU libc.

So, if there's a change which introduces a problem with wildcard it is
more likely to be related to the GNU libc implementation of glob() or
fnmatch().

Unless you've somehow compiled GNU make to use its internal version of
GNU glob()/fnmatch() instead of the system version.

I filed a bug about this with GNU libc a long time ago, and it was
apparently fixed in GNU libc 2.19 in 2014.  So, I'm not sure why you've
just started seeing it now.

https://sourceware.org/bugzilla/show_bug.cgi?id=10278

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make