Re: [Question] Unicode weirdness breaking tests on ZFS?

On Wed, Nov 17, 2021 at 01:35:32PM -0500, Derrick Stolee wrote:

On 11/17/2021 1:29 PM, Derrick Stolee wrote:

quoted

On 11/17/2021 12:39 PM, Torsten =?unknown-8bit?Q?B=C3=B6gershausen?= wrote:

quoted

On Wed, Nov 17, 2021 at 06:06:13PM +0100, Torsten B??gershausen wrote:

quoted

On Wed, Nov 17, 2021 at 05:12:26PM +0100, Torsten B??gershausen wrote:

quoted

I'll can have a look - just installing in a virtual machine.

So, the virtual machine is up-and-running.

I got 2 messages:

ok 9 - rename (silent unicode normalization) # TODO known breakage vanished
ok 10 - merge (silent unicode normalization) # TODO known breakage vanished

Do you get the same ?

Halfway, I see this:

ok 9 - rename (silent unicode normalization) # TODO known breakage vanished
not ok 10 - merge (silent unicode normalization) # TODO known breakage

Making this even more confusing, my original output shows both of
the TODOs vanishing, but I can't make that happen only running this
test. However, with "prove -j8 t00*.sh" I can get them to both
vanish:

Test Summary Report
-------------------
t0050-filesystem.sh           (Wstat: 0 Tests: 11 Failed: 0)
  TODO passed:   9-10
t0021-conversion.sh           (Wstat: 256 Tests: 41 Failed: 1)
  Failed test:  31
  Non-zero exit status: 1
Files=53, Tests=2896, 15 wallclock secs ( 0.59 usr  0.07 sys + 26.96 cusr 13.95 csys = 41.57 CPU)
Result: FAIL

Should we conclude that the underlying os/zfs is not stable ?
Things don't seem to be reproducable

What Git needs here in t0050 is that stat("ä") behaves the same as stat("a¨"),
when either "ä" or "a¨" exist on disk.
The same for open() and all other file system functions.
("ä" is the precomposed form "a¨" is the decomposed form,
 typically both render to the same glyph on the screen,
 and a hex dump or xxd will show what we had.
 I just use this notation here for illustration)

Should we contact the zfs developers ?