-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test that fails on ppc64le #137
Conversation
This tries to reproduce conda-forge/pyproj-feedstock#139 using only PROJ. Unfortunately, this won't directly yield an error, but will produce incorrect values if it fails.
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Hrmph, that gave the expected: |
I commented on the pyproj PR referenced above, but the pyproj test has an xfail on a specific PROJ version 9.1.1:
|
Sorry, didn't realize conda-forge is well past the version being checked in this xfail. I'd also like to link this PR to conda-forge/pyproj-feedstock#144 |
- echo -105 40 | proj +proj=utm +zone=13 +ellps=WGS84 | ||
- echo -117 30 | cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83 | ||
- echo -105 40 | cs2cs +init=epsg:4326 +to +init=epsg:2975 | ||
- echo -92.199881 38.56694 | proj EPSG:26915 | cs2cs EPSG:26915 +to EPSG:26715 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on conda-forge/pyproj-feedstock#144, the first command below should give the wrong answer (second component at about -3.54). I run it first because I noticed in pyproj testing that running cs2cs
changes the results of later operations (at least in pyproj).
- echo -105 40 | proj +proj=utm +zone=13 +ellps=WGS84 | |
- echo -117 30 | cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83 | |
- echo -105 40 | cs2cs +init=epsg:4326 +to +init=epsg:2975 | |
- echo -92.199881 38.56694 | proj EPSG:26915 | cs2cs EPSG:26915 +to EPSG:26715 | |
- echo 569704.57 4269024.67 | cs2cs EPSG:26915 +to EPSG:26715 | |
- echo -105 40 | proj +proj=utm +zone=13 +ellps=WGS84 | |
- echo -117 30 | cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83 | |
- echo -105 40 | cs2cs +init=epsg:4326 +to +init=epsg:2975 | |
- echo -92.199881 38.56694 | proj EPSG:26915 | cs2cs EPSG:26915 +to EPSG:26715 |
Could someone tell me why this feedstock uses the |
@djhoese, the answer is that this feedstock is emulating ppc64le on linux64: pyproj is not emulating, it's running on ppc6rle CI using Travis CI: This might explain differences you're seeing. We could try to build natively here but I believe we switched to emulation because the Travis CI jobs were timing out. We could switch to emulation on pyproj, with the downside that we would potentially lose testng. @conda-forge/proj-4, please correct me if anything I said is nonsense! |
It looks like the switch to cross-compiling happened inadvertently via a bot change in #128. Perhaps we want to switch it back. |
Thanks @xylar. FYI the test I proposed in my comment fails locally:
with these changes:
Not sure where the But for the results, note how the same command outputs two different results. First:
then:
|
Perhaps off topic, but since you mentioned the libtiff PR @xylar, I've noticed a libtiff linking error on Python 3.8 (probably not supported by conda-forge anymore?) on MacOS when importing pyproj. |
@xylar How do I put it back to match pyproj's build process? I could test it locally so we can ignore travis limits and see if it actually fixes things. |
@conda-forge-admin, please rerender. |
What I've just done should hopefully take care of that once the rerender happens. |
I think it would be better to open an issue for that. I'm afraid it will get lost here. |
Python 3.8 is still supported, at least for now. |
…nda-forge-pinning 2023.10.14.15.41.10
I replicated the changes here and re-rendered and I see the same incorrect results with the ppc64le image being used. |
FYI I tried other EPSG codes and it seems these ones specifically are initializing something and it gives the wrong results the first time. The other EPSG codes run first in the output below return the same result between executions, but the old EPSG codes I've been using this whole time are wrong the first time, correct the second time:
This may have gotten to the point that I need to try building PROJ without the conda infrastructure and see if I can reproduce it. I guess I could at least file a bug with the information I have so far. |
@xylar I'll make another PR for the test I've put together since I don't have any permissions to this PR and I can do some more testing with conda-forge's CI. On the referenced PROJ issue above it was determined that the ppc64le emulation is actually the problem and Even was able to setup their Travis CI with a native ppc64le system and their version of my tests pass. Is there a conda-forge compatible way for me to do this without suddenly charging conda-forge a ton of Travis credits for something that isn't in the existing contract/plan? |
You don't need to worry about this. Anything you do is in the noise on the scale of conda-forge and our resources are free. You might just have to sit in the queue. |
This tries to reproduce conda-forge/pyproj-feedstock#139 using only PROJ. Unfortunately, this won't directly yield an error, but will produce incorrect values if it fails.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)