On Fri, 4 Aug 2023 08:47:23 +0200 Gianfranco Costamagna
<locutusofb...@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
