Test failure on big endian

[superm1]

I recently attempted to package efivar 39 + 68daa04 and noticed that there was a test failure on s390x.

make[3]: Entering directory '/build/reproducible-path/efivar-39/tests'
testing export to DMPSTORE format
testing export to libefivar format
test.dmpstore.export.result.var test.dmpstore.export.new.goal.var differ: byte 1, line 1
make[3]: *** [Makefile:61: test.dmpstore.export] Error 1
make[3]: *** Waiting for unfinished jobs....

Full log: https://buildd.debian.org/status/fetch.php?pkg=efivar&arch=s390x&ver=39-2&stamp=1755672318&raw=0

[superm1]

CC @apalos

[apalos]

@superm1 I can't find anything relevant in the efitool sources. Can you point me to the actual test? I can't see how the patch would affect s390. The functionality shouldn't even trigger or make any difference

[superm1]

efivar/tests/Makefile

Line 69 in 68daa04

test.efivar.export:

is the test that fails.

[apalos]

efivar/tests/Makefile

Line 69 in 68daa04

test.efivar.export:
is the test that fails.

Thanks. Looking at it, it's unclear why tbh. But I'll find time to have a closer look

[lumag]

I will try applying for s390x access in order to fix this issue.

[lumag]

@superm1 actually... I'm surprised that the dmpstore test passed. It fails both in the tip and in the relase 39: efivar (well all the functions inside export.c use native endianness for storing data (integers and UCS-2 strings), which is then compared to the file stored in the little endianness. It applies to both dmpstore and evifar formats.
I'm not sure, what is correct (native or little endianness).

[superm1]

I guess that means that the bug is not 68daa04 but rather something else from 38 to 39 then?

[apalos]

I guess that means that the bug is not 68daa04 but rather something else from 38 to 39 then?

@superm1 yea, that's what I hinted on my first reply as well. That commit merely fixes a 'special' case to handle variables at runtime and should be irrelevant to the current failure

[lumag]

I guess that means that the bug is not 68daa04 but rather something else from 38 to 39 then?

No, 38 is likewise broken. efivar has always been writing data in the native endianness and then comparing that to LE dumps.
Do we have a spec, defining which endianness should be used for those data formats?

[lumag]

@apalos @superm1 so, do we have a spec defining whether those files should be written in native endianness or in little endianness?

[apalos]

@apalos @superm1 so, do we have a spec defining whether those files should be written in native endianness or in little endianness?

@lumag I don't know if the efivar project defines something, but the EFI spec does not mandate how variables should be stored (format, endianess etc)