Re: [Bug-wget] wget IRI test failures on Mac OS X

[Tim Rühsen]

Am Mittwoch, 18. Mai 2016, 20:51:16 schrieb Eli Zaretskii:
> > From: Ryan Schmidt <address@hidden>
> > Date: Wed, 18 May 2016 02:39:56 -0500
> > Cc: address@hidden
> 
> > Thanks Eli. I tried the latest commit from April 2016, 
42cc84b6b6cceeb146a668797ceaafe60743ce6d, and the IRI tests still failed:
> Does OS X have a function that can compare equal strings with composed
> and decomposed characters that are equivalent sequences?

Is it a Mac OSX issue or a HFS+ issue ?

I generated a HFS+ filesystem image via loopback device on GNU/Linux. Building 
and testing Wget on this filesystem suffers from same (or similar) problems.

Since we are also talking about a Perl code issue, we could need functions 
from Unicode::Normalize (see 
http://search.cpan.org/~khw/Unicode-Normalize-1.25/Normalize.pm).

When comparing the utf-8 filenames from the 'expected_downloaded_files' list 
with the filenames from disk, we should 'normalize' both arguments. Or maybe 
there is a compare function doing this already !?

Here is my recipe to buld+test wget on a HFS+ filesystem (Debian):

$ sudo apt-get install hfsprogs

$ dd if=/dev/zero of=hfsimage bs=512 count=500k
$ sudo losetup /dev/loop0 hfsimage
$ sudo mkfs -t hfsplus /dev/loop0
$ sudo mount -t hfsplus /dev/loop0 /mnt

$ cd /mnt
$ sudo git clone git://git.sv.gnu.org/wget.git
$ sudo chown -R tim:users wget
$ cd wget
$ ./bootstrap
$ ./configure
$ make 
$ make check


Maybe that helps.

Tim

signature.asc
Description: This is a digitally signed message part.