Unit tests fail on s390x (big-endian) about geoalchemy2

[adrien-berchet]

Hi @EdwardBetts

Thanks for your report!

May I ask why you have to run these tests? Also, did they pass with a previous version of GeoAlchemy2?

Anyway, the tests were indeed never meant to run on any platform, especially the big-endian ones. This is because GeoAlchemy2 is mainly a wrapper, so the main point of the tests is to check that the proper functions are called in the DB. So I don't think we need to test on big-endian platforms (and as we can see in the report you posted, the tests only fail when we compare the raw values where endian matters, so it seems to confirm that the proper functions are called, it's just that they don't return the same values as the expected ones but, from a GeoAlchemy2 point of view, it does not really matter). Of course it would be possible to make the tests pass with big-endians but it would be quite long (too much for me at the moment, but any PR to improve this is welcome 😊 ).

[EdwardBetts]

When a Python module is packaged for Debian the tests are run as part of the build process to ensure the package isn't broken in some way.

The tests are also run whenever one of the package dependencies are modified. This is to catch breakages caused by a change to a dependency.

We run the tests on all available architectures to catch architecture specific bugs.

I don't think this is a regression. I don't think the tests were passing with an older version of GeoAlchemy2.

I'm going to modify the Debian package so it doesn't run the failing tests on big-endian architectures.

[adrien-berchet]

Ok, I see, thanks for the explanation.
So yeah I think that just skipping the tests on big-endian architectures is the best option. And it should still be safe since you keep the tests on all other architectures.

Just out of curiosity, do you know which package pulled the GeoAlchemy2 dependency?

[EdwardBetts]

The tests were run on the s390x architecture to check the package worked there. The test run wasn't trigged by another package that depends on GeoAlchemy2.

I checked, there are no packages in Debian that depend on GeoAlchemy2. The dependencies of GeoAlchemy2 are python3-packaging, python3-sqlalchemy and python3.

[adrien-berchet]

Ok.
I'm a bit surprised that GeoAlchemy2 is packaged in Debian just for its own, not because it's pulled by another package as a dependency. But I'm glad to know :-)

[EdwardBetts]

I've built a web-based tool for matching objects with coordinates in OpenStreetMap and Wikidata. The tool is built using GeoAlchemy2. Deploying the tool is easier for me if the dependencies are part of Debian, that's why I packaged GeoAlchemy2.

The tool is here: https://osm.wikidata.link/

[adrien-berchet]

Ah ok ok.
Nice tool btw! I didn't know it.

[adrien-berchet]

Can we consider this issue as solved and close it? Or is there still anything we can do?

[EdwardBetts]

Yes, let's close it.

[adrien-berchet]

Ok, thanks.
See you around!