[geos-devel] 3.12.0beta2

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel <gdt at lexort.com> wrote:
>> 
>> > Looking at the logs (at end), overall this smells like either a
>> > systematic issue where the floating point on my system is broken, or
>> > there is some slight floating point difference from x86, and geos
>> > tests are very sensitive to exact FP results.  But that's just guessing.
>> 
>> In terms of CI, it's linux/windows/macos all on Intel. In terms of development,
>> there's me on MacOS AppleSilicon, so getting a little
>> Arm64 in there. It's possible there's something special about the floating point
>> in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, which
>> ... is not doing any heavy lifting. So I duno. As with other fun platforms I'm
>> always open to patches. :)
>
> We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - berrie and berrie64
> And those look to be showing successes.  But not sure about the endian.
>
> https://libgeos.org/project/development/ci_status/

Interesting.  Raspberry Pi culture is very much to run LE, and I have
never heard of Debian doing BE on RPI.  NetBSD people do occasionally,
just to be difficult, I mean to help with testing.

> I think we've had issues in past specific to big endian.

I would expect so absent testing.  Someday(tm) I will have an emulated
sparc64 to run tests on.

For now, I think the project should just keep my report in mind in case
there are similar, but I don't think it's reasonable to ask anyone to do
anything, mostly.

My only suggestion for the CI page is:

  Avoid using '32-bit' and '64-bit' as if that describes a CPU type,
  using i386/x86_64 for PCs and armv7/aarch64 (or some such) for
  RPI/ARM.

but that's just being picky about wording, not anything real.