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,
Note that this is kind of a duplicate of [0]. I have marked [0] as blocking
this one.
Some further information:
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
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,
Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?
I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement
Hi,
Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?
I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement
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,
the dependency is alread gone version 2023.10+ds-2 and later (unstable). We
just need to wait for their migration to testing.
Best,
Markus
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,
there is already a version (2023.10+ds-2) uploaded to unstable with the
python3-distutils
dependency. We just need to for it's migration.
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,
Am Thu, Nov 23, 2023 at 09:32:31AM +0100 schrieb Sebastian Ramacher:
On 2023-11-12 21:42:20 +0100, Markus Blatt wrote:
Dear Debian release team,
A new upstream release of OPM is available. To ease migration to testing I am
requesting a mini-transition. Uploading to unstable would
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-scie...@lists.debian.org
Dear Debian release team,
A new upstream release of OPM is available. To ease migration to testing I am
requesting a mini-transition.
Package: ftp.debian.org
Severity: normal
Please the remove the version (2022.10+ds-5) that is currently in experimental
as it is much older than the version 2023.04+ds-5 in unstable.
Thanks a lot.
Kind regards,
Markus
Hi,
FYI the binary packages for architecture armel and mispel have now been removed
from unstable.
As the FTBFS is not fixed and never will be I won't close this bug but leave it
as it is.
If other prefer to close it that is of course fine with me.
Cheers,
Markus
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,
Package: ftp.debian.org
Severity: normal
Dear ftpmaster,
for architecture armel the packages is FTBS because its dependency opm-common
is FTBS (see #104203 [1]) and removal for armel was already requested in
#1049463 [2].
Hence please remove the binary packages on architecture armel.
Thanks a
Package: ftp.debian.org
Severity: normal
Dear FTP team,
it was reported in bug #1042023 [1] that the packages is FTBS.
While the failure was when running tests during the build process, the reason
is that upstream does not support 32bit and never will be. That the package is
now failing to
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
Hi Paul,
Am Sun, Apr 16, 2023 at 10:03:07PM +0200 schrieb Paul Gevers:
On 13-04-2023 22:56, Markus Blatt wrote:
None, because no real code is changed
Can you elaborate why this is needed? I confirm I see nothing of interest.
you are right, there are no real changes in here.
The only
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+opm-upscaling (2022.10+ds-4) unstable; urgency=medium
+
+ * Removed stale static benchmarks to really not need git.
+
+ -- Markus Blatt Thu, 09 Mar 2023 13:36:31 +0100
+
+opm-upscaling (2022.10+ds-3) unstable; urgency=medium
+
+ * d/control
missing imported Alberta targets.
+ * d/control: Fixed version string used in binaries.
+
+ -- Markus Blatt Thu, 09 Mar 2023 13:31:04 +0100
+
opm-simulators (2022.10+ds-1) unstable; urgency=medium
* New upstream version 2022.10
diff --git a/debian/control b/debian/control
index 50cb90194
(2022.10+ds-4) unstable; urgency=medium
+
+ * d/(tests/)control: Limit the architectures to known working ones.
+
+ -- Markus Blatt Fri, 24 Mar 2023 09:43:28 +0100
+
+opm-models (2022.10+ds-3) unstable; urgency=medium
+
+ * Release to unstable (no-change)
+
+ -- Markus Blatt Wed, 08 Mar 2023 23:45:45
-material (2022.10+ds-4) unstable; urgency=medium
+
+ * d/(tests/)control: Limit the architectures to known working ones.
+
+ -- Markus Blatt Fri, 24 Mar 2023 09:33:42 +0100
+
+opm-material (2022.10+ds-3) unstable; urgency=medium
+
+ * d/control: Removed unneeded git from Build-Depends.
+
+ -- Markus
; urgency=medium
+
+ * d/control: Removed unneeded git from Build-Depends.
+
+ -- Markus Blatt Wed, 08 Mar 2023 23:49:15 +0100
+
+opm-grid (2022.10+ds-2) experimental; urgency=medium
+
+ * d/control: Bumped standards version to 4.6.2 (no-change)
+
+ -- Markus Blatt Mon, 09 Jan 2023 12:08:19 +0100
-common/2022.10+ds-7
diff --git a/debian/changelog b/debian/changelog
index 0af409a45..a011537d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+opm-common (2022.10+ds-7) unstable; urgency=medium
+
+ * d/control: Limit the architectures to known working ones.
+
+ -- Markus Blatt
Hi,
the archictures to remove are armhf hppa m68k as the title suggests. Not the
ones listed in the body.
Best,
Markus
for the needed architectures (excluding those to be removed).
Best regards,
Markus Blatt
of the latest version is already adapted to
only build successfully for the needed architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).
Best regards,
Markus Blatt
architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).
Best regards,
Markus Blatt
architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).
Best regards,
Markus Blatt
Hi,
I had the same error on my system (Debian 11.6). It seems like the imapd
process runs as the normal user after login. Hence the shared directory
needs to be readable and listable for those:
$ chmod o+xr /etc/courier/shared
did the trick and then on my system working permissions are:
$
Am Sat, Jan 28, 2023 at 12:42:38AM +0100 schrieb Santiago Vila:
El 27/1/23 a las 23:48, Graham Inggs escribió:
As opm-common is no longer in bookworm, this bug is currently unreproducible.
When I wrote "bookworm" I meant "bookworm and above".
Should I change the title so that you don't
Hi guys,
Santiago told me that the machine used for rebuilding would have enough ram.
Well, I beg to differ. At least the machine that he gave me access to only
has 2 GB of RAM and no swap space:
markus@debian-1:~$ LANG=C free
totalusedfree shared buff/cache
Hi,
On Sat, 18 Jul 2020 19:54:07 +0200 Gianfranco Costamagna
wrote:
On Sat, 18 Jul 2020 10:09:34 +0200 Ansgar wrote:
> On Fri, 2020-07-17 at 20:03 +0200, Gianfranco Costamagna wrote:
> > Hello, dune-common is FTBFS in Ubuntu and on systems where there is not
enough ram, because of OOM
Package: g++-12
Version: 12-20220428-1
Severity: important
Dear Maintainer,
I have uploaded my package opm-common to experimental. Buildd shows that
compilation fails on riscv64 with the message:
In file included from /usr/include/fmt/format.h:48,
from
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,
Am Wed, Mar 30, 2022 at 12:22:29PM +0200 schrieb Markus Blatt:
I think I figured out what the issue is. The cmake configuration files of all
opm modules
have an explicit list of libraries that need to be linked with the library of
the module and
this is always used for linking. This list
Hi,
Am Wed, Mar 30, 2022 at 09:45:30AM +0200 schrieb Markus Blatt:
Am Tue, Mar 29, 2022 at 09:28:22PM +0200 schrieb Graham Inggs:
It seems opm-simulators FTBFS in much the same way now after
opm-common has been rebuilt.
I will take a look and try to fix it. It seems there is a reference
Hi,
Am Tue, Mar 29, 2022 at 09:28:22PM +0200 schrieb Graham Inggs:
It seems opm-simulators FTBFS in much the same way now after
opm-common has been rebuilt.
I will take a look and try to fix it. It seems there is a reference to
libpython3.9.so.
Markus
Hi,
I just took a look at the tracker and noticed that opm-common is level 3 and
opm-simulators is level 2. If build attempts for level 3 come after level 2
that migth explain the failure in the logs [1] and opm-common should be in a
level before opm-simulators.
If there is anything that I need
The fix for #1007930 in
https://salsa.debian.org/science-team/dune-common/-/merge_requests/3
fixes this as well.
As I said there might still be breakage due to the scotch transition
in opm-simulators and opm-upscaling.
I have created an MR on salsa which extends the autopkgtest and fixes
the reported issue:
https://salsa.debian.org/science-team/dune-common/-/merge_requests/3
signature.asc
Description: PGP signature
Some explanations:
The autopkgtest of opm-grid creates a DUNE module using duneproject and tries
to build that. This is done to make sure that opm-grid can be used by other
DUNE modules as a DUNE module. Even though opm-grid ships its own
FindMETIS.cmake test the test in autopkgtest should
Attached is a patch that adds libscotchmetis-dev to the autopkgtest
dependencies and will make the test fail.
>From 1cb79dc83e6b1d50604346b39366e4e3bf1a2548 Mon Sep 17 00:00:00 2001
From: Markus Blatt
Date: Fri, 18 Mar 2022 20:14:28 +0100
Subject: [PATCH 1/2] d/tests: Added libscotchmetis-
Package: libdune-common-dev
Version: 2.8.0-3
Severity: important
Tags: upstream
Control: block 1007830 by -1
Dear Maintainer,
If a user creates a DUNE module with the duneproject script on Debian sid with
the package libscotchmetis-dev install, then running CMake will fail in this
module:
--
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:
Dear all,
I have packaged the new release 2021.10-1.
You can find the packages on mentors.debian.org:
https://mentors.debian.net/package/opm-common/
https://mentors.debian.net/package/opm-material/
https://mentors.debian.net/package/opm-grid/
https://mentors.debian.net/package/opm-models/
Hi,
We are still looking for a sponsor for the OPM packages.
FYI: We are about to release the next upstream version 2021.10 and intend to
update the prospective Debian packages (see [0], [1] for all details).
Any comments and recommendations about the current packages are of course
welcome and
Hi
Two additional comments:
These packages depend on dune-common, dune-geometry, dune-grid, dune-istl,
for which Debian is currently uploading new versions to experimental. Therefore
I have also tested the build with the dune packages from experimental.
If it is more suitable for you to have
Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/o/opm-upscaling/opm-
upscaling_2021.04-1.dsc
Changes for the initial release:
opm-upscaling (2021.04-1) unstable; urgency=medium
.
* Initial release (Closes: #987
Package: wnpp
Severity: wishlist
Owner: Markus Blatt
* Package name: opm-common, opm-material, opm-grid, opm-models, opm-
simulators, opm-upscaling
Version : 2021.04
Upstream Author : OPM
* URL : https://www.opm-project.org/
* License : GPL2+/GPL3
Package: libdune-istl-dev
Version: 2.6.0-2
Severity: normal
Dear Maintainer,
I think that libdune-istl-dev should at least recommend libscotchparmetis-dev
(or better: even depend on it like for superlu and libsuitesparse). The
parallel version of the AMG will suffer from scalability issues
On Wed, Aug 05, 2020 at 01:36:23PM +0200, Markus Blatt wrote:
> As I have learned on the German gnucash mailinglist [1], the bug has been
> fixed upstream after version 3.7 appeared.
Sorry, that was only after 3.10, see
https://lists.gnucash.org/pipermail/gnucash-de/2020-June/011642.html
As I have learned on the German gnucash mailinglist [1], the bug has been
fixed upstream after version 3.7 appeared.
The upstream bug report is at [2], and theb corresponding bugfix at [3].
HTH
Markus
[1] https://lists.gnucash.org/pipermail/gnucash-de/2020-June/011639.html
[2]
BTW: currently I am running one the test versions offered by gnucash via
flatpak [1]. Version
org.gnucash.GnuCash//maint-C4.0-98-g82da49efc-D4.0-5-g8eee199
works for me.
I would assume that the current stable version 4.1-1 from
https://flathub.org/apps/details/org.gnucash.GnuCash should also
Package: gnucash
Version: 1:3.4-1
Severity: important
Dear Maintainer,
I am using gnucash for booking with LANG=de_DE.UTF-8 (i.e. in German) and
usually use the report "Steuer-Bericht/ElStEr-Export" for calculating the
entries for my quaterly VAT report. When I open the report "Abwechselnde
Package: libscotch-dev
Version: 5.1.12b.dfsg-2+b1
Severity: normal
Dear Maintainer,
I tried to link to the libraries under
/usr/lib/parmetis-{int64,int32,long}/, but that failed under CMake
with the following errror:
make[1]: *** No rule to make target '/usr/lib/parmetis-int64/liparmetis.so',
Hi,
this actually seems like an upstream problem. netlib adds xerbla.f to
the lapack library, but xerbla is already supposed to be in blas
itself.
The attached patch fixes the problem on my system (Debian
wheezy), by simply not putting xerbla.f into lapack. Please double
check and feel free to
Package: libdune-common-dev
Version: 2.2.0-1
Severity: wishlist
File: libdune-common
Dear Debian Science Team,
we have just released the 2.2.1 version of the DUNE modules. It is
a pure bugfix release and should be fully backward compatible. Would
be perfect if this would be packaged instead of
Package: libatlas-base-dev
Version: 3.8.3-27
Severity: important
When trying to link programs with the static lapack library, the linker does
not find the libs libblasf77.a and libatlas.a because the links to them are
missing in /usr/lib.
This can be resolved by adding
--slave
Hi,
as there was no reaction here for two weeks. I forwarded this
bugreport upstream to the openmpi guys.
It appears to be a known issue which is fixed starting from svn
revision r20674. The patch will be in the next openmpi release.
Cheers,
Markus
--
To UNSUBSCRIBE, email to
Package: libopenmpi-dev
Version: 1.2.7~rc2-2
Severity: important
Hi,
In one of my applications I am using cascaded derived MPI datatypes
created with MPI_Type_struct. One of these types is used to just send
a part (one MPI_Char) of a struct consisting of an int followed by two
chars. I.e, the
Package: libhypre-dev
Version: 1.6.0-4
Severity: important
Hi,
the package includes modified superlu headers, e.g SLU_NC is renamed to NC
in supermatrix.h, which get installed under /usr/include. Therefore
the suplerlu headers under /usr/include are different from the original
superlu
mod_rewrite is activated and if not activate it autmatically.
Cheers,
Markus Blatt
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions
74 matches
Mail list logo
