Re: Bug#1138623: persalys FTBFS on big endian: pyinstallcheck_DataModel_load test failure

Pranav P <[email protected]> Thu, 4 Jun 2026 10:27:10 +0000
Newsgroups gmane.linux.debian.ports.s390
Message-ID <CO1PR15MB48419848F6E0FCB93CFDE3DEA0102@CO1PR15MB4841.namprd15.prod.outlook.com>
Hi Adrian,=0A=
=0A=
I was looking into this for the past 2 days.=0A=
I will just share what all I found.=0A=
=0A=
So, in the `python/test/DataModel.xml` file, the file path for the two csv =
files (`Housing-prices-Boston.csv` and `table.csv`)=0A=
are hard coded like the following `/home/aroles/Documents/proj_persalys/stu=
dies/Housing-prices-Boston.csv` and=0A=
`/home/aroles/Documents/proj_persalys/studies/table.csv`. This is where the=
 issue starts. Since, this is a hard coded absolute path,=0A=
the program doesn't find these files. Hence for line no. 493 in `lib/src/ba=
se/DataModel.cxx` in the function call=0A=
`ImportedDataset(fileName, inputColumns, outputColumns)`, it throws an exce=
ption and goes into the catch block and hence falls=0A=
back to the `.h5` file. Now the `.h5` file has entries in little endian for=
mat. Hence, in x86 machines, the data is read fine but fails on=0A=
s390x. But the thing is, HDF5 files are supposed to be portable across arch=
itectures (irrespective of endianness). I can see that the=0A=
call is moving into `libOT.so`. So will have to dig deeper over there to se=
e why this is exactly happening.=0A=
=0A=
Meanwhile, I tried correcting the paths (by changing them to relative paths=
). Now the first assertion (line 14 of `t_DataModel_load.py`)=0A=
now passes. This is since that the `.csv` file is being picked up rather th=
an the `.h5` file. But still, the second assertion fails. That is when=0A=
I noticed another thing. The file called `table.csv` doesn't exist within t=
he repo. I am not sure whether that is supposed to be produced=0A=
by another test case or was supposed to uploaded. But since the file is not=
 there the control falls back to the `.h5` file and chaos=0A=
continues.=0A=
=0A=
If there was a `table.csv` file, then changing the path names and uploading=
 this file should fix the issue. Or another work around we=0A=
could do is to add the necessary byte swaps in the `t_DataModel_load.py` fi=
le.=0A=
=0A=
Thanks,=0A=
Pranav=