Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
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/
Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
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 ***Failed0.15 sec -- It looks like pmix_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during pmix_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an PMIX developer): pmix_psquash_base_select failed --> Returned value -46 instead of PMIX_SUCCESS -- [arm-ubc-05:12560] PMIX ERROR: NOT-FOUND in file ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at line 237 [arm-ubc-05:12559] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 716 [arm-ubc-05:12559] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 172 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_init failed --> Returned value Unable to start a daemon on the local node (-127) instead of ORTE_SUCCESS -- -- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: ompi_rte_init failed --> Returned "Unable to start a daemon on the local node" (-127) instead of "Success" (0) -- *** An error occurred in MPI_Init *** on a NULL communicator *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, ***and potentially your MPI job) [arm-ubc-05:12559] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! See [1] for a complete build where the tests using mpirun fail in this way. This happens on these architectures: armel, armhf, i386, hppa Best, Markus [1] https://buildd.debian.org/status/fetch.php?pkg=dune- grid=armel=2.9.0-4=1714724856=0 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openmpi-bin depends on: ii libc62.36-9+deb12u6 ii libevent-core-2.1-7 2.1.12-stable-8 ii libopenmpi3 4.1.4-3+b1 ii openmpi-common 4.1.4-3 ii openssh-client [ssh-client] 1:9.2p1-2+deb12u2 openmpi-bin recommends no packages. Versions of packages openmpi-bin suggests: ii gfortran [fortran-compiler] 4:12.2.0-3 -- no debconf information
Bug#1069492: Seems to be an OpenMPI problem
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
Bug#1064762: Upstream has an incoming fix
Hi, seems like upstream already has a proposed fix, see [1] Best, Markus [1] https://gitlab.kitware.com/vtk/vtk/-/issues/19258#note_1510307
Bug#1065270: Unable to open VTK file with appended data that were fine with previous versions (invalid token in vtkXMLDataParser)
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 assumptions broke when moving to 2.6.0. Hence this probably is an incompatibility on vtk9's side rather than a bug in expat. At least upstream thinks that way in in [1] and closed the bug. The stalled discussion about this in VTK9 can be found in [3]. Should we reassing this to vtk9? Best, Markus [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064762 [1] https://github.com/libexpat/libexpat/issues/857 [2] https://github.com/libexpat/libexpat/issues/840 [3] https://gitlab.kitware.com/vtk/vtk/-/issues/19258
Bug#1064762: Might be an incompatibility of vtk9 with expat/2.6.0
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 expat. At least upstream thinks that way in in [1] and closed the bug. The stalled discussion about this in VTK9 can be found in [3]. Should we reassing this to vtk9? Best, Markus [1] https://github.com/libexpat/libexpat/issues/857 [2] https://github.com/libexpat/libexpat/issues/840 [3] https://gitlab.kitware.com/vtk/vtk/-/issues/19258
Bug#1043227: patch still valid? (opm-common: test failure on ppc64el with -O3)
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 like this then the test passes:
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
namespace Opm { namespace data {
/// Intermediary Protocol to Linearise Per-Connection Flow Rates Into
Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
using sz_t = decltype(InterRegFlow::bufferSize());
const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<< std::distance(begin, end);// << " size="<<
InterRegFlow::bufferSize()<(std::distance(begin, end))
== InterRegFlow::bufferSize();
}
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$
Best,
Markus
Bug#1055857: patch still valid? (opm-common: test failure on ppc64el with -O3)
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 like this then the test passes:
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
namespace Opm { namespace data {
/// Intermediary Protocol to Linearise Per-Connection Flow Rates Into Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
using sz_t = decltype(InterRegFlow::bufferSize());
const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<< std::distance(begin, end);// << " size="<<
InterRegFlow::bufferSize()<(std::distance(begin, end))
== InterRegFlow::bufferSize();
}
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$
Best,
Markus
Bug#1064762: Bug is actually in expat xml-parser
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 sid contains expat 2.6.2 where this is fixed. Ubuntu 23.10 has recently backported a fix to 2.5.0 which broke reading appended data in paraview for me. So the issue reported here may now also effect Ubuntu 23.10. * Bug report for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/expat/+bug/2058415 * Related discussion for arch: https://discourse.paraview.org/t/i-cannot-read-a-vtp-file-i-could-open-yesterday-can-someone-try-to-open-it/13938 * In the debian security tracker for expat one can the the CVEs that * have been fixed in sid but (so far) not in stable and testing. In * Ubuntu the patches for these CVEs have been backported already: * https://security-tracker.debian.org/tracker/source-package/expat Best, Markus
Bug#1065913: opm-common: Please drop dependencies on python3-distutils
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
Bug#1064762: Works with vtk9.3 installed in venv via pip (was Re: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1)
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
Bug#1065914: opm-simulators: Please drop dependencies on python3-distutils
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
Bug#1064762: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1
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 python3-vtk9-test.tar.gz that mimics the problems. The script test/vtkcheckcomb.py will read the file vtktest-1D-leafview-nonconforming-appendedbase64.vtp using different relative paths with vtkXMLPolyDataReader. On Debian stable all those cases succeed (see log file tests/stable/vtkcheckcomb.log. On Debian sid all of the fail with this error of vtk xml parser: 2024-03-11 14:31:34.098 ( 0.123s) [A51E0740] vtkXMLParser.cxx:375ERR| vtkXMLDataParser (0x1659c80): Error parsing XML in stream at line 27, column 9, byte index 1562: not well-formed (invalid token) 2024-03-11 14:31:34.099 ( 0.123s) [A51E0740] vtkXMLReader.cxx:521ERR| vtkXMLPolyDataReader (0x15f4e90): Error parsing input file. ReadXMLInformation aborting. 2024-03-11 14:31:34.099 ( 0.123s) [A51E0740] vtkExecutive.cxx:752ERR| vtkCompositeDataPipeline (0x1631800): Algorithm vtkXMLPolyDataReader(0x15f4e90) returned failure for request: vtkInformation (0x166e920) Debug: Off Modified Time: 775 Reference Count: 1 Registered Events: (none) Request: REQUEST_INFORMATION ALGORITHM_AFTER_FORWARD: 1 FORWARD_DIRECTION: 0 I have no clue why this is the case. To me it is more likely that the problem is due a change in vtk9. Hence I am reassinging to vtk9 in the hope that the maintainers there have more clues than me. Best, Markus python3-vtk9-test.tar.gz Description: application/gzip
Bug#1060076: alberta: FTBS on ppc64el: Package fixed but Sponsor for uploading needed
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 I need a sponsor from e.g. the Debian Science team that uploads the fixed package. alberta is marked for removal today. Thanks a lot. Best, Markus [1] https://salsa.debian.org/science-team/alberta/-/merge_requests/4 signature.asc Description: PGP signature
Bug#1064561: 1064561 dune-grid: FTBFS on i386: 98% tests passed, 1 tests failed out of 66
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 read.
excerpt from dune/grid/io/file/gmshreader.hh
void readfile(FILE * file, int cnt, const char * format,
void* t1, void* t2 = 0, void* t3 = 0, void* t4 = 0,
void* t5 = 0, void* t6 = 0, void* t7 = 0, void* t8 = 0,
void* t9 = 0, void* t10 = 0)
{
off_t pos = ftello(file);
int c = fscanf(file, format, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10);
if (c != cnt)
DUNE_THROW(Dune::IOError, "Error parsing " << fileName << " "
"file pos " << pos
<< ": Expected '" << format << "', only read " << c <<
" entries instead of " << cnt << ".");
}
[...]
// open file name, we use C I/O
fileName = f;
FILE* file = fopen(fileName.c_str(),"rb");
if (file==0)
DUNE_THROW(Dune::IOError, "Could not open " << fileName);
//=
// Header: Read vertices into vector
// Check vertices that are needed
//=
number_of_real_vertices = 0;
boundary_element_count = 0;
element_count = 0;
// process header
double version_number;
int file_type, data_size;
readfile(file,1,"%s\n",buf);
if (strcmp(buf,"$MeshFormat")!=0)
DUNE_THROW(Dune::IOError, "expected $MeshFormat in first line");
readfile(file,3,"%lg %d %d\n",_number,_type,_size);
if( (version_number < 2.0) || (version_number > 2.2) )
DUNE_THROW(Dune::IOError, "can only read Gmsh version 2 files");
[...]
File unitcube.sh:
$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
...
I will need to reproduce this somehow. Just need to learn how.
Best,
Markus
Bug#1055857: transition: opm-common
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 probably work even without a transition, but I would like to play it safe. This should only affect the OPM source packages opm-common, opm-grid, opm- models, opm-simulators and opm-upscaling. I have already uploaded new versions to experimental that seemed to have built without any issues, see [1]. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "libopm-common-2023"; is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- common-2023.10"; is_good = .depends ~ "libopm-common-2023.10"; is_bad = .depends ~ "libopm-common-2023.04"; libopm-common has a Provides: libopm-common-X, but the shared library included in libopm-common also has a SONAME of libopm-common.X. Why is the packaging not following the common practice of matching the package name with the SONAME? Thanks a lot for noticing. Indeed the library has an SONAME, but as upstream does not care about API changes, one cannot rely on them. Basically the SONAME is changed with every release. Releases happen twice a year in April/October. Hence we have 2022.04, 2022.10, 2023.04, 2023.10, etc. The problem probably is that there is no compatibility between 2023.04 and 2023.10. If we would do intermediate snapshot releases, then those might have slightly incompatibe APIs, too. The reason for the current situation probably is a combination of lack of knowledge on my side and inspiration taken from libdune-common-dev. I now realise that the situation is different here, though. Solving the SONAME issue might require quite some additional work. We would need to start with 2024.0 now and increase the major number with every release. If we do this only in Debian then those numbers would also differ from upstream, which might be a problem. What would your suggestion be? Cheers, Markus
Bug#1055857: transition: opm-common
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. Uploading to unstable would probably work even without a transition, but I would like to play it safe. This should only affect the OPM source packages opm-common, opm-grid, opm- models, opm-simulators and opm-upscaling. I have already uploaded new versions to experimental that seemed to have built without any issues, see [1]. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "libopm-common-2023"; is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- common-2023.10"; is_good = .depends ~ "libopm-common-2023.10"; is_bad = .depends ~ "libopm-common-2023.04"; Thanks a lot. Kind regards, Markus [1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de
Bug#1051920: RM: opm-common/experimental -- ROM; NVIU
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
Bug#1042023: opm-common: FTBFS on armel and mipsel
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
Bug#1042023: opm-common: FTBFS on armel and mipsel
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, Markus [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049463
Bug#1049696: RM: opm-models [armel] -- ROM; FTBS ANAIS
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 lot for your good work. Best, Markus [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042023 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049463
Bug#1049463: RM: opm-common [armel mipsel] -- ROM; FTBS
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 build and is probably due better tests in package for the new upstream version. Patching opm-common for 32bit in Debian would be way too much effort. Therefore I patched the sources such that the FTBS now already occurs for any 32bit system when CMake is run. That patch is part of version 2023.04+ds-3 which is waiting for migration. It will be forwarded upstream. Please remove the binary packages for armel and mipsel to allow migration. Thanks a lot for your good work. Cheers, Markus [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042023
Bug#1042023: opm-common: FTBFS on armel and mipsel
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 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
Bug#1042023: opm-common: FTBFS on armel and mipsel
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 lot. Kind regards, Markus
Bug#1037809: With relase 2023.04+ds-1 opm-material was merged into opm-common
Tags: wontfix Dear all, With the upstream release 2023.04 that I am currently uploading the code of opm-material was merged into opm-common. Therefore there will be no fix for this in opm-material as it should be removed anyway. Hopefully this will be done by the autoremoval system without 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
Bug#1037810: opm-upscaling: ftbfs with GCC-13
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
Bug#1034380: unblock: opm-models/2022.10+ds-4
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 changes are: - Bump to 4.6.2 standard - Limit architectures for running tests. (That was my failed attempt to convince britney that the autopkgtests have run) I am perfectly fine with keeping this blocked and closing the bug. Best, Markus signature.asc Description: PGP signature
Bug#1034382: unblock: opm-upscaling/2022.10+ds-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package opm-upscaling
[ Reason ]
Package contains fixes to d/*control files, unneeded code is not compiled
anymore (backport from upstream). Package is blocked only because britney
thinks that not all autopkgtests have run, but those for official architectures
with binaries have run
[ Impact ]
No impact on user if this is not unblocked.
[ Tests ]
All autopkgtests for architectures with binaries have run
[ Risks ]
None, because no real code is changed
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
None
unblock opm-upscaling/2022.10+ds-4
diff --git a/debian/changelog b/debian/changelog
index 6cc7b59..abc63b0 100644
--- 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: Remove git from Build-Depends as it is not needed.
+
+ -- Markus Blatt Thu, 09 Mar 2023 00:01:19 +0100
+
+opm-upscaling (2022.10+ds-2) experimental; urgency=medium
+
+ * d/control: Bumped standards version to 4.6.2 (no-change)
+
+ -- Markus Blatt Mon, 09 Jan 2023 16:57:02 +0100
+
opm-upscaling (2022.10+ds-1) unstable; urgency=medium
* New upstream version 2022.10
diff --git a/debian/control b/debian/control
index 8fd5433..7226645 100644
--- a/debian/control
+++ b/debian/control
@@ -6,10 +6,10 @@ Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt,
libboost-system-dev, libboost-date-time-dev, libboost-test-dev,
libboost-iostreams-dev,
gfortran, libtinyxml-dev, bc,
- git, zlib1g-dev, libtool, libopm-material-dev (>= 2022.10),
libopm-grid-dev (>= 2022.10),
+ zlib1g-dev, libtool, libopm-material-dev (>= 2022.10),
libopm-grid-dev (>= 2022.10),
doxygen, texlive-latex-extra, texlive-latex-recommended,
ghostscript,
pkg-config, mpi-default-dev, mpi-default-bin
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
Section: libs
Homepage: http://opm-project.org
Vcs-Browser: https://salsa.debian.org/science-team/opm-upscaling
diff --git
a/debian/patches/0001-Removed-stale-static-benchmarks-to-really-not-need-g.patch
b/debian/patches/0001-Removed-stale-static-benchmarks-to-really-not-need-g.patch
new file mode 100644
index 000..a87c4b3
--- /dev/null
+++
b/debian/patches/0001-Removed-stale-static-benchmarks-to-really-not-need-g.patch
@@ -0,0 +1,35 @@
+From: Markus Blatt
+Date: Thu, 9 Mar 2023 09:40:37 +0100
+Subject: Removed stale static benchmarks to really not need git.
+
+According to upstream those are from ancient time, not used and built,
+anyway.
+---
+ CMakeLists.txt | 15 ---
+ 1 file changed, 15 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 0ea55dd..f4f68c6 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -112,20 +112,5 @@ include
(${CMAKE_CURRENT_SOURCE_DIR}/compareUpscaling.cmake)
+ # encode test cases so they can be embedded in the benchmark executables
+ include (${PROJECT_SOURCE_DIR}/EmbedCases.cmake)
+
+-# Setup static benchmarks
+-include(OpmStaticTargets)
+-opm_from_git(${PROJECT_SOURCE_DIR} benchmarks ${VCS_SHA1} benchmarks)
+-add_dependencies(benchmarks-static opm-grid-static)
+-
+-# Copy static benchmarks to main project binary directory
+-foreach(benchmark ${OPM_BENCHMARKS})
+- add_custom_command(TARGET benchmarks-static POST_BUILD
+- COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_BINARY_DIR}/static/benchmarks/src/benchmarks-static-build/bin/${benchmark}
+-
${CMAKE_BINARY_DIR}/bin/${benchmark}-static)
+- if(INSTALL_BENCHMARKS)
+- install(TARGETS ${benchmark} DESTINATION bin)
+- endif()
+-endforeach()
+-
+ install(DIRECTORY doc/man1 DESTINATION ${CMAKE_INSTALL_MANDIR}
+ FILES_MATCHING PATTERN "*.1")
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..0197cdd
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Removed-stale-static-benchmarks-to-really-not-need-g.patch
Bug#1034381: unblock: opm-simulators/2022.10+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package opm-simulators
[ Reason ]
Package contains fixes to d/*control and d/rules files (might ease rebuilds)
and fixes the version string of the programs. Is blocked only because britney
thinks that not all autopkgtests have run, but those for official architectures
with binaries have run
[ Impact ]
Slight impact on the user if he/she build software based on opm-simulators.
Without the new version there might be issues when using alberta
[ Tests ]
All autopkgtests for architectures with binaries have run
[ Risks ]
Small, because not much code is changed
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
None
unblock opm-simulators/2022.10+ds-2
diff --git a/debian/changelog b/debian/changelog
index 1d514e256..df8054d61 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+opm-simulators (2022.10+ds-2) unstable; urgency=medium
+
+ * d/rules: Require 4GB of RAM per make process
+ * [cmake] Work around 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..eb74c3c7c 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Maintainer: Debian Science Maintainers
, Markus Blatt
Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt, dh-python,
libboost-system-dev, libboost-date-time-dev, libboost-test-dev,
- zlib1g-dev, gfortran, pkg-config, git, libtool, doxygen,
+ zlib1g-dev, gfortran, pkg-config, lsb-release, libtool, doxygen,
texlive-latex-extra, texlive-latex-recommended, ghostscript,
libopm-grid-dev (>= 2022.10), libopm-models-dev (>= 2022.10),
mpi-default-dev, mpi-default-bin,
python3-dev, libpython3-dev, python3-distutils, pybind11-dev
diff --git
a/debian/patches/0003-cmake-Work-around-missing-imported-Alberta-targets.patch
b/debian/patches/0003-cmake-Work-around-missing-imported-Alberta-targets.patch
new file mode 100644
index 0..e716106e5
--- /dev/null
+++
b/debian/patches/0003-cmake-Work-around-missing-imported-Alberta-targets.patch
@@ -0,0 +1,27 @@
+From: Markus Blatt
+Date: Fri, 23 Dec 2022 13:32:43 +0100
+Subject: [cmake] Work around missing imported Alberta targets.
+
+For the autopkgtest Alberta is not searched before dune-grid and
+hence leading to errors about missing imported targets.
+
+With this workaround we make sure that Alberta is searched for before
+dune-grid to prevent this.
+---
+ opm-simulators-prereqs.cmake | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/opm-simulators-prereqs.cmake b/opm-simulators-prereqs.cmake
+index 69fb165..4640914 100644
+--- a/opm-simulators-prereqs.cmake
b/opm-simulators-prereqs.cmake
+@@ -28,6 +28,9 @@ set (opm-simulators_DEPS
+ # Various runtime library enhancements
+ "Boost 1.44.0
+ COMPONENTS date_time system unit_test_framework REQUIRED"
++ # work around issue in the CMake dependecy search order
++ # We need some imported targets before the othr
++ "Alberta"
+ # DUNE prerequisites
+ "dune-common REQUIRED"
+ "dune-istl REQUIRED"
diff --git a/debian/patches/series b/debian/patches/series
index 0f35f5775..309f2d0e1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
0001-Fixed-typo-acess-access.patch
0002-Use-SKIP_BUILD_RPATH-for-python-lib-of-simulators.patch
+0003-cmake-Work-around-missing-imported-Alberta-targets.patch
diff --git a/debian/rules b/debian/rules
index 598aeb7e3..f18fc8bbd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,10 +18,12 @@ ifneq ("$(wildcard $(OPM_LIB_DEBIAN_MK))","")
include $(OPM_LIB_DEBIAN_MK) # for makeshlibs
endif
-# Set DEBIAN_FORCE_PARALLEL to compile in parallel
-ifeq ($(strip $(DEBIAN_FORCE_PARALLEL)),)
- DEB_PARALLEL="--max-parallel=1"
-endif
+# require 4GB of RAM per make process
+need_gb_ram_per_process=4
+free_ram=$(shell free -g | sed -n 2p| sed "s/ \+/ /g"| cut -d " " -f 2)
+max_procs=$(shell echo "$(free_ram)/$(need_gb_ram_per_process)" | bc)
+parallel_procs=$(shell if test "$(max_procs)" -lt "1"; then echo 1; else echo
"$(max_procs)"; fi)
%:
- dh $@ --with python3 $(DEB_PARALLEL)
+ echo "ram in gb: $(free_ram), needed ram per thread:
$(need_gb_ram_per_process), threads: $(parallel_procs)"
+ dh $@ --with python3 --max-parallel=$(parallel_procs)
Bug#1034380: unblock: opm-models/2022.10+ds-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package opm-models
[ Reason ]
Package contains fixes to d/*control files. Is blocked only because britney
thinks that not all autopkgtests have run, but those for official architectures
with binaries have run
[ Impact ]
No impact on the user if this is not unblocked
[ Tests ]
All autopkgtests for architectures with binaries have run
[ Risks ]
None, because no real code is changed
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
None
unblock opm-models/2022.10+ds-4
diff --git a/debian/changelog b/debian/changelog
index 221675485..5a43ea694 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+opm-models (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 +0100
+
+opm-models (2022.10+ds-2) experimental; urgency=medium
+
+ * d/control: Bumped standards version to 4.6.2
+
+ -- Markus Blatt Mon, 09 Jan 2023 15:55:47 +0100
+
opm-models (2022.10+ds-1) unstable; urgency=medium
* New upstream version 2022.10
diff --git a/debian/control b/debian/control
index fa91260d4..add7ae3c6 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper-compat (= 12), cmake,
# Build-Depends-Indep: # broken on precise pbuilder
doxygen, texlive-latex-extra, texlive-latex-recommended, ghostscript,
zlib1g-dev
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
Homepage: http://opm-project.org
Vcs-Browser: https://salsa.debian.org/science-team/opm-models
Vcs-Git: https://salsa.debian.org/science-team/opm-models.git
@@ -20,7 +20,7 @@ Rules-Requires-Root: no
Package: libopm-models-dev
Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Multi-Arch: same
Depends: ${misc:Depends},
libdune-grid-dev, libdune-istl-dev,
diff --git a/debian/tests/control b/debian/tests/control
index 423df4959..fdc4cac7a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -6,3 +6,4 @@ Depends:
libboost-test-dev
# skip test on architectures where there is no installable package (e.g. 32bit)
Restrictions: allow-stderr, skip-not-installable
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Bug#1034379: unblock: opm-material/2022.10+ds-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package opm-material
[ Reason ]
New package contains various cleanups in debian/*control files.
Only blocked by britney, because it thinks that not all autopkgtest have run,
but they have for official architectures with binaries.
[ Impact ]
No direct impact on user-
[ Tests ]
All autopkgtests on official architectures with binaries have run successfully
[ Risks ]
None that I can think off.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
None
unblock opm-material/2022.10+ds-4
diff --git a/debian/changelog b/debian/changelog
index 0c12d4aa..eacf04c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+opm-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 Blatt Wed, 08 Mar 2023 23:37:43 +0100
+
+opm-material (2022.10+ds-2) experimental; urgency=medium
+
+ * d/control: Bump standards version to 4.6.2 (no-change)
+
+ -- Markus Blatt Mon, 09 Jan 2023 11:35:45 +0100
+
opm-material (2022.10+ds-1) unstable; urgency=medium
* New upstream version 2022.10
diff --git a/debian/control b/debian/control
index d1d6ea3e..75591d3c 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,10 @@ Uploaders: Arne Morten Kvarving
, Markus Blatt <
Build-Depends: debhelper-compat (= 12),
pkg-config, libopm-common-dev (>= 2022.10), quilt,
libboost-test-dev,
libdune-common-dev, cmake, bc,
- git, zlib1g-dev, libtool, doxygen, graphviz,
+ zlib1g-dev, libtool, doxygen, graphviz,
texlive-latex-extra, texlive-latex-recommended, ghostscript,
mpi-default-dev, mpi-default-bin, libatlas-base-dev
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
Section: libs
Homepage: http://opm-project.org
Vcs-Browser: https://salsa.debian.org/science-team/opm-material
@@ -17,7 +17,7 @@ Rules-Requires-Root: no
Package: libopm-material-dev
Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Multi-Arch: same
Depends: ${misc:Depends}, libopm-common-dev (>= 2022.10), libdune-common-dev
Replaces: libopm-material1-dev
diff --git a/debian/tests/control b/debian/tests/control
index d07f6ee1..ad95245a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -6,3 +6,4 @@ Depends:
libboost-test-dev
# skip test on architectures where there is no installable package (e.g. 32bit)
Restrictions: allow-stderr, skip-not-installable
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Bug#1034377: unblock: opm-grid/2022.10+ds-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package opm-grid [ Reason ] Only debian/control has been cleaned up. Blocked only because britney thinks not all autopkgtests have run, but they have for official architectures with binaries [ Impact ] No impact for the user if it stays blocked [ Tests ] autopkgtests have run successfully on all offical architectures with binaries. [ Risks ] None that I can think o. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] None unblock opm-grid/2022.10+ds-3 diff --git a/debian/changelog b/debian/changelog index ea72b63d..d008b89a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,15 @@ +opm-grid (2022.10+ds-3) unstable; 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 + opm-grid (2022.10+ds-1) unstable; urgency=medium * New upstream version 2022.10 diff --git a/debian/control b/debian/control index 765a482b..923f671d 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Maintainer: Debian Science Maintainers , Markus Blatt Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt, libboost-system-dev, libboost-test-dev, - libdune-common-dev (>= 2.6), bc, git, zlib1g-dev, libtool, pkg-config, + libdune-common-dev (>= 2.6), bc, zlib1g-dev, libtool, pkg-config, libdune-grid-dev (>= 2.6), libtinyxml-dev, libdune-istl-dev (>= 2.6), doxygen, texlive-latex-extra, texlive-latex-recommended, ghostscript, @@ -13,7 +13,7 @@ Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt, libscotchmetis-dev, libscotchparmetis-dev, libdune-geometry-dev (>= 2.6), libtrilinos-zoltan-dev, mpi-default-dev, mpi-default-bin -Standards-Version: 4.6.0 +Standards-Version: 4.6.2 Section: libs Homepage: http://opm-project.org Vcs-Browser: https://salsa.debian.org/science-team/opm-grid
Bug#1034376: unblock: opm-common/2022.10+ds-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package opm-common
It contains an important fix of the printed version number. It is only blocked
because britney thinks that autopkgtests have not run, but they have
[ Reason ]
It contains an important fix of the printed version number and reduces resource
usage during the build.
[ Impact ]
No impact for users if there no binary rebuilds.
In the case of rebuilds resource usage on buildd will be much higher than with
new version.
[ Tests ]
All autopkgtest have run successfully for official architectures with binary
packages
[ Risks ]
None that I can think of
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
None
unblock opm-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 Thu, 23 Mar 2023 08:34:59 +0100
+
+opm-common (2022.10+ds-6) unstable; urgency=medium
+
+ * Reduce compile time and resources with g++-12
+ * d: Fixed version string used in binaries.
+
+ -- Markus Blatt Wed, 08 Mar 2023 23:05:15 +0100
+
+opm-common (2022.10+ds-5) experimental; urgency=medium
+
+ * Backported fixes for python tests from upstream (to fix mipsel*?)
+ * d/rules: Try to limit parallel builds to ensure 3GB RAM per process
+
+ -- Markus Blatt Sun, 05 Feb 2023 13:59:47 +0100
+
opm-common (2022.10+ds-4) unstable; urgency=medium
* Make sure copy_python is run before CopyHeaders Closes: #1029440
diff --git a/debian/control b/debian/control
index 86112f71a..55debe51b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,9 @@ Source: opm-common
Priority: optional
Maintainer: Debian Science Maintainers
Uploaders: Arne Morten Kvarving , Markus Blatt
-Build-Depends: cmake (>=3.10), mpi-default-bin, mpi-default-dev,
+Build-Depends: cmake (>=3.10), mpi-default-bin, mpi-default-dev, bc, procps,
debhelper-compat (= 12), libcjson-dev, libfmt-dev, quilt,
dh-python,
- pkg-config, git, libtool, doxygen, graphviz,
+ pkg-config, lsb-release, libtool, doxygen, graphviz,
texlive-latex-extra, texlive-latex-recommended,
ghostscript, libboost-system-dev, libboost-test-dev,
zlib1g-dev, python3-dev, libpython3-dev, python3-numpy,
python3-distutils,
@@ -19,7 +19,7 @@ Rules-Requires-Root: no
Package: libopm-common
Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
Provides: ${opm:shared-library}
@@ -36,7 +36,7 @@ Description: Tools for Eclipse reservoir simulation files --
library
Package: libopm-common-bin
Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
Replaces: libopm-common1-bin
@@ -52,7 +52,7 @@ Description: Tools for Eclipse reservoir simulation files --
utility programs
Package: libopm-common-dev
Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Multi-Arch: same
Suggests: libopm-common-doc
Replaces: libopm-common1-dev
@@ -85,7 +85,7 @@ Description: Tools for Eclipse reservoir simulation files --
documentation
Package: python3-opm-common
Section: python
Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
libopm-common, python3-numpy, python3-decorator
Description: Tools for Eclipse reservoir simulation files -- Python wrappers
The Open Porous Media (OPM) software suite provides libraries and
diff --git a/debian/opm-debian.mk b/debian/opm-debian.mk
index 3b74fbe07..ea37112a8 100644
--- a/debian/opm-debian.mk
+++ b/debian/opm-debian.mk
@@ -2,10 +2,10 @@ include /usr/share/dpkg/architecture.mk
include /usr/share/dpkg/pkg-info.mk
include /usr/share/dune/dune-debian.env
-LSB_RELEASE = lsb_release -r | sed "s/.*:\s*\([^\s]*\).*/\1/"
+LSB_RELEASE = lsb_release -d | sed "s/.*:\s\+\(.*\)/\1/"
# Needed for reproducable builds as we use __FILE__
export DEB_BUILD_MAINT_OPTIONS += reproducible=+fixfilepath
-OPM_DEBIAN_CMAKE_FLAGS += -DBUILD_SHARED_LIBS=1
-DCMAKE_INSTALL_DOCDIR=share/doc/lib$(DEB_SOURCE)
-DPYTHON_INSTALL_PREFIX=lib/python3/dist-packages
-DOPM_INSTALL_COMPILED_PYTHON=OFF -DUSE_RUNPATH=OFF -DWITH_NATIVE=OFF
-DUSE_MPI=ON -DUSE_BASH_COMPLETIONS_DIR=ON
-D
Bug#1033561: Arch list for removal in bug title is the correct one
Hi, the archictures to remove are armhf hppa m68k as the title suggests. Not the ones listed in the body. Best, Markus
Bug#1033563: RM: opm-models [armhf, hppa, m68k] -- ROM; FTBS & package useless on these archs
Package: opm-models Severity: serious built successfully in the past) Dear FTP team, the package fails to build from source for the architectures armhf, hppa and m68k since a few versions. For armhf this situation is new as opm-common now fails to build reliably from source for this architecture. The main reason for having opm-models is to be able to build opm-simulators. As that is not built for these architectures, having those in Debian is of little use even if they would build from source. Note that the architecture list of the latest version is already adapted to only build for the needed architectures (excluding those to be removed). Best regards, Markus Blatt
Bug#1033562: RM: opm-common [alpha armhf hppa x32] -- ROM; FTBS and/or ANAIS
Package: ftp.debian.org Severity: normal Dear FTP team, the package fails to build from source for the architectures alpha, armhf, hppa and x32 since a few versions. For armhf this situation is new as opm-common now fails to build reliably from source for this architecture. For the others these problems that appeared with more checks introduces with 2022.10 The main reason for having opm-common is to be able to build opm-simulators. As that is not built for these architectures, having those in Debian is of little use even if they would build from source. Note that the architecture list 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
Bug#1033561: RM: opm-models [armhf hppa m68k] -- ROM; FTBS and/or ANAIS
Package: ftp.debian.org Severity: normal Dear FTP team, the package fails to build from source for the architectures armhf, hppa and appha since a few versions. For armhf this situation is new as opm-common now fails to build reliably from source for this architecture. The main reason for having opm-material is to be able to build opm-simulators. As that is not built for these architectures, having those in Debian is of little use even if they would build from source. Note that the architecture list 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
Bug#1033559: RM: opm-material [alpha armhf hppa] -- ROM; FTBS and/or ANAIS
Package: ftp.debian.org Severity: normal Dear FTP team, the package fails to build from source for the architectures armhf, hppa and appha since a few versions. For armhf this situation is new as opm-common now fails to build reliably from source for this architecture. The main reason for having opm-material is to be able to build opm-simulators. As that is not built for these architectures, having those in Debian is of little use even if they would build from source. Note that the architecture list 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
Bug#930421: My permissions for /etc/courier/shared
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: $ ls -ld /etc/courier/shared/ drwxr-xr-x 2 root courier 4096 May 17 2016 /etc/courier/shared/ Best, Markus
Bug#1029440: opm-common: FTBFS in bookworm (cc1plus: fatal error: [...]/builtin_pybind11.cpp: No such file or directory)
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 interpret it literally? Also, I gave Markus ssh access to a machine where the bug is fully reproducible. Markus, any progress? Sorry, not yet. This week was rather busy, but my intention is to give it a try today or tomorrow on that machine. First I need to do some sport :) Then this will be top priority Up to now I have only interpreted the presented log: /<>/obj-x86_64-linux-gnu/tmp_gen/builtin_pybind11.cpp is create by the generator program. Somehow CMake notices that and remove the first file A.cpp that is generated by the generator program. As the next step needs that file the generation is tried again and must fail. This failue is not detected until the compilation error occurs. I have no idea why writing of the file fails. I will probably have to patch the generator program to do some error checking (that is currently missing). I think I saw this same error for buildd on some not officially supported architectures, but never on amd64. Best, Markus
Bug#1029440: opm-common: FTBFS in bookworm (cc1plus: fatal error: [...]/builtin_pybind11.cpp: No such file or directory)
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 available Mem: 1981536 80440 795168 512 1105928 1720784 Swap: 0 0 0 That makes migh highly doubt that it is possible to compile opm-common (and probably other C++ packages using templates) on that machine. Even if the file would have been correctly generated. The lacking RAM is probably why I never saw this on any other amd64 build (on Debian) as they all seem to have more RAM per build thread (I assume >=4GB). Ubuntu is another story though (we needed to limit parallel builds for e.g. opm-simulators there before). How should we proceed. Is there a possibility to do the builds on other machines with more RAM? Best, Markus
Bug#965215: Use --max-parallel based on available ram
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 killer. > I don't think this problem is limited to dune-common or Ubuntu. It occurs for e.g. dealii or OPM even for some Debian build machines (e.g. arm). That is quite unfortunate. > > Can you please consider adding --max-parallel=3 to dh invocation? > > > > People might want to rebuild on their system without having to swap during the build process. > > That might require parallel=1 depending on the system anyway. I > usually build with parallel=8 without problems, so I don't want to > limit it to 3. mmm what about doing something like this? ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes),yes) dh $@ --builddirectory=build --max-parallel=3 else dh $@ --builddirectory=build endif Maybe we should rather base that on the assumed max ram needed per process. Say that is e.g. 4 Gigabyte then one could do something similar to free_ram = $(shell free -g | sed -n 2p| sed "s/ \+/ /g"| cut -d " " -f 2) max_procs = $(shell echo $(free_ram)/4 | bc) %: dh $@ --builddirectory=build --max-parallel=$(max_procs) Would that work? Would need some trial and error of course... Best, Markus
Bug#1010519: g++-12: compilation fails on riscv64 because of always_inline when using fmtlib
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
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:19:
/usr/include/fmt/core.h: In member function ‘void
Opm::UDAValue::assert_numeric() const’:
/usr/include/fmt/core.h:3117:31: error: inlining failed in call to
‘always_inline’ ‘std::string fmt::v8::format(format_string, T&& ...)
[with T = {const std::__cxx11::basic_string,
std::allocator >&}]’: target specific option mismatch
3117 | FMT_NODISCARD FMT_INLINE auto format(format_string fmt, T&&...
args)
| ^~
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:77:169: note: called
from here
77 | std::string msg = fmt::format("Internal error: The support for
use of UDQ/UDA is not complete in opm/flow. The string: '{}' must be numeric",
this->string_value);
|
^
/usr/include/fmt/core.h:3057:28: error: inlining failed in call to
‘always_inline’ ‘fmt::v8::basic_format_string::basic_format_string(const S&) [with S = char [109]; typename
std::enable_if
>::value, int>::type = 0; Char = char; Args = {const
std::__cxx11::basic_string, std::allocator
>&}]’: target specific option mismatch
3057 | FMT_CONSTEVAL FMT_INLINE basic_format_string(const S& s) : str_(s) {
|^~~
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:77:169: note: called
from here
77 | std::string msg = fmt::format("Internal error: The support for
use of UDQ/UDA is not complete in opm/flow. The string: '{}' must be numeric",
this->string_value);
|
^
make[3]: *** [CMakeFiles/genkw.dir/build.make:107:
CMakeFiles/genkw.dir/src/opm/input/eclipse/Deck/UDAValue.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
[ 8%] Generating tests/TEST_WLIST.DATA
See [1] for the full log.
It seems like this problem might be solved upstream already, see [2]. Maybe we
shold backport this?
[1] https://buildd.debian.org/status/fetch.php?pkg=opm-
common=riscv64=2022.04%7Erc1-2=1651224804=0
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234#c14
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages g++-12 depends on:
ii gcc-1212-20220428-1
ii gcc-12-base 12-20220428-1
ii libc6 2.33-7
ii libgmp10 2:6.2.1+dfsg-3
ii libisl23 0.24-2
ii libmpc3 1.2.1-2
ii libmpfr6 4.1.0-3
ii libstdc++-12-dev 12-20220428-1
ii libzstd1 1.5.2+dfsg-1
ii zlib1g1:1.2.11.dfsg-4
g++-12 recommends no packages.
Versions of packages g++-12 suggests:
pn g++-12-multilib
pn gcc-12-doc
Bug#1009685: Please close as resolved without package upload
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 hope that we can simply close this bug without uploading a new package version with any changes. I abstained from closing it myself, as I am not sure whether that would be rude. I am happy to close it myself if that is ok. [1] https://qa.debian.org/excuses.php?package=opm-grid signature.asc Description: PGP signature
Bug#1009685: Resolved due to migration of Python3.10 (was: opm-grid: autopkgtest regression: No rule to make target '/usr/lib/x86_64-linux-gnu/libpython3.10.so')
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). In retrospect that might not have been the best idea? Seems like this has actually worked as after the python transition finished all the autopkgtests are green on [1]. Or am I missing something? But maybe the correct fix would be to have a versioned dependency on the python lib for all binary packages that have references to it in the CMake configuration files? That would then be for all libopm-*-dev packages which ship these. At least this might prevent problems in future transitions. On a side note: We seem to have similar (or more serious) problems with opm-material, see [2]. There I do not understand why opm-models (which requires opm-material) can actually block the migration. But that might my limited knowledge. Would be cool if someone would enlighten me in this regard. Cheers, Markus [1] https://qa.debian.org/excuses.php?package=opm-grid [2] https://qa.debian.org/excuses.php?package=opm-material signature.asc Description: PGP signature
Bug#1006836: transition: python3.10 as default
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 is only updated if the module/package is rebuilt. All modules built before the transition have a reference to /usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake configuration file of opm-common when they where built. The only way to get rid of them seems to be rebuilding all. Hence one would need to change the dependencies along the following lines dependency level 3: opm-grid, opm-material, dependency level 4: opm-models, opm-uscaling dependency level 5: opm-simulators (currently level 3) As there were some packaging improvements lying aroud anyway, I pushed new releases for opm-grid, opm-material, opm-models, opm-upscaling. They did build fine and are now installed in sid. I think this should fix the problem for opm-simulators, once you trigger a rebuild. (At least it work in the salsa-ci). HTH, Markus
Bug#1006836: transition: python3.10 as default
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 to libpython3.9.so. 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 is only updated if the module/package is rebuilt. All modules built before the transition have a reference to /usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake configuration file of opm-common when they where built. The only way to get rid of them seems to be rebuilding all. Hence one would need to change the dependencies along the following lines dependency level 3: opm-grid, opm-material, dependency level 4: opm-models, opm-uscaling dependency level 5: opm-simulators (currently level 3) Note that opm-upscaling is only needed because: if a user searches for it in its project, then compilation will fail in the same manner as opm-simulators is failing currently. Explanation why it is the way it is: It is the way OPM uses CMake, these scripts date back to an old Cmake version (without support for targets). At that time this approach was (or seemed to be) needed for static libraries. Otherwise there would have been linker errors, because we use embedded python in opm-common. Updating to modern CMake targets would have prevented this issue. Sorry for the trouble and HTH. Cheers, Markus
Bug#1006836: transition: python3.10 as default
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
Bug#1006836: transition: python3.10 as default
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 to do on my side as a maintainer then please let me know. Cheers, Markus [1] https://buildd.debian.org/status/fetch.php?pkg=opm-simulators=amd64=2021.10-4%2Bb1=1648476056=0
Bug#1007830: Possible fix in dune-common
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.
Bug#1007930: MR with fix created on salsa
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
Bug#1007830: opm-grid: FindMETIS.cmake
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 actually use the one from dune-common (/usr/share/dune/cmake/modules/FindMETIS.cmake) and hence exhibit a bug there (just opened one a few minutes ago). Having said that, it seems quite likely that FindMETIS.cmake in opm-grid (/usr/share/dune/cmake/Modules/FindMETIS.cmake) might have the same problem and this problem will surface when rebuilding opm-simulators and opm-upscaling. METIS code is used in opm-simulators via usage of source code of dune-istl. The reason why opm-grid search for METIS is that Zoltan from trilinos might need it if a static library of thise is used. Then another user module using opm-grid will need METIS.
Bug#1007930: trigger patch
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-dev to also test FindMETIS.cmake --- debian/tests/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/tests/control b/debian/tests/control index db7e036..cd0b5cf 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -3,4 +3,5 @@ Depends: libdune-common-dev, build-essential, mpi-default-bin, mpi-default-dev, + libscotchmetis-dev, Restrictions: allow-stderr -- 2.30.2
Bug#1007930: libdune-common-dev: METIS_PartGraphVKway is available in metis v3 but DUNE modules tests whether linking to metis v5
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: -- Found PTScotch: /usr/lib/x86_64-linux-gnu/libscotch.so (found version "7.0.1") -- Looking for METIS_PartGraphVKway CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: METIS_LIBRARY linked by target "cmTC_6a2ff" in directory /home/opm- build/test/tester/build/CMakeFiles/CMakeTmp CMake Error at /usr/share/cmake-3.22/Modules/CheckSymbolExists.cmake:148 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/CheckSymbolExists.cmake:71 (__CHECK_SYMBOL_EXISTS_IMPL) /usr/share/dune/cmake/modules/FindMETIS.cmake:131 (check_symbol_exists) /usr/share/dune/cmake/modules/DuneCommonMacros.cmake:35 (find_package) /usr/share/dune/cmake/modules/DuneMacros.cmake:609 (include) /usr/share/dune/cmake/modules/DuneMacros.cmake:699 (dune_process_dependency_macros) CMakeLists.txt:19 (dune_project) -- Configuring incomplete, errors occurred! See also "/home/opm-build/test/tester/build/CMakeFiles/CMakeOutput.log". See also "/home/opm-build/test/tester/build/CMakeFiles/CMakeError.log". According to bug #1007830 this is because METIS_PartGraphVKway is in metis v3 but the default version used in v5. Therefore we might need to change /usr/share/dune/cmake/module/FindMetis.cmake such that it uses libmetisv3.so. Explanation copied from #1007830: scotch 7.0.1 has just been uploaded to unstable. It provides some metis (and parmetis) compatibility which opm-grid is using. The scotch metis compatibility version can be selected via metis.h with define variable SCOTCH_METIS_VERSION. If not set then SCOTCH_METIS_VERSION=5 is applied, i.e. metis v5. >From scotch v7, compatibility libraries are provided for both metis v3 and v5 (libscotchmetisv3.so, libscotchmetisv5.so). For default metis -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-12-amd64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libdune-common-dev depends on: ii cmake3.22.1-1+b1 ii gfortran 4:11.2.0-2 ii libatlas-base-dev3.10.3-12 ii libatlas3-base [liblapack.so.3] 3.10.3-12 ii libc62.33-7 ii libgcc-s112-20220313-1 ii liblapack-dev3.10.0-2 ii liblapack3 [liblapack.so.3] 3.10.0-2 ii libstdc++6 12-20220313-1 ii mpi-default-bin 1.14 ii mpi-default-dev 1.14 ii pkg-config 0.29.2-1 Versions of packages libdune-common-dev recommends: ii python3 3.9.8-1 Versions of packages libdune-common-dev suggests: pn libdune-common-doc
Bug#1007823: scotch breaks opm-grid autopkgtest: Failed to build dune-autopkgtest
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
Bug#1005754: libopenmpi3: linked library libpmix.so.2 not found
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: minpvprocessor ..***Failed0.64 sec [smaug.dr-blatt.de:34326] mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored) [smaug.dr-blatt.de:34326] [[62064,0],0] ORTE_ERROR_LOG: Not found in file ../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): opal_pmix_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- It seems libpmix2 library is not found. There seems to have been an aborted mini transition for that lately, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951310 which might be the cause for this. root@smaug:/tmp/buildd/opm-grid-2021.10# ldd /usr/lib/x86_64-linux- gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so linux-vdso.so.1 (0x7ffd381e7000) /usr/lib/cowdancer/libcowdancer.so (0x7f4e86c75000) libopen-pal.so.40 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.40 (0x7f4e86bb8000) libpmix.so.2 => not found libevent_core-2.1.so.7 => /usr/lib/x86_64-linux- gnu/libevent_core-2.1.so.7 (0x7f4e86b7e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f4e86b5d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4e86993000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f4e8698c000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f4e86987000) libhwloc.so.15 => /usr/lib/x86_64-linux-gnu/libhwloc.so.15 (0x7f4e8692b000) libevent_pthreads-2.1.so.7 => /usr/lib/x86_64-linux- gnu/libevent_pthreads-2.1.so.7 (0x7f4e86926000) /lib64/ld-linux-x86-64.so.2 (0x7f4e86ca4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f4e867e3000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x7f4e867b8000) root@smaug:/tmp/buildd/opm-grid-2021.10# Please not that this means that packages tested by salsaci that run parallel programs during make test will fail also. See e.g. https://salsa.debian.org/science-team/opm-grid/-/jobs/2466390 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libopenmpi3 depends on: ii libc62.33-5 ii libevent-core-2.1-7 2.1.12-stable-1 ii libevent-pthreads-2.1-7 2.1.12-stable-1 ii libfabric1 1.11.0-3 ii libgcc-s111.2.0-16 ii libhwloc-plugins 2.7.0-2 ii libhwloc15 2.7.0-2 ii libibverbs1 39.0-1 ii libnl-3-200 3.5.0-0.1 ii libpmix2 4.1.2-1 ii libpsm-infinipath1 3.3+20.604758e7-6.1 ii libpsm2-211.2.185-1 ii libstdc++6 11.2.0-16 ii libucx0 1.12.1~rc1-1 ii zlib1g 1:1.2.11.dfsg-2 libopenmpi3 recommends no packages. libopenmpi3 suggests no packages.
Bug#994272: New packages for release 2021.10 of OPM
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/ https://mentors.debian.net/package/opm-simulators/ https://mentors.debian.net/package/opm-upscaling/ or salsa.debian.org: https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-upscaling Looking forward to the reviews and comments. Cheers, Markus
Bug#994272: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)
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 we will try to incorporate them. It might of course make sense to wait with uploading to NEW for the new release. I will report when the packages for the new release are available. What OPM is and why it should be in Debian: The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. Its main part is a blackoil reservoir simulator with file input and output compatible with a major commercial oil reservoir simulator. On some cases it clearly outperforms the commercial one. Being open source it lowers the bar for starting simulations and is used by industry, research institutes and quite a few small consultancies. Looking foward to your reviews and sponsoring efforts Cheers, Markus [0] https://lists.debian.org/debian-mentors/2021/09/msg00055.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994272
Bug#994272: Acknowledgement (RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)
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 RFS for each individual package, I will gladly do that. The intention of just one ITP and RFS bug was to make clear that there are dependencies between these packages. Regads, -- Markus
Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite
tors - Python wrappers for the Open porous media / reservoir simulators libopm-simulators-doc - Open porous media / reservoir simulators -- documentation libopm-simulators-bin - Parallel porous media / reservoir simulators -- applications libopm-simulators - Open porous media / reservoir simulators -- library libopm-simulators-dev - Parallel porous media / reservoir simulators -- development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opm-simulators/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opm-simulators/opm- simulators_2021.04-1.dsc Changes for the initial release: opm-simulators (2021.04-1) unstable; urgency=medium . * Initial release (Closes: #987381) 6. opm-upscaling * Package name: opm-upscaling Version : 2021.04-1 Upstream Author : o...@opm-project.org * URL : http://opm-project.org * License : GPL-3.0+ * Vcs : https://salsa.debian.org/science-team/opm-upscaling Section : libs It builds those binary packages: libopm-upscaling-doc - Porous media upscaling tools -- documentation libopm-upscaling - Porous media upscaling tools -- library libopm-upscaling-bin - Porous media upscaling tools -- applications libopm-upscaling-dev - Porous media upscaling tools -- development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opm-upscaling/ 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: #987381) Thanks a lot for your help Regards, -- Markus Blatt -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#987381: ITP: opm-common -- Tools for Eclipse reservoir simulation files
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+ Programming Lang: C++, Python Description : Open Porous Media (OPM) software suite . The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. Please note that the software is maintained in several repositories and hence this ITP is for several source packages. Packages should ideally be maintained via the Debian science team as this is software for physics. Most of the packaging will be maintained by me and a colleague who are also part of the OPM development team, but as neither of us are Debian maintainers we rely on some mentoring and definitely need sponsors for uploading. The actual packaging effort has already started and besides smal glitches seems to be now in good shape (as far as we as newbie/recreational packagers can judge). Current state of the packaging effort can be found at https://salsa.debian.org/blattms/ Below is a list of the packages: Source: opm-common Description: Tools for Eclipse reservoir simulation files The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. . The Eclipse file format is widely used in the reservoir simulation community. This package provides library containing code for processing files in Eclipse format as well as utility code used by other OPM modules. Source: opm-material Description: Material properties framework for porous media The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. . This header-only library contains the generic code for calculating material properties used when simulating porous media flow. It includes utilities for calculating relative-permeability/capillary pressure laws, thermodynamic relations, flash solvers, empirical heat conduction laws, et cetera.It uses automatic differentiation for calculating the properties. Source: opm-grid Description: DUNE grid implementations for reservoir simulation The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. . opm-grid provides implementations of grids for reservoir simulation, corner point or more general pillar grids, following the DUNE grid interface: CpGrid, a parallel corner point grid, and PolyhedralGrid a more general serial grid implementation of an unstructured, legacy, grid. . A standard grid type in the petroleum industry, corner-point grids fills the domain with a relatively low number of cells while still providing sufficient flexibility to model faults, fractures and erosion. The grid format was originally designed with an eye towards geological modeling rather than numerical simulation, but is still suitable for e.g. low order finite volume discretizations. Source: opm-models Description: C++ simulation framework for porous media flow -- development files The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. . opm-models is a header-only simulation framework which is primary focused on fully implicit models for flow and transport in porous media. It uses finite volume schemes for discretization and automatic differentiation for calculating the Jacobians. Its main objectives is to provide an easily usable, well maintainable, high performance framework which is capable of capturing all macro-scale scenarios relevant for academic research and industrial applications involving flow and transport processes in porous media. Source: opm-simulators Description: Parallel porous media / reservoir simulators The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. . opm-simulators provides a research (ebos) and a production (flow) fully implicit black-oil simulators, supporting one to three phases and supporting solvent and polymer options. It uses cell centered finite volume schemes with two point flux approximation and automatic differentiation for the discretization and uses state of the art linear and nonlinear
Bug#973412: libdune-istl-dev: package should recommend libscotchparmetis-dev
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 otherwise. Note that the non-free libparmetis-dev would resolve this, too, but is not usable by everybody. * What led up to the situation? Installing libdune-istl-dev without installing either libparmetis-dev or libptscotchparmetis-dev. Write an example program that uses AMG and run it on a parallel computer with more than 32 processes. >From a certain number of processes you will see a warning : "Successive accumulation of data on coarse levels only works with ParMETIS installed." * What exactly did you do (or not do) that was effective (or ineffective)? To remedy I need to install libscotchparmetis-dev and recompile the program. * What was the outcome of this action? Having libscotchparmetis-dev makes the warning go away * What outcome did you expect instead? I expected that just installing libdune-istl-dev would actually install libscotchparmetis-dev to make using the more scalable version of the parallel AMG solver the default in other/user DUNE modules. Thanks a lot in advance! Cheers, Markus -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libdune-istl-dev depends on: ii libdune-common-dev 2.6.0-3 ii libsuitesparse-dev 1:5.4.0+dfsg-1 ii libsuperlu-dev 5.2.1+dfsg1-4 libdune-istl-dev recommends no packages. Versions of packages libdune-istl-dev suggests: pn libdune-istl-doc -- no debconf information
Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"
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
Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"
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] https://bugs.gnucash.org/show_bug.cgi?id=797750 [3] https://github.com/Gnucash/gnucash/commit/659f785cb81396412e503b4d8f5fe22ceb3f39df
Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"
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 work but I did not check that. Looking forward to switching back to Debian packages once it is fixed there. Thanks a lot for all the hard work. HTH, Markus [1] https://lists.gnucash.org/wiki/De/Flatpak#Beispiel-Einrichtung (German)
Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"
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 Perioden" (alternate periods) is set to "Benutzen Sie letztes Jahr" (use last year). When change it to "Benutzen Sie Von - Bis" (Use from - to) and press either Ok are Anwenden (Apply) gnucash crashes with a segmentation fault. Here is the backtrace: Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. 0x72d077e8 in _wrap_gnc_mktime (s_0=0x170e47fbe) at ./libgnucash/engine/swig-engine.c:16747 16747 ./libgnucash/engine/swig-engine.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x72d077e8 in _wrap_gnc_mktime (s_0=0x170e47fbe) at ./libgnucash/engine/swig-engine.c:16747 #1 0x77e0b53f in () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1 #2 0x77e10d8f in scm_call_n () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #3 0x77d92b0f in scm_call_3 () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #4 0x77e0b53f in () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1 #5 0x77e10d8f in scm_call_n () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #6 0x77d92ac8 in scm_call_1 () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #7 0x7307af86 in gfec_eval_string (str=0x5b8c1950 "(gnc:report-run 0)", error_handler=0x7320d650 ) at ./libgnucash/app- utils/gfec.c:74 #8 0x7320db05 in gnc_run_report (report_id=, data=0x7fffbf68) at ./gnucash/report/report-system/gnc-report.c:163 #9 0x7320dc18 in gnc_run_report_id_string (id_string=, data=data@entry=0x7fffbf68) at ./gnucash/report/report-system/gnc- report.c:189 #10 0x76f48d15 in gnc_html_report_stream_cb (location=, data=0x7fffbf68, len=0x7fffbf64) at ./gnucash/report/report- gnome/window-report.c:273 #11 0x76f2e02f in load_to_stream (self=0x5c39e1c0, type=type@entry=0x5e9a3be0 "report", location=location@entry=0x5d2c4de0 "id=0", label=label@entry=0x0) at ./gnucash/html/gnc-html-webkit2.c:500 #12 0x76f2e9c5 in impl_webkit_show_url (self=0x5c39e1c0, type=, location=, label=, new_window_hint=) at ./gnucash/html/gnc-html-webkit2.c:891 #13 0x76f2b5da in gnc_html_show_url (self=0x5c39e1c0, type=, location=0x5d2c4de0 "id=0", label=0x0, new_window_hint=0) at ./gnucash/html/gnc-html.c:371 #14 0x76f45623 in gnc_plugin_page_report_option_change_cb (data=) at ./gnucash/report/report-gnome/gnc-plugin-page- report.c:749 #15 0x7308fa85 in _wrap_gncp_option_invoke_callback (s_0=, s_1=0x562250e0) at ./libgnucash/app-utils/swig-app-utils-guile.c:1591 #16 0x77e0b53f in () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1 #17 0x77e10d8f in scm_call_n () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #18 0x77d92ac8 in scm_call_1 () at /usr/lib/x86_64-linux- gnu/libguile-2.2.so.1 #19 0x7308d198 in gnc_call_option_change_callbacks (odb=0x5bedcd90) at ./libgnucash/app-utils/option-util.c:532 #20 0x7308d198 in gnc_option_db_commit (odb=0x5bedcd90) at ./libgnucash/app-utils/option-util.c:1817 #21 0x76f48b84 in gnc_options_dialog_apply_cb (propertybox=, user_data=0x56afd9b0) at ./gnucash/report/report-gnome/window- report.c:88 #22 0x730e8947 in gnc_options_dialog_ok_button_cb (widget=, win=0x5deae7c0) at ./gnucash/gnome-utils/dialog-options.c:2065 #23 0x76f9deb6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #24 0x76fba3a1 in g_signal_emit_valist () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #25 0x76fba90f in g_signal_emit () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #26 0x775a844d in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #27 0x775a84b5 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #28 0x76f9deb6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x76fba3a1 in g_signal_emit_valist () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #30 0x76fba90f in g_signal_emit () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #31 0x775a69c0 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #32 0x7200b8ee in ffi_call_unix64 () at /usr/lib/x86_64-linux- gnu/libffi.so.6 #33 0x7200b2bf in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6 #34 0x76f9e8f6 in g_cclosure_marshal_generic_va () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #35 0x76f9deb6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #36 0x76fba3a1 in g_signal_emit_valist () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #37 0x76fba90f in g_signal_emit () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #38 0x7766abd4 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #39 0x76fa0cf2 in
Bug#816109: libscotch-dev: Broken library symlink detected in libscotchparmetis-dev
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',
needed by 'cmTryCompileExec3172204297'. Schluss.
Makefile:118: recipe for target 'cmTryCompileExec3172204297/fast' failed
It turns out that all the following links are dangling:
/usr/lib/parmetis-int32:
insgesamt 0
lrwxrwxrwx 1 root root 21 Aug 21 2013 libparmetis.a -> libptscotchparmetis.a
lrwxrwxrwx 1 root root 22 Aug 21 2013 libparmetis.so -> libptscotchparmetis.so
/usr/lib/parmetis-int64:
insgesamt 0
lrwxrwxrwx 1 root root 21 Aug 21 2013 libparmetis.a -> libptscotchparmetis.a
lrwxrwxrwx 1 root root 22 Aug 21 2013 libparmetis.so -> libptscotchparmetis.so
/usr/lib/parmetis-long:
insgesamt 0
lrwxrwxrwx 1 root root 21 Aug 21 2013 libparmetis.a -> libptscotchparmetis.a
lrwxrwxrwx 1 root root 22 Aug 21 2013 libparmetis.so -> libptscotchparmetis.so
The apparent fix is that the links should point to the corresponding
libs in /usr/lib/scotch-{int32,int64,long}
This bug is similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715112
and depends on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71507
-- System Information:
Debian Release: 8.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libscotch-dev depends on:
ii libscotch-5.15.1.12b.dfsg-2+b1
ii mpi-default-dev 1.0.2+nmu2
ii zlib1g-dev 1:1.2.8.dfsg-2+b1
libscotch-dev recommends no packages.
libscotch-dev suggests no packages.
-- no debconf information
Bug#354463: Patch propsal
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 forward it upstream. Cheers, Markus diff -aur lapack-3.4.1+dfsg/src/CMakeLists.txt lapack-3.4.1+dfsg.new/src/CMakeLists.txt --- lapack-3.4.1+dfsg/src/CMakeLists.txt 2012-04-02 21:06:36.0 +0200 +++ lapack-3.4.1+dfsg.new/src/CMakeLists.txt 2013-08-19 22:50:06.548318037 +0200 @@ -48,7 +48,7 @@ set(ALLAUX ilaenv.f ieeeck.f lsamen.f iparmq.f ilaprec.f ilatrans.f ilauplo.f iladiag.f chla_transtype.f -../INSTALL/ilaver.f ../INSTALL/lsame.f xerbla.f xerbla_array.f +../INSTALL/ilaver.f ../INSTALL/lsame.f xerbla_array.f ../INSTALL/slamch.f) set(ALLXAUX ) diff -aur lapack-3.4.1+dfsg/src/Makefile lapack-3.4.1+dfsg.new/src/Makefile --- lapack-3.4.1+dfsg/src/Makefile 2012-04-02 21:06:36.0 +0200 +++ lapack-3.4.1+dfsg.new/src/Makefile 2013-08-19 22:49:37.524316460 +0200 @@ -54,7 +54,7 @@ # ### -ALLAUX = ilaenv.o ieeeck.o lsamen.o xerbla.o xerbla_array.o iparmq.o \ +ALLAUX = ilaenv.o ieeeck.o lsamen.o xerbla_array.o iparmq.o \ ilaprec.o ilatrans.o ilauplo.o iladiag.o chla_transtype.o \ ../INSTALL/ilaver.o ../INSTALL/lsame.o ../INSTALL/slamch.o diff -aur lapack-3.4.1+dfsg/SRC/CMakeLists.txt lapack-3.4.1+dfsg.new/SRC/CMakeLists.txt --- lapack-3.4.1+dfsg/SRC/CMakeLists.txt 2012-04-02 21:06:36.0 +0200 +++ lapack-3.4.1+dfsg.new/SRC/CMakeLists.txt 2013-08-19 22:50:06.548318037 +0200 @@ -48,7 +48,7 @@ set(ALLAUX ilaenv.f ieeeck.f lsamen.f iparmq.f ilaprec.f ilatrans.f ilauplo.f iladiag.f chla_transtype.f -../INSTALL/ilaver.f ../INSTALL/lsame.f xerbla.f xerbla_array.f +../INSTALL/ilaver.f ../INSTALL/lsame.f xerbla_array.f ../INSTALL/slamch.f) set(ALLXAUX ) diff -aur lapack-3.4.1+dfsg/SRC/Makefile lapack-3.4.1+dfsg.new/SRC/Makefile --- lapack-3.4.1+dfsg/SRC/Makefile 2012-04-02 21:06:36.0 +0200 +++ lapack-3.4.1+dfsg.new/SRC/Makefile 2013-08-19 22:49:37.524316460 +0200 @@ -54,7 +54,7 @@ # ### -ALLAUX = ilaenv.o ieeeck.o lsamen.o xerbla.o xerbla_array.o iparmq.o \ +ALLAUX = ilaenv.o ieeeck.o lsamen.o xerbla_array.o iparmq.o \ ilaprec.o ilatrans.o ilauplo.o iladiag.o chla_transtype.o \ ../INSTALL/ilaver.o ../INSTALL/lsame.o ../INSTALL/slamch.o
Bug#701866: libdune-common: New upstream release
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 2.2.0 for Debian. Of course this holds for all DUNE packages. If we can assist you, please yell! Kind regards, Markus -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdune-common-dev depends on: ii dpkg 1.16.9 ii libdune-common-2.2.0 2.2.0-1 Versions of packages libdune-common-dev recommends: ii autoconf2.69-1 ii automake1:1.11.6-1 ii libtool 2.4.2-1.1 ii pkg-config 0.26-1 Versions of packages libdune-common-dev suggests: pn libdune-common-dbg none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666203: libatlas-base-dev: update-alternatives missing some static libs (libblasf77.a, libatlas.a)
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 /usr/lib/libf77blas.a libf77blas.a /usr/lib/atlas-base/libf77blas.a \ --slave /usr/lib/libatlas.a libatlas.a /usr/lib/atlas-base/libatlas.a to the first call to update-alternatives in the postinst file /var/lib/dpkg/info/libatlas-base-dev.postinst. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libatlas-base-dev depends on: ii libatlas-dev 3.8.3-27 ii libatlas3gf-base 3.8.3-27 libatlas-base-dev recommends no packages. Versions of packages libatlas-base-dev suggests: pn libblas-docnone pn liblapack-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515116: Acknowledgement (libopenmpi-dev: Receive of cascaded derived datatypes disregards offset of inner custom type)
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515116: libopenmpi-dev: Receive of cascaded derived datatypes disregards offset of inner custom type
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 int at the beginning is/should be ignored.
This works fine if I use this data type on its own.
Unfortunately I need to send another struct that contains an int and
the int-char-char struct from above. Again I construct a custom MPI
data type for this.
When sending this cascaded data type It seems that the offset of the
char in the inner custom type is disregarded on the receiving end and the
received data ('1') is stored in the first int instead of the
following char.
I have tested this code with both lam and mpich. There it worked as
expected (saving the '1' in the first char.
The last two lines of the output of the attached test case read
received global=10 attribute=0 (local=1 public=0)
received attribute=1 (local=100 public=0)
for openmi instead off
received global=10 attribute=1 (local=100 public=0)
received attribute=1 (local=100 public=0)
for lam and mpich.
The same problem is experienced when using version 1.3-2 of openmpi
Cheers,
Markus
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28.4 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libopenmpi-dev depends on:
ii libc62.7-18 GNU C Library: Shared libraries
ii libopenmpi1 1.2.7~rc2-2 high performance message passing l
ii openmpi-common 1.2.7~rc2-2 high performance message passing l
libopenmpi-dev recommends no packages.
libopenmpi-dev suggests no packages.
-- no debconf information
#includempi.h
#includeiostream
struct LocalIndex
{
int local_;
char attribute_;
char public_;
};
struct IndexPair
{
int global_;
LocalIndex local_;
};
int main(int argc, char** argv)
{
MPI_Init(argc, argv);
int rank, size;
MPI_Comm_rank(MPI_COMM_WORLD, rank);
MPI_Comm_size(MPI_COMM_WORLD, size);
if(size2)
{
std::cerrno procs has to be 2std::endl;
MPI_Abort(MPI_COMM_WORLD, 99);
}
MPI_Datatype litype, ptype;
// Create custom MPI datatypes
{
int length[3]={1, 1, 1};
MPI_Aint disp[3];
MPI_Datatype types[3] = {MPI_LB, MPI_CHAR, MPI_UB};
LocalIndex rep[2];
MPI_Address(rep, disp); // lower bound of the datatype
MPI_Address((rep[0].attribute_), disp+1);
MPI_Address(rep+1, disp+2); // upper bound od the datatype
for(int i=2; i = 0; --i)
disp[i] -= disp[0];
MPI_Type_struct(3, length, disp, types, litype);
MPI_Type_commit(litype);
if(rank==0)
{
MPI_Aint lb,extent;
MPI_Type_get_extent(litype, lb, extent);
std::coutlitype: lb=lb extend=extentstd::endl;
MPI_Type_get_true_extent(litype, lb, extent);
std::couttrue litype: lb=lb extend=extentstd::endl;
int size;
MPI_Type_size(litype, size);
std::coutlitype size=sizestd::endl;
}
}
{
int length[4] ={1, 1, 1, 1};
MPI_Aint disp[4];
MPI_Datatype types[4] = {MPI_LB, MPI_INT,
litype, MPI_UB};
IndexPair rep[2];
MPI_Address(rep, disp); // lower bound of the datatype
MPI_Address((rep[0].global_), disp+1);
MPI_Address((rep[0].local_), disp+2);
MPI_Address(rep+1, disp+3); // upper bound of the datatype
for(int i=3; i = 0; --i)
disp[i] -= disp[0];
MPI_Type_struct(4, length, disp, types, ptype);
MPI_Type_commit(ptype);
if(rank==0)
{
MPI_Aint lb,extent;
MPI_Type_get_extent(ptype, lb, extent);
std::coutptype: lb=lb extend=extentstd::endl;
MPI_Type_get_true_extent(ptype, lb, extent);
std::couttrue: ptype: lb=lb extend=extentstd::endl;
int size;
MPI_Type_size(ptype, size);
std::coutptype size=sizestd::endl;
}
}
IndexPair pair;
if(rank==0)
{
pair.global_=10;
pair.local_.local_=1;
pair.local_.attribute_='1';
pair.local_.public_='1';
MPI_Send(pair, 1, ptype, 1, 199, MPI_COMM_WORLD);
MPI_Send(pair.local_, 1, litype, 1, 199, MPI_COMM_WORLD);
}else
{
pair.global_=0;
pair.local_.local_=100;
pair.local_.attribute_='0';
pair.local_.public_='0';
if(rank==1)
{
MPI_Status status;
MPI_Recv(pair, 1, ptype, 0, 199, MPI_COMM_WORLD, status);
std::coutreceived global=pair.global_ attribute=
pair.local_.attribute_ (local=pair.local_.local_
public=pair.local_.public_)std::endl;
pair.local_.local_=100;
pair.local_.attribute_='0';
pair.local_.public_='0';
MPI_Recv(pair.local_, 1, litype, 0, 199, MPI_COMM_WORLD, status);
std::coutreceived attribute=pair.local_.attribute_
(local=pair.local_.local_
Bug#436230: libhypre-dev: modified superlu headers get installed under /usr/include
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 headers in /usr/include/superlu/supermatrix from package libsuperlu3-dev. Any dumb user (like me) would assume the headers under /usr/include to be the original ones, which is not the case here. As a remedy I would suggest installing all hypre headers under /usr/include/hypre instead. Cheers, Markus -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages libhypre-dev depends on: ii atlas3-sse2-dev [libblas-3.so 3.6.0-20.6 Automatically Tuned Linear Algebra ii libhypre1.6.0c2 1.6.0-4High Performance Matrix Preconditi ii refblas3-dev [libblas-3.so] 1.2-8 Basic Linear Algebra Subroutines 3 libhypre-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311550: If sugarplum modifies apache2 config it does not activate mod_rewrite
Package: sugarplum Version: 0.9.10-10 Severity: wishlist Hi, I just installed sugarplum and lazy as I am, I told it to change my apache2 config. This it did but unfortunately the needed mod_rewrite was not activated automatically. It would really be need if sugarplum coult check whether 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 of packages sugarplum depends on: ii debconf 1.4.30.13 Debian configuration management sy ii perl 5.8.4-8Larry Wall's Practical Extraction ii wamerican [wordlist] 5-4American English dictionary words ii wenglish 5-4American English dictionary words ii wngerman [wordlist] 20030222-7 New German orthography wordlist -- debconf information: * sugarplum/configure_httpd: true sugarplum/removeoldconf: sugarplum/deconfigure_httpd: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
