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=