Hi,
the problem already appears in OpenMPI's own autopkgtests, see [1]
Best,
Markus
[1] https://ci.debian.net/packages/o/openmpi/unstable/i386/46207866/
Source: openmpi
Version: 4.1.6-13
Severity: serious
Justification: unkown
Control: affects -1 src:dune-grid
Dear Maintainer,
I just uploaded a new version of package dune-grid and noticed that none of our
parallel tests start successfully on 32bit
architectures.
2/66 Test #2: scsgmappertest
Hi,
the problem occurs during startup of OpenMPI when running mpirun. I see similar
problems for other packages during the same rebuild.
Hence I don't think this is related to us but rather to OpenMPI.
Best,
Markus
Hi,
seems like upstream already has a proposed fix, see [1]
Best,
Markus
[1] https://gitlab.kitware.com/vtk/vtk/-/issues/19258#note_1510307
Hi.
I tried to follow this up a bit. Looking at the upstream expat bugs [1] [2]
it might very well be that vtk9 was relying in internals of expat's xml
processing and their assumptions broke when moving to 2.6.0.
Hence this probably is an incompatibility on vtk9's side rather than a bug in
Hi,
One of the DUNE developers has some more insight on this:
https://gitlab.dune-project.org/core/dune-grid/-/issues/184#note_135809
This looks like being the same problem that I noted for Paraview on
ubuntu. It seems that a bugfix in the xml-parser `expat` broke parsing
binary data. Debian
Hi,
I did some further tests with the provided test case.
If I install vtk (latest version 9.3) with pip in a venve. The script also does
not report an error for the relative paths. Tested on stable and in a sid
chroot.
Best,
Markus
Hi,
these tests write out vtk files and read them in using python3-vtk9.
If parsing of the file succeeds then the test was successful.
How the files are written did not change between Debian stable and Debian sid.
I have verified that the files are the same.
Attached is a small test case in
Dear all,
I was able to fix the FTBFS by backporting two upstream patches.
You can find my changes in MR [1]. Note that this also adds the
changes for the 64bit time_t transition made in version 3.0.3-1.1
to the repository.
As I am not Debian Developer and not maintaining the alberta, Hence
Hi,
I did look into this shortly. I must admit that I problems seeing what could
fail in this code.
The code reads the second line of a file using using scanf and checks that the
first number read is larger or equal 2.0 and less than or equal 2.2. Strangely
this works for all the other files
Hi,
I have changed opm-common to not build on 32bit architectures anymore
in version 2023.04+ds-3 and requested removal of the binary packages
in #1049463 [1].
Once the binaries are removed we should decrease the severity of this bug
to allow migation of new versions to testing again.
Best,
On Fri, 4 Aug 2023 08:47:23 +0200 Gianfranco Costamagna
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
Thanks a lot for reporting this. We are aware of this but did not find
the time to look into it, yet.
Is there a good howto/instructions how to debug such problems using e.g.
qemu for emulating arm? Or is it possible to gain access to an arm
machine as a Debian Maintainer?
That would help a
removing the rest of OPM.
Please note that in the recently uploaded version 2023.04+ds-1 of opm-common
(containing the failing code) this particular problem is fixed.
Cheers,
Markus Blatt
Package: src:opm-upscaling
Version: 2022.10+ds-4
It turned out the bug was not in opm-grid but in dune-geometry which caused
the build here to fail (see bug #1037631). With the upload of version 2.9.0-3
of dune-geometry we believe that the bug you reported is fixed.
Cheers,
Markus Blatt
As the transition to python3.10 is finished and the missing library
/usr/lib/x86_64-linux-gnu/libpython3.10.so will now be there when running
the autopkgtest, I believe the only thing preventing migration of opm-grid
Version 2021.10-3, is this bug being open. The autpkgtests are green on [1].
I
Dear Paul,
thanks for noticing. You are right the migration was not possible due to
the Python transition.
The problem was a chicken and egg one. And the update of the package was
done to make the python migration possible (by removing remnants of the
old python version from all opm packages).
Hi,
will look into this in more detail tomorrow, but it seems like the problem
might be in dune-common. The error is triggered during a CMake run that
uses FindMETIS.cmake (shipped with libdune-common-dev) and that fails.
Markus
Package: libopenmpi3
Version: 4.1.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I just updated my chroot of cowbuilder to build my own package that runs some
parallel
programs during make test. When these are run I get errors like this
7/27 Test #16:
19 matches
Mail list logo
