python-shapely-1.7-3b1.fc33 fails to build on s390x with Python 3.9. Other arches build fine. See https://koji.fedoraproject.org/koji/buildinfo?buildID=1513447 Multiple failures are linked from https://src.fedoraproject.org/rpms/python-shapely/c/a31a3ba9d1e52574dfe26999c5bd99903129e281?branch=master The failure is: ====================================================================== FAIL: test_topological_error (tests.test_iterops.IterOpsTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Shapely-1.7b1/tests/test_iterops.py", line 69, in test_topological_error list(iterops.within(polygon1, [polygon2])) AssertionError: TopologicalError not raised ====================================================================== FAIL: test_binary_predicate_exceptions (tests.test_predicates.PredicatesTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Shapely-1.7b1/tests/test_predicates.py", line 42, in test_binary_predicate_exceptions self.assertRaises(TopologicalError, Polygon(p1).within, Polygon(p2)) AssertionError: TopologicalError not raised by within ====================================================================== FAIL: test_split_line_with_line (tests.test_split.TestSplitLine) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Shapely-1.7b1/tests/test_split.py", line 122, in test_split_line_with_line self.assertTrue(splitter.touches(self.ls)) AssertionError: False is not true ---------------------------------------------------------------------- Ran 225 tests in 0.633s FAILED (failures=3, skipped=1) This blocks the Python 3.9 rebuild of this and all dependent packages: $ repoquery --repo=rawhide{,-source} --whatrequires python3-shapely --recursive cura-1:4.6.1-1.fc33.noarch cura-1:4.6.1-1.fc33.src cura-fdm-materials-0:4.6.1-1.fc33.noarch flatcam-0:8.5-17.20180606git46454c293a9b.fc32.noarch pyosmium-0:3.0.0-1.fc33.src pyproj-0:2.6.1.post1-1.fc33.src python-cartopy-0:0.18.0-1.fc33.src python-descartes-0:1.1.0-14.fc32.src python-fiona-0:1.8.13-4.fc33.src python-geopandas-0:0.7.0-1.fc33.src python-geoplot-0:0.4.0-2.fc33.src python-libpysal-0:4.2.2-1.fc32.src python-mapclassify-0:2.2.0-1.fc33.src python-missingno-0:0.4.2-3.fc33.src python-tilestache-0:1.51.14-3.fc32.src python-trimesh-0:3.6.34-1.fc33.src python-uranium-0:4.6.1-1.fc33.src python3-cartopy-0:0.18.0-1.fc33.x86_64 python3-geopandas-0:0.7.0-1.fc33.noarch python3-geoplot-0:0.4.0-2.fc33.noarch python3-missingno-0:0.4.2-3.fc33.noarch python3-trimesh-all-0:3.6.34-1.fc33.noarch python3-trimesh-easy-0:3.6.34-1.fc33.noarch python3-uranium-0:4.6.1-1.fc33.noarch This is a big stack, hence setting the severity to high. If this is fixed, please rebuild the package in the f33-python target. See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/24UMFCUXDERAP5KAU3QMWQRKOVLSBSJR/ Thanks.
Python 3.9 update: The f33-python side tag is currently being merged. New builds in f33-python are no longer possible, but python3 is not yet updated to Python 3.9 in rawhide. You can check when Python is Python 3.9 with: $ koji wait-repo f33-build --build python3.9-3.9.0~b1-3.fc3 And build the packages normally after that.
If I see right, then nothing changed in python-shapely, but the buildroot is different ... rebuild in F-31 = OK rebuild in F-32 -> same errors as with the rawhide/python-3.9 builds
The python code didn't change, but geos did. The last successful build of python-shapely was on January 31. On March 2, geos 3.8.0 was built for F32+, followed later by geos 3.8.1. There may be an endianness bug in geos 3.8.x.
Or something changed bit width, and the shapely cython code needs to be updated.
Please always regenerate Cython code on build. I sent a PR for it: https://bugzilla.redhat.com/show_bug.cgi?id=1841335 Sadly, it doesn't help the FTBFS :(
The PR link is: https://src.fedoraproject.org/rpms/python-shapely/pull-request/5
*** Bug 1842150 has been marked as a duplicate of this bug. ***
Created attachment 1693859 [details] Demonstration of geos bug The attached file is a C translation of one of the failing python-shapely tests. It shows that the bug is in geos, not python-shapely. Build it with "gcc -o test test.c -lgeos_c". If built and run on a little endian machine, it correctly produces this output: TopologyException: side location conflict at 459 346 The result is 2 If built and run on s390x, it incorrectly produces this output: The result is 0
Created attachment 1693904 [details] C++ version of demonstration This version demonstrates that the bug is in the C++ core of geos, not in the C wrapper that python-shapely uses. Build it like this: "g++ -o test test.cpp -lgeos". You will see warnings, but they can be ignored.
Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (ignatenkobrain). All subpackages of a package agaisnt which this bug was filled are now installable or removed from Fedora 33. Thanks for taking care of it!
Can we temporarily skip the python-shapely 3 failing shapely tests on s390x to unblock handful of packages that might not be affected by this problem?
Since geos is computing incorrect results on s390x, then python-shapely is too. That means that anything sitting on top of python-shapely is likely to fail its test suite on s390x, too, I would think. We should concentrate our efforts on diagnosing and fixing the geos problem. In fact, I tried to do just that, but ran into bug 1842325. If somebody can fix that, I think we should be able to fix the geos bug pretty quickly. Note that I am not a maintainer for either geos or python-shapely. I'm just Random Drive-by User who is trying to lend a hand.
I've noticed two things: 1) The geos spec file does this: %ifarch armv7hl aarch64 s390x ppc64le make test || : %else make test %endif and indeed, many tests fail on s390x. 2) The reason I can't get the C++ pretty printers to work for me so I can debug this issue is that python support was compiled out of gdb due to bug 1829702.
2) Can you debug this on Fedora 32?
Latest geos git still suffers from test failures [1]. Any chance of getting ssh access to a s390x machine to bisect this? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=45318460
(In reply to Sandro Mani from comment #15) > Latest geos git still suffers from test failures [1]. > > Any chance of getting ssh access to a s390x machine to bisect this? > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=45318460 I can arrange access to s390x, send me an email to sharkcz
@Dan Horák Have you received my PM?
(In reply to Sandro Mani from comment #17) > @Dan Horák Have you received my PM? yes, and I have replied the other day, please check your spam box ...
Hmm don't see it anywhere. Can you please resend?
(In reply to Sandro Mani from comment #19) > Hmm don't see it anywhere. Can you please resend? done, sender is dan at danny dot cz
FTR: I'm trying to bisect this trough Koji.
This is what I got: 10ff0f8d6809c212aa9eb75f710bd068a90ccff0 is the first new commit commit 10ff0f8d6809c212aa9eb75f710bd068a90ccff0 Author: Paul Ramsey <pramsey> Date: Fri Dec 14 09:24:28 2018 -0800 Remove references to RobustDeterminant JTS 2fc9fa215cdfff4210ec55cb8c6cfb79618b4ff2 src/algorithm/CGAlgorithmsDD.cpp | 5 +++++ src/algorithm/RayCrossingCounter.cpp | 3 ++- src/algorithm/SIRtreePointInRing.cpp | 3 ++- 3 files changed, 9 insertions(+), 2 deletions(-) I am not available to inspect the commit at this point.
https://git.osgeo.org/gitea/geos/geos/commit/10ff0f8d6809c212aa9eb75f710bd068a90ccff0
(the commit does not rever cleanly on 3.8.1)
I'm also looking into it, the problem is that newly added tests were immediately failing on those arches, so the actual code may have already been broken on those arches way before...
Note that the bisected commit is the one where the test.c reproducer from Jerry starts to give incorrect results on s390x. I.e. I was not bisecting based on unit test results, but only on this one case.
Likely the DD class [1][2] itself being the issue... [1] https://github.com/libgeos/geos/blob/master/include/geos/math/DD.h [2] https://github.com/libgeos/geos/blob/master/src/math/DD.cpp
I've summarized this to https://github.com/libgeos/geos/issues/323 but that is only a mirror. Upstream uses https://trac.osgeo.org/geos/report/1 where I requested an account (pending approval).
(In reply to Sandro Mani from comment #15) > Latest geos git still suffers from test failures [1]. > > Any chance of getting ssh access to a s390x machine to bisect this? > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=45318460 bed36f15c780057ae9b83eb9cd2e8ef6a9ada498 is the fixer of the C reproducer. Not sure if it fixes shapely. Latest goes git still fails tests, but might actually fix shapely tests.
I've opened https://src.fedoraproject.org/rpms/geos/pull-request/2 Could somebody with access to s390x verify it fixes shapely tests? Alternatively, Dan, could you e-mail me the access details?
It looks good, I have used F-32, rebuilt geos with the PR #2, installed the rpms, then built shapely, all tests passed.
Thanks Miro for taking care of this and sorry for not being more responsive, dayjob is keeping me pretty busy at the moment.
Thank you all.