Bug#813846: postgis FTBFS on hppa and mips architectures - part two (with patch)

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Helge,

Thanks for the patch.

I've disabled the tests for hppa in git, and it will be included in the
next upload.

On 05-02-16 23:34, Helge Deller wrote:
> postgis fails to build because the testcases "ticket" and "wkb" fail, e.g.:
> https://buildd.debian.org/status/fetch.php?pkg=postgis&arch=hppa&ver=2.2.1%2Bdfsg-2&stamp=1453419898
> 
> This is a follow-up on debian ticket #810859 and upstream bug 
> https://trac.osgeo.org/postgis/ticket/3426
> 
> The main problem is, that hppa and mips have different representations of the NaN (Not-a-number) floating point values.
> This leads to the testcases failing like this:
> It expects:
> -#1478|010100002001000000000000000000f87f000000000000f87f
> but gets on hppa (and probably mips):
> +#1478|010100002001000000fffffffffffff77ffffffffffffff77f
>  
> To solve it "the simple way", the debian package already excluded mips from running the testcases in debian/rules.
> Attached is a patch which adds hppa to the same exclusion and this is probably the easy way to go in the beginning with the debian package.
> 
> 
> In addition, of course it would be nice to get this finally fixed cleanly upstream so that we can run the testcases on debian for hppa and mips. 
> For that I think the testcases "tickets" and "wkb" would need to be rewritten somehow (I don't know how though!).
> For example, the expected output regress/tickets_expected is generated [e.g. on x86_64] by running ./regress/tickets.sql
> Maybe changing those tests to not output the hexadecimal representation of "empty" points but instead check with postgis sql extensions if a point is "valid/empty" or not and then writing e.g. SUCESS/FAILURE into the output (via SQL commands if it's possible) and compare those strings instead of hex values ?
>  
> I can provide a ssh login to a hppa box if someone from the postgis team wants to test himself.

The upstream issue is still open, and this change was recently included:

https://trac.osgeo.org/postgis/changeset/13707

The isnan tests are more reliable than the string representation of the
NaN values. Something like that may be an option.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1