Bug#1042023: opm-common: FTBFS on armel and mipsel

[Markus Blatt]

On Fri, 4 Aug 2023 08:47:23 +0200 Gianfranco Costamagna <locutusofborg at debian.org> wrote:
> Hello, if you request with a signed message you can as maintainer get access to porterboxes.
> See e.g. https://lists.debian.org/debian-mentors/2019/04/msg00125.html
> 
> 
> Also I find useful with qemu-user-static and ubuntu-dev-tools installed to debug with
> 
> pbuilder-dist sid armel create
> pbuilder-dist sid armel login
> and then copy-paste do whatever I want in the qemu-created chroot.
> It's slow, but works for most of the tasks I need to solve
> 
> HTH

Dear Gianfranco,

Thank a lot. I ended up using a chroot using qemu and also found an armhf 
machine where I could see the same problems.

It turns out that at least some of tests (e.g. test_AggregateActionxData) fail
due to an std::time_t overflow on 32bit architectures. Chances are that the
rest of the failures is similar.

At upstream we never cared about those because they would seriously limit 
the simulation time. A few years ago I started to add 32bit patches to the Debian 
packages, but then I realized that this would become a very big effort with 
very little gain for the user. It is of course very unfortunate that we did 
not fail when testing before, but that was probably because of missing tests 
and luck.

My proposal is to make our packages and upstream already check for 64bit when 
configuring the packages and remove the binaries of the archictures where this 
happens.

Note that opm-common is more or less a helper package for the other OPM modules. 
For the user the architectures supported by opm-simulators and opm-upscaling 
are what matters. Removing other architectures from helper modules will not 
limit the usability in any major way.

Best,

Markus