arm64 test failures during debbuild

[scpeters]

There were some arm64 test failures when building 6.6.0 debs that were successful when building 6.5.0.

• https://build.osrfoundation.org/job/ign-math6-debbuilder/675/console
• https://build.osrfoundation.org/job/ign-math6-debbuilder/682/console
• https://build.osrfoundation.org/job/ign-math6-debbuilder/684/console

[ RUN      ] PoseTest.OperatorStreamOut
/var/lib/jenkins/workspace/ign-math6-debbuilder/build/ignition-math-6.6.0/src/Pose_TEST.cc:155: Failure
Expected equality of these values:
  stream.str()
    Which is: "0.1 1.2 2.3 -0 0.1 1"
  "0.1 1.2 2.3 0 0.1 1"
[  FAILED  ] PoseTest.OperatorStreamOut (11 ms)

I'm not sure what has changed to cause this because the difference between 6.5.0 and 6.6.0 is only #158, which is unrelated to this test failure.

[scpeters]

testing with gazebo-tooling/action-gz-ci@314bdf6 and dccb189

[j-rivero]

I'm not sure what has changed to cause this because the difference between 6.5.0 and 6.6.0 is only #158, which is unrelated to this test failure.

I've used the debian patching system to get one fix I needed to do in Debian packaging to avoid the remove of Gazebo some weeks ago.

root of the problem is that the different platform optimizations can end up in a negative zero so when we compare the strings the result does not match because of the signal. We probably want to implement a method of comparing it more robust.

[j-rivero]

Thinking on the solution for this, I have some doubts: does it make any sense that a Pose returns a negative 0.0 as a stream result? Does it make sense that a Vector or Quaternion use negative zeros instead of just unsigned zeros? //cc @scpeters @azeey

[azeey]

I would vote for fixing the stream operators to check if the value is zero and output an unsigned zero. I've used std::fpclassify for this in sdformat.

https://github.com/osrf/sdformat/blob/983e8fae73ace20897c97dffacbd00fb0ec01ccc/src/parser_urdf.cc#L1113-L1117

[scpeters]

fixed by #206