Open akrherz opened 2 months ago
@akrherz, thanks for making this issue.
Good grief, I fouled this up with #917 and #919 both targeting the v3.7.x branch. I need to submit a PR to fix this in main branch
I haven't seen any downstream libgdal=3.9 migrations yet, I suspect we'll need to go downstream and disable ppc64le
builds there as well? Uffties.
I suspect we'll need to go downstream and disable
ppc64le
builds there as well?
Kind of annoying if that must be done manually, and there's no automated way of doing that for all reverse dependencies. Otherwise, maybe skipping the tests for pyproj on ppc64le could be simpler after all, and just live with the fact that it may be partly broken on that arch for some use cases?
If we want to go back to just letting ppc64le be broken, we would need to open that up again as an issue to discuss on the proj.4 feedstock, I guess.
I see geotiff is now skipping ppc64le with conda-forge/geotiff-feedstock#65 , so I guess, I will start doing some downstream of GDAL's and reference back to this issue...
Thanks @akrherz for pro-actively opening all those PRs! Looking at the 'Not solvable' section under https://conda-forge.org/status/migration/libgdal39, it should be just gz-common
and pygplates
remaining.
https://github.com/conda-forge/proj.4-feedstock/pull/141 https://github.com/conda-forge/proj.4-feedstock/pull/143 https://github.com/conda-forge/admin-requests/pull/981 Originally, we had tried skipping the failing test in proj4, but that just caused problems downstream in pyproj: https://github.com/conda-forge/pyproj-feedstock/pull/148
There was a general consensus that the failing test could not be safely skipped and ultimately would need to be addressed but that we didn't have the bandwidth and/or expertise. Some also felt that too much precious maintainer time was being wasted on a rare and exotic architecture.
Originally posted by @xylar in https://github.com/conda-forge/gdal-feedstock/issues/917#issuecomment-2102828795