[Pkg-pascal-devel] CGE failing on arm64, mips, mipsel, ppc64 and sparc64

[Michalis Kamburelis]

2017-07-13 20:41 GMT+02:00 Paul Gevers <elbrus at debian.org>:
> Hi Michalis,
>
> May I draw your attention to the Debian build logs for CGE 6.2?
>
> https://buildd.debian.org/status/package.php?p=castle-game-engine
>
> CGE fails on 4 (5) architectures (and succeeds on 6) in slightly
> different ways. Could you shed you light on it and see if there is
> anything we can do (like adding debugging info)?
>
> I seem to recollect that I helped you once to get access to porterboxes
> to investigate some failures in the past. Did that lead to anything?
>

Hi,

Sorry for the late answer!

Looking at the build logs:

1. mips and mipsel: They both fail because they don't have the
freetype library available, and the texture-font-to-pascal utility
relies on it to load ttf files. We open the freetype library
dynamically, by opening "libfreetype.so" or "libfreetype.so.6" (see
CastleInternalFreeTypeH).

  Can you make the Castle Game Engine package Build-Depend on
libfreetype6? It should be available on mips and mipsel, looking at
the bottom of https://packages.debian.org/sid/libfreetype6 .

2. ppc64: Looks like it needs larger epsilon for some floating-point
comparisons. I committed a change that should take care of it to the
engine: https://github.com/castle-engine/castle-engine/commit/2e920b18da8aa9a275186adcb56ab5b10890ce4b.patch
.

  Note that you may need to adjust this patch a bit for CGE 6.2
(vector API changed in the engine this week, so my patch from GitHub
may not be exactly compatible with 6.2 sources). Probably you will
need to rename AssertSameValue->AssertFloatsEqual and
Vector3FromStr->Vector3SingleFromStr to make it compatible with 6.2.

3. arm64: Hm, I don't know, admittedly. Testing on an actual arm64
machine would be needed to debug what's wrong there... It seems that
(all? many?) math operations in CastleScript fail for some reason.

In the past you indeed helped me get access for the "porter box" with
powerpc32 and powerpc64, and it was fruitful -- I was able to log into
the machine, and create bugreports
https://bugs.freepascal.org/view.php?id=29594 and
https://bugs.freepascal.org/view.php?id=29587 . Thanks to this, these
architectures work now (well, powerpc64 does not fully work yet, as
seen above, but it's getting better :).

So, I would appreciate the access to a porter box for powerpc64 and
arm64 now. Then I could test my patch on powerpc64 (instead of fixing
it "blindly"), and I could actually debug on arm64 what's the problem.
Without it, I don't have right now an idea how to fix the arm64 port
"blindly".

Do you mean my information for this? All of my info (including my key
fingerprint) from the last time is still valid, it is in the mail
"Debian RT: request porter box guest access for Michalis Kamburelis"
you sent on 29.11.2015.

Regards,
Michalis