Bug#1067055: Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers It looks like libpmix-dev is only used by mpich, openmpi and slurm-wlm. mpich will be configured not to use pmix on 32-bit systems anyway slurm-wlm builds ok without pmix; it can be patched to use pmix only on 64-bit systems. openmpi in sid (4.1.6-7) has an internal copy of pmix 4.1.2 that it can be configured to use. I can prepare this for openmpi on the debian/trixie branch; to upload with a fix for #1067055, regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1067055: Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. Doesn't make it better. This is not the time to do that without tests builds and bugs filed. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) Beside the easy part of chaning mpi-defaults, I count 30 something packages that have explicit build dependencies on libopenmpi-dev. None of those packages has bugs filed to change to mpich on 32 bit architectures. To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers I checked with "build-rdeps libopenmpi-dev" and checked the packages. They are mostly false-alarms. What is needed: * mpich not to use libpmix for 32-bit archs. I've a patch i'm testing. * armci-mpi builds on both mpich, openmpi. Needs work to only build on openmpi on 64-bit. #10683219 * code-saturne: Uses the default mpi version of hdf5. #1068318 * adios: fix just uploaded. * vtk9: Depends on libhdf5-openmpi-dev instead of libhdf5-mpi-dev. #1068321 * trilinos: deps on openmpi , but only available on 64-bit systems. No change needed * hdf5: Needs to depend on 64-bit archs for libopenmpi-dev. #1068320 * scalapack: Needs to dep on 64-bit archs only for libopenmpi-dev. #1068322 Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 01/04/2024 23:25, Sebastian Ramacher wrote: There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition. It drops 32-bit support from OpenMPI. Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months. While we didn't want the transitions to be done simultaneously, it might be the best answer. What does the release team think? Adding another transition on top will just delay the time_t transition even more. So if we can avoid that, I'd prefer to not do this transition now. Unfortunately, uploads such as the one of pmix that no dropped support for 32 bit architectures (#1068211) are not really helpful. Also, #1064810 has no information on test builds with the new mpi-defaults on a 32 bit architecture. So has this transition been tested? Cheers OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) I'm sorry I missed the dropped 32-bit support for pmix; I tested on 64-bit platforms only. Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 23/03/2024 01:58, Thorsten Glaser wrote: Andrey Rakhmatullin dixit: OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64 And I assume this arch doesn't have 64-bit atomics. No native ones, yes. I *think* either libatomic or libatomic_ops(?) make them available, but very slowly, using a syscall to guarantee atomicity (those systems are normally uniprocessor) on m68k. If possible, avoiding them would be preferrable. (For example, in some cases, like reading a 64-bit timestamp, if the writing direction is known and stable, reading twice then comparing is a possible alternative at least for some architectures (e.g. I know BSD code for sparc does it that way). I guess you’ll have to ask the porters of 32-bit arches with no native 64-bit atomics for details. Though I had thought GCC’s builtin atomics use the aforementioned kernel-based workaround from that library these days? There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition. It drops 32-bit support from OpenMPI. Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months. While we didn't want the transitions to be done simultaneously, it might be the best answer. What does the release team think? bye, //mirabilos -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite
Package: python3.12 Version: 3.12.1-2 Severity: serious Justification: 4 X-Debbugs-Cc: debian-pyt...@lists.debian.org Python3.12 segfaults on the unittest suite for python-xarray (2024.01.0, head of tree in debian/latest) Unfortunately I cannot get a core dump yet to be more specific; this is on arm64 at least. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055848: Reproducing
I've now been able to setup autopkgtest locally based on sbuild. I get failures in an autopkgtest (sbuild sid) chroot, but not when I do a clean pbuilder chroot via sid to do "pbuilder login". Investigating the differences between what should be identical chroots. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 27/12/2023 21:30, Drew Parsons wrote:
Hi Alistair, given the complexity around hacking openmpi to
accommodate placing the mod files under /usr/include, I'm starting to
wonder whether it's the best way of resolving Bug#1058526 in the first
place.
I did it bit of background reading on the fortran mod files. There's a
fair bit of dissent about them, and no consensus on a proper
location. e.g. https://fortranwiki.org/fortran/show/Library+distribution
The files are binary dependent (and compiler version dependent), and
not clear that /usr/include is the best place for them anyway.
mpich seems to be fine placing them in
/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/mpich, and openmpi
seemed to be happy enough doing the same up until Bug#1058526.
Is there a different way of resolving Bug#1058526 without moving the
mod files to /usr/include?
Drew
I had altered FMODDIR from /usr/lib/ to /usr/include to match what
appears to be most conventional, but given the problems caused, I'm
backing out that change and reverting to /usr/lib/${DEB_HOST_MULTIARCH}/.
It will take changes in dh-fortran-mod and openmpi which I'm doing today.
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 27/12/2023 08:45, Drew Parsons wrote:
On 2023-12-26 12:45, Drew Parsons wrote:
I can manually reproduce the error trivially on an arm64 chroot
(amdahl.debian.org). Copying hello.f90 from openmpi's debian/tests
and manually running
mpif90 -o hello hello.f90
reproduces the error reference to the x86_64 include path on the
arm64 machine.
`mpif90.openmpi -print-search-dirs` only shows aarch64 paths though.
I guess the problem must be the common files from openmpi-common in
/usr/share/openmpi/. They're not actually arch-independent. Do
mpif90.openmpi and the other components actively read them at runtime?
For instance, /usr/share/openmpi/mpif90.openmpi-wrapper-data.txt contains
fmoddir=/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15
Since openmpi-common is marked Arch: all, it's only built once, on
amd64, hence x86_64-linux-gnu gets carried to the other arches. The
compiler_flags variables is also affected, alongside as fmoddir.
It looks like only the mpi fortran wrapper txts are affected,
mpif77-wrapper-data.txt
mpif77.openmpi-wrapper-data.txt
mpif90-wrapper-data.txt
mpif90.openmpi-wrapper-data.txt
mpifort-wrapper-data.txt
mpifort.openmpi-wrapper-data.txt
Should these be moved from openmpi-common to libopenmpi-dev (or
openmpi-bin)
at /usr/lib//openmpi/share ?
This appears to be it. I've been building on arm64 recently (a VM on a
mac) and don't see this.
There appears to be a mechanism for including ${includedir} and
${libdir} and evaluating the wrapper-data files at runtime. My hacking
on these files in d/rules is causing the errors. I'll work on a better
solution.
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 24/12/2023 10:50, Drew Parsons wrote: reopen 1058876 block 1058944 by 1058876 thanks Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi fortran modules has hardcoded x86_64-linux-gnu This is preventing builds and tests on other architectures, e.g. rebuilding sundials for the petsc transition. I think openmpi's debian/tests will also need Depends: pkg-config for the new compile_run_cc_pkgconfig test. The problem appears to be the heuristics in upstream/FindMPI.cmake in adios2 (and sundials). It happens in sid tests but not my arm64 devel environment. Debugging slowly. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1055848: Processed: Re: cfgrib failing to find eccodes
I cannot reproduce this locally yet - running the tests in a clean chroot works fine. However ecmwflibs was failing when I tested it - but worked ok when rebuilt, so I've added a superficial test for autopkgtest to it, to see if it breaks on its own in the CI pipeline. Alastair On 10/12/2023 18:51, Debian Bug Tracking System wrote: Processing control commands: retitle -1 cfgrib: test failure - can't find eccodes Bug #1055848 [src:cfgrib] cfgrib: autopkgtest regression Changed Bug title to 'cfgrib: test failure - can't find eccodes' from 'cfgrib: autopkgtest regression'. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1056054: Reported upstream
I've opened a bug upstream in prrte. https://github.com/openpmix/prrte/issues/1849 -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1050854: Please push your changes to python-xarray
Hi Apologies I am swamped on this. Please go ahead and apply. Thanks Alastair On 13/11/2023 12:51, Andreas Tille wrote: Ping? I'd love to apply the patch from the bug report and push everything properly. If I do not hear from you I might consider mass-commiting all the releases you made without pushing to the repository in one single commit and add what I'd like to commit. Kind regards Andreas. Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille: Hi Alastair, I realised that the Git repository on salsa[1] is lagging a couple of uploads behind the package pool. Please be so kind to push your changes to Salsa. Thanks a lot for your work on this package Andreas. [1] https://salsa.debian.org/science-team/python-xarray -- http://fam-tille.de -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1051017: cdo: Major data error with ICON files
Package: cdo Version: 2.2.1 Severity: serious Tags: upstream Justification: 2 X-Debbugs-Cc: Momtchil Momtchev Just a heads up that there is a serious issue with the cdo version in bookworm - it produces broken (flipped on the Y-axis) GRIBs when "remapping" (extracting) data from the ICON output files. The one in bullseye works correctly. As this is probably the number one reason commoners use cdo, it is a major showstopper. Here is the original bug report: https://code.mpimet.mpg.de/boards/1/topics/14808 The issue has been fixed in 2.2.2. -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cdo depends on: ii libc6 2.36-9+deb12u1 pn libcdi0 ii libcurl3-gnutls 7.88.1-10+deb12u1 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 12.2.0-14 ii libgomp1 12.2.0-14 pn libhdf5-103-1 pn libmagplus3v5 pn libnetcdf19 pn libproj25 ii libstdc++612.2.0-14 pn libudunits2-0 Versions of packages cdo recommends: pn python3-cdo cdo suggests no packages.
Bug#1039871: proposed patch fails
Hi Unfortunately the proposed patch doesn't fix the problem. With later versions of xarray now using pooch to download data, and failing if its not setup, a better fix to the download issue is needed. regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1030268: marked as pending in fparser
Control: tag -1 pending Hello, Bug #1030268 in fparser reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/fparser/-/commit/ca1a17bacfaa03b2075c375f4a9675d6f89c10e3 Changes to d/rules from Sebastian Ramacher to build on all pyvers Closes: #1030268 (this message was generated automatically) -- Greetings https://bugs.debian.org/1030268
Bug#1022255: fixed in python-xarray 2022.11.0-2
Dear Antonio Apologies but I saw this too late to stop the transition to testing. At this stage, I believe the best solution is to work on the issues in satpy and dask; I can help. Best regards Alastair On 07/12/2022 08:38, Antonio Valentino wrote: Dear Alastair, On Mon, 21 Nov 2022 15:12:02 + Debian FTP Masters wrote: Source: python-xarray Source-Version: 2022.11.0-2 Done: Alastair McKinstry We believe that the bug you reported is fixed in the latest version of python-xarray, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1022...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Alastair McKinstry (supplier of updated python-xarray package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 21 Nov 2022 14:37:38 + Source: python-xarray Architecture: source Version: 2022.11.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Alastair McKinstry Closes: 1004869 1022255 1023222 Changes: python-xarray (2022.11.0-2) unstable; urgency=medium . * Ack bogs fixed in this and previous releases: Closes: #1022255, #1004869, #1023222 Checksums-Sha1: 25bfc4ad68c46f9f7428c7a008736478f3bd2fa7 3395 python-xarray_2022.11.0-2.dsc 9d5fa48523ea38b6684f9b18e3d3a10a8aee2875 14092 python-xarray_2022.11.0-2.debian.tar.xz Checksums-Sha256: 2921fcf4d7b5b82ed54813180ceacb2261264e99eb22e1b9bcf11e8660755e6e 3395 python-xarray_2022.11.0-2.dsc c480af287094772516773b559ac385d6eed33001e1ded8aa1ddab4db721fc91b 14092 python-xarray_2022.11.0-2.debian.tar.xz Files: 16ee7843761bf700d78213b6a8061f38 3395 python optional python-xarray_2022.11.0-2.dsc b483b08efbb572a27c4af434d3df17d1 14092 python optional python-xarray_2022.11.0-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmN7jiUACgkQy+a7Tl2a 06Vb0Q//YmFju6NG15oqqygNRQiiGIGPXS+qvtwPbXKGJDq6g3rX24KdF2tP77i6 Aw9LjfskclEe7TRQCwaS/49qh+6CE+Tndv47nMGb3jnBGL0vYa9YqOn3XeBAHCcw aYCvbkks5HxDWizJ6Kh2Ohef0okEl2Q/pHDKMDfF+Q8DEvGh7iFtedVF6ARquPSW 95u3V6QhCCQPws26cYPz1L2a+QJuEf49lohoVDC8u4EtaJHbv1NKXtQP1srEqf10 zqbSd6KDqT3mn4dONtF7etxzQGxSHRySEPJpXQ+2kkdmcueLUT5UAEazC6SCdCUB GMCqMFbwi4kY7CaaK5646XxCm3QQUg3UeZAMHqsBI9gYModfKG8twRhlyA4N9mam Unfortunately version 2022.11.2 and 2022.12.0 of xarray still causes test failures in satpy. According to the satpy upstream developers [1] (also reported in one of the previous messages [2]), the problem should be related to some kind of incompatibility between new versions of xarray and the version of dask currently in Debian (2022.02.0). I can confirm that updating dask to 2022.11.1 fixes the issues and satpy tests pass with dask 2022.11.1 and xarray 2022.12.0. I have started preparing a Merge Request [3] to update the dask package. Unfortunately, while the Python package itself builds and works well, it is currently not possible to build the -doc package because of outdated build dependencies or new build dependencies still not in debian. In addition, there are some other test failures in satpy that are not related to xarray/dask and could be fixed with an update to the latest upstream version of satpy (0.38.0). I have the packaging work done (locally), but I cannot upload until the problem with xarray/dask is solved. In conclusion the satpy version currently in testing works perfectly with xarray 2022.06.0, but the migration of xarray 2022.12.0 would break satpy and make it unbuildable both in testing and unstable. Honestly I'm not sure about what is the best way to proceed. In principle I think that this issue should be re-open and xarray 2022.12.0 should not migrate, for the moment at least. But then the way forward is not clear to me. Waiting for an update of dask could take some time. Of course I would be more that happy to help to prepare a new version of the dask package. What is your idea about how to proceed? [1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022255#16 [3] https://salsa.debian.org/python-team/packages/dask/-/merge_requests/1 kind regards -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024859: change in the extention importation with 3.11
On 06/12/2022 16:13, PICCA Frederic-Emmanuel wrote: There is a fix from the upstream around enum. https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 Fix enum_type_object type on Python 3.11 The enum_type_object type inherits from PyLong_Type which is not tracked by the GC. Instances doesn't have to be tracked by the GC: remove the Py_TPFLAGS_HAVE_GC flag. The Python C API documentation says: "To create a container type, the tp_flags field of the type object must include the Py_TPFLAGS_HAVE_GC and provide an implementation of the tp_traverse handler." https://docs.python.org/dev/c-api/gcsupport.html The new exception was introduced in Python 3.11 by: python/cpython#88429 an opinion ? I'd favour that being added to boost1.74. It would fix my ecflow bug (#1024911). A minor (?) fix also needed for Swig wrapping too (#1024555) -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024555: Fwd: swig4.0 bug causes FTBFS of XDMF
clone 1023911 -1 reassign -1 swig thanks As of the latest swig4.1.0 , Xdmf FTBFS due to bad code being generated. Some elements such as SWIGPY_SLICEOBJECT are not defined. Adding """ %include """ to /usr/share/swig4.0/python/python.swg fixes this. This is currently a blocker for the python3.11 transition. Best regards Alastair McKinstry -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024911: change in the extention importation with 3.11
On 06/12/2022 13:47, picca wrote:
Hello, I am trying to fix this bug
I'm debugging something similar,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024911
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024859
I find the error message not very informative...
:~/$ python3.11
Python 3.11.0+ (main, Nov 4 2022, 09:23:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
import scitbx_linalg_ext
Traceback (most recent call last):
File "", line 1, in
SystemError: initialization of scitbx_linalg_ext raised unreported
exception
The problem is that python is catching a C/C++ exception.
You can debug with:
gdb /usr/bin/python3.11
...
(gdb) catch throw
(gdb) run
>> import scitbx_linalg_ext
...
I would like your opinion and some help in order to fix this or at
least understand what is going on.
ther extension was build with boost_python, maybe something is wrong
also with boost_python and Python3.11.
I do not know if other packages using boost_python are affected like
this.
thanks for considering
Frederic
Both cctbx and ecflow are breaking on generating new enums.
A simple test case is:
```
#include
using namespace boost::python;
// enum has flags 0x42000, no traversefunction set
class CheckPt {
public:
/// NEVER - the check pt file is never saved
/// ON_TIME - the check pt file is saved periodically. specified by
checkPtInterval.
/// ALWAYS - the check pt file is saved after any state change
/// UNDEFINED - Internal use only
enum Mode { NEVER, ON_TIME, ALWAYS, UNDEFINED};
};
void inc_enum () {
enum_("CheckPt",
"CheckPt is enum that is used to control check pointing in
the `ecflow_server`_\n\n"
"- NEVER : Switches of check pointing\n"
"- ON_TIME: `check point`_ file is saved periodically,
specified by checkPtInterval. This is the default.\n"
"- ALWAYS : `check point`_ file is saved after any state
change, *not* recommended for large definitions\n"
"- UNDEFINED : None of the the above, used to provide
default argument\n"
)
.value("NEVER", CheckPt::NEVER)
.value("ON_TIME",CheckPt::ON_TIME)
.value("ALWAYS", CheckPt::ALWAYS)
.value("UNDEFINED", CheckPt::UNDEFINED)
;
}
char const *greet()
{
return "Hello world\n";
}
BOOST_PYTHON_MODULE(wrapper)
{
def ("greet", greet);
inc_enum();
}
```
What appears to be happening is a change in python3.11:
https://docs.python.org/ja/3.11/whatsnew/3.11.html
The PyType_Ready() function now raises an error if a type is
defined with the Py_TPFLAGS_HAVE_GC flag set but has no traverse
function (PyTypeObject.tp_traverse). (Contributed by Victor
Stinner in bpo-44263.)
and indeed, the enum types are created without a traverse function but
with the HAVE_GC flag set.
It doesn't at first glance look like the code for boost1.80 is different.
A Python/boost expert is now needed.
Regards
Alastair McKinstry
mckins...@debian.org
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1021603: libpmix2
It appears that openmpi needs to be rebuilt with the latest pmix. This works locally for me, but an attempt to do so (on the autobuilds) was blocked by a separate bug in pmix. Will retry Alastair On 16/10/2022 23:23, Ron Lovell wrote: Should have said Arch Linux Issue 75727. On Sun, Oct 16, 2022 at 5:20 PM Ron Lovell wrote: Same issue as Arch issue 279267? -- James Ronald Lovell Huntsville, AL, USA -- James Ronald Lovell Huntsville, AL, USA -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1021603: libpmix2: 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)
This appears to be fixed locally for me by rebuilding openmpi against the latest pmix. I'm doing a rebuild now Alastair On 11/10/2022 16:50, Andreas Beckmann wrote: Package: libpmix2 Version: 4.2.1-2 Severity: serious Hi, the new pmix version in sid causes autopkgtest regressions, e.g. https://ci.debian.net/data/autopkgtest/testing/amd64/o/openmpi/26943322/log.gz autopkgtest [01:13:33]: test check_shared_objs: [--- [ci-284-796c5454:01766] 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) autopkgtest [01:13:34]: test check_shared_objs: ---] autopkgtest [01:13:34]: test check_shared_objs: - - - - - - - - - - results - - - - - - - - - - check_shared_objsFAIL non-zero exit status 1 I see similar errors when rebuilding src:p4est while the tests are running. This works fine with the version in testing. Andreas -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error
Package: autoconf-archive Version: 20220211-1 Severity: serious Tags: patch Justification: Policy 4.6 m4/ax_cc_maxopt.m4 has a syntax error that causes silo-llnl to FTBFS. See #1017240. The following patch fixes it: --- ax_cc_maxopt.m4.orig2022-08-19 16:13:36.230050352 +0100 +++ ax_cc_maxopt.m4 2022-08-19 16:13:47.994113092 +0100 @@ -146,6 +146,7 @@ nvhpc) # default optimization flags for nvhpc CFLAGS="$CFLAGS -O3" +;; gnu) # default optimization flags for gcc on all systems thanks Alastair -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autoconf-archive depends on: ii dpkg 1.20.11 Versions of packages autoconf-archive recommends: ii autoconf 2.69-14 autoconf-archive suggests no packages. -- no debconf information
Bug#1004556: libmpich-dev: The simplest MPI program compiled with mpich crashes
I can disable pmix support in mpich. Pmix is working fine in openmpi, so it’s an mpich/pmix issue of some sort (or maybe ch4) Regards Alastair On 22/02/2022, 14:57, "debian-science-maintainers on behalf of Drew Parsons" wrote: Package: mpich Followup-For: Bug #1004556 My guess is that this bug is ongoing in 4.0-2 because of pmix support. 4.0-2 is still configured --with-pmix=/usr/lib/x86_64-linux-gnu/pmix2 and still Depends: libpmix2 (>= 4.1.2) pmix support was added in 4.0~b1-2 along with ucx. I gather ucx was deactivated in 4.0-2 but pmix was not. Looks like pmix also needs to go (unless the problem is ch4, which was also added in 4.0~b1-2). But the error message references PMIX. Ironically, I find that an executable compiled against mpich 4.0-1 fails with mpiexec.mpich (as raised in this bug) but actually passes when run with mpiexec.openmpi. Awkward. -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#996642: FTBFS with glibc 2.32
Hi Nilesh Just uploaded a patched csh now. Apologies I was trying to port a later snapshot of csh but ran into porting issues. Regards Alastair From: Nilesh Patra Date: Monday 25 October 2021 at 11:17 To: <996...@bugs.debian.org> Cc: Alastair McKinstry Subject: Re: csh: FTBFS with glibc 2.32 (Resending with a different email, since my earlier mail bounced back, because of your DNS seeing it with invalid SPF) Hi Alastair, On Sat, 16 Oct 2021 18:47:48 +0200 Graham Inggs wrote: > Source: csh > Version: 20110502-6 > Severity: serious > Tags: ftbfs patch bookworm sid > > Hi Maintainer > > As can be seen in reproducible builds [1], csh FTBFS since glibc 2.32 > was uploaded. > I've attached a patch from Ubuntu where this was fixed already. Can you please upload this with Graham's patch? Since this is triggering a huge number of (warnings for) autoremovals Nilesh
Bug#994937: openscad: FTBFS ( due to cgal changes ?)
Package: openscad Version: 2021.01-1) Severity: serious Tags: ftbfs openscad now FTBFS: g++ -c -pipe -DSTACKSIZE=8388608 -fno-strict-aliasing -g -O2 -ffile-prefix-map=/build/openscad-2021.01=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++1y -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include -I/usr/include/libxml2 -I/usr/include/lib3mf -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DEIGEN_DONT_ALIGN -frounding-math -D_REENTRANT -Wall -Wextra -Wno-unused-local-typedefs -fPIC -DOPENSCAD_VERSION=2021.01 -DOPENSCAD_SHORTVERSION=2021.01 -DOPENSCAD_YEAR=2021.0 -DOPENSCAD_MONTH=01.0 -DOPENSCAD_DAY=.0 -DSTACKSIZE=8388608 -DUSE_QOPENGLWIDGET -DENABLE_DBUS -DENABLE_JOYSTICK -DENABLE_QGAMEPAD -DENABLE_CAIRO -DENABLE_SPNAV -DENABLE_LIBZIP -DENABLE_LIB3MF -DENABLE_OPENCSG -DENABLE_CGAL -DCGAL_HEADER_ONLY -DUSE_SCINTILLA_EDITOR -DQSCINTILLA_DLL -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GAMEPAD_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_NETWORK_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -Isrc -Isrc/ext/libtess2/Include -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -I/usr/include/x86_64-linux-gnu/qt5/QtGamepad -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtDBus -I/usr/include/x86_64-linux-gnu/qt5/QtCore -Iobjects -I/usr/include/eigen3 -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o objects/src/cgalutils-polyhedron.o src/cgalutils-polyhedron.cc src/cgalutils-polyhedron.cc: In instantiation of 'std::string CGALUtils::printPolyhedron(const Polyhedron&) [with Polyhedron = CGAL::Polyhedron_3 >; std::string = std::__cxx11::basic_string]': src/cgalutils-polyhedron.cc:351:63: required from here src/cgalutils-polyhedron.cc:346:29: error: 'generic_print_polyhedron' was not declared in this scope 346 | generic_print_polyhedron(sstream, p, writer); | ^~~~ make[2]: *** [Makefile:5723: objects/src/cgalutils-polyhedron.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/build/openscad-2021.01' dh_auto_build: error: make -j2 returned exit code 2 make[1]: *** [debian/rules:41: override_dh_auto_build] Error 25 make[1]: Leaving directory '/build/openscad-2021.01' make: *** [debian/rules:32: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openscad depends on: pn lib3mf1 pn libboost-filesystem1.74.0 pn libboost-program-options1.74.0 ii libboost-regex1.74.0 [libboost-regex1.74.0-icu67] 1.74.0-9 ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libdouble-conversion3 3.1.5-6.1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libglib2.0-0 2.66.8-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgmp10 2:6.2.1+dfsg-1 ii libharfbuzz0b 2.7.4-1 ii libmpfr6 4.1.0-3 pn libopencsg1 pn libqscintilla2-qt5-15 pn libqt5core5a pn libqt5dbus5 pn libqt5gamepad5 pn libqt5gui5 | libqt5gui5-gles pn libqt5multimedia5
Bug#994835: vice: Fails to build -- missing JPEG support
Package: vice Version: 3.5.0.dfsg-3 Severity: serious Tags: ftbfs Justification: ftbfs checking for png.h... yes checking for png_sig_cmp in -lpng... yes checking for jpeglib.h... no configure: error: JPEG support is missing make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 1 make[1]: Leaving directory '/build/vice-3.5.0.dfsg' make: *** [debian/rules:60: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 I: copying local configuration Best regards Alastair -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#994824: slop: FTBFS on sid
Package: slop Version: 7.5 Severity: serious Tags: ftbfs Justification: FTBFS This package now Fails to build in unstable: [ 80%] Building CXX object CMakeFiles/slopy.dir/src/glrectangle.cpp.o /usr/bin/c++ -DCXXOPTS_USE_UNICODE -DSLOP_OPENGL=\"True\" -DSLOP_VERSION=\"v7.5\" -Dslopy_EXPORTS -I/build/slop-7.5/obj-x86_64-linux-gnu -g -O2 -ffile-prefix-map=/build/slop-7.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -MD -MT CMakeFiles/slopy.dir/src/glrectangle.cpp.o -MF CMakeFiles/slopy.dir/src/glrectangle.cpp.o.d -o CMakeFiles/slopy.dir/src/glrectangle.cpp.o -c /build/slop-7.5/src/glrectangle.cpp /build/slop-7.5/src/framebuffer.cpp: In member function 'void slop::Framebuffer::setShader(slop::Shader*)': /build/slop-7.5/src/framebuffer.cpp:55:9: error: 'XDestroyImage' was not declared in this scope; did you mean 'eglDestroyImage'? 55 | XDestroyImage( image ); | ^ | eglDestroyImage make[3]: *** [CMakeFiles/slopy.dir/build.make:219: CMakeFiles/slopy.dir/src/framebuffer.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/build/slop-7.5/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:114: CMakeFiles/slopy.dir/all] Error 2 make[2]: Leaving directory '/build/slop-7.5/obj-x86_64-linux-gnu' Best regards Alastair McKinstry -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages slop depends on: ii libc62.31-13 ii libgcc-s110.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libicu67 67.1-7 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxrender1 1:0.9.10-1 slop recommends no packages. slop suggests no packages.
Bug#994480: ball: FTBFS following glibc change
Package: ball Version: 1.5.0+git20180813.37fc53c-6) Severity: serious Tags: ftbfs Justification: 4 FTBFS The package FTBFS : /srv/build/glew/rebuild/ball-1.5.0+git20180813.37fc53c/include/BALL/CONCEPT/XDRPersistenceManager.h:12:10: fatal error: rpc/types.h: No such file or directory 12 | #include | ^ This is due to a recent change in glibc; these headers are now in libtirpc-dev regards Alastair -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#993992: i386 regression
The bugs on mips, mips64el were unrelated – a problem with the proj8.patch (headers now conflicting due to proj.h in proj8 conflicting with hdf-eos5). This was resolved in 6.6.2-9. Remaining is a definite regression with gcc, or more correctly gfortran ; testing with gfortran 10.2.1-6 from bullseye works ; regression with 10.3.0-10 (and also 11.2.0-5). The generated “Iftran” compiler created from Iftran.f fails to compile correctly. Alastair
Bug#993631: cfgrib FTBFS: test failures
This is a bug in python3-eccodes which now depends on ecmwflibs. Ecmwflibs in now in the NEW queue On 03/09/2021, 21:51, "Adrian Bunk" wrote: Source: cfgrib Version: 0.9.9.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=cfgrib=0.9.9.0-1
Bug#984956: Pmix issues with openmpi-4.1.0
Ok, openmpi, redone ucx (to avoid 1.10.1~rc1 ) uploaded and unblock sent. Alastair On 16/05/2021, 06:39, "Lucas Nussbaum" wrote: Hi Alaitair, Thanks a lot for fixing this. Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Lucas
Bug#984956: Pmix issues with openmpi-4.1.0
Hi Paul To confirm: You mean do an upload of 1.10.0~rc1-7 <https://packages.debian.org/source/testing/ucx> (current testing UCX) as 1.10.1 <https://packages.debian.org/source/unstable/ucx>~rc1.really.1.10.0-1? <https://packages.debian.org/source/unstable/ucx> thanks Alastair On 20/05/2021 16:33, Paul Gevers wrote: Hi Alastair, On Sun, 16 May 2021 07:25:51 +0100 Alastair McKinstry wrote: No, I wanted to wait and check if there were any issues before issuing an unblock request. ucx is not bullseye material, it doesn't comply at all with the release policy. It would be best if ucx is reverted to the previous version (e.g. using an +really version name). And openmpi rebuild after that. On 16/05/2021 06:35, Lucas Nussbaum wrote: Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Paul -- Alastair McKinstry, email:alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#989111: libopenmpi-dev: broken symlinks: /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_{ofi,ompio}.so
This appears to be limited to i386/ 32-bit systems. They're shipped elsewhere. There have been changes on 32-bit support. Thanks Alastair On 26/05/2021 08:15, Andreas Beckmann wrote: Package: libopenmpi-dev Version: 4.1.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. From the attached log (scroll to the bottom...): 7m38.7s ERROR: FAIL: Broken symlinks: /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_ofi.so -> libmca_common_ofi.so.10.0.1 (libopenmpi-dev:i386) /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_ompio.so -> libmca_common_ompio.so.41.29.1 (libopenmpi-dev:i386) The corresponding libraries do not seem to be shipped in libopenmpi3 any longer. cheers, Andreas -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#984956: Still occurring here with 4.1.0-9
Alastair McKinstry
Hi
Can you confirm that openmpi 4.1.0-9 is present on all the nodes ?
Regards
Alastair
From: Dominique Brazziel
Reply to: Dominique Brazziel , <984...@bugs.debian.org>
Date: Thursday 20 May 2021 at 13:03
To: "984...@bugs.debian.org" <984...@bugs.debian.org>
Subject: Bug#984956: Still occurring here with 4.1.0-9
Resent from: Dominique Brazziel
Resent to:
Resent date: Thu, 20 May 2021 12:03:02 +
I installed openmpi-{bin, common} V4.1.0-9 from unstable and still have the
problem.
mpirun.openmpi -host X:2,Y:2 hostname results in the same ORTE_ERROR_LOG
messages
followed by FORCE-TERMINATE.
Bug#984956: Pmix issues with openmpi-4.1.0
Hi Lucas Yikes. No, I wanted to wait and check if there were any issues before issuing an unblock request. Alastair On 16/05/2021 06:35, Lucas Nussbaum wrote: Hi Alaitair, Thanks a lot for fixing this. Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Lucas -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#984956: Pmix issues with openmpi-4.1.0
See in part the discussion upstream at : https://github.com/open-mpi/ompi/issues/8596 One workaround might be to use the internal pmix. 4.1.0-4 worked, and using the internal pmix works, BUT reverting to using internal pmix has big testing consequences: We'd move libpmix.so.2 from the external libpmix ($LIBDIR/libpmix.so.2) to libopenmpi3 ($LIBDIR/openmpi/lib/libpmix.so.2) also involves including pmix headers in libopenmpi-dev and re-testing apps accordingly. Currently libopenmpi-dev depends on libpmix-dev , which means 'build-rdeps libpmix-dev' lists 313 packages. Fortunately only the pmix and openmpi source packages are really involved (mpich 3.4.1 didn't correctly work with libpmix so its not built with it - a flag/hint?) but if we simply move to internal pmix we will be shipping 2 sets of pmix headers. I get 4.1.0-4 to work only by excluding libpmix-dev when building to avoid accidental collisions. We could put Build-Conflicts: libpmix-dev into openmpi but we need to test this. Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#981289: udunits breaks gnudatalanguage autopkgtest
Ok, found the bug (and a fix). Instead of looking at the default xml path for the datafile, it tries to calculate the path in absolute terms, does it badly, and always prepends "/lib". Simple fix is to revert to 2.26 behaviour. Regards Alastair On 28/01/2021 19:59, Ole Streicher wrote: Control: notfound -1 gnudatalanguage Dear udunits maintainer, unfortunately, the test log of gnudatalanguage is a bit confusing; these are the relevant lines from it: % Compiled module: TEST_CONSTANTS. % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % Execution halted at: TEST_CONSTANTS 36 /tmp/autopkgtest-lxc.tr9rpg1n/downtmp/build.2hE/src/testsuite/test_constants.pro % $MAIN$ This looks that udunits didn't find its unit database. Since from the log one can see that the libudunits2-data package was loaded, I would guess that there is some problem with the library. When looking into the failed CI test for gyoto, the message is a bit similar: In gyoto.C: Error initializing libgyoto: Converters.C:56 in void Gyoto::Units::Init(): error initializing arcsec unit Could you check that? Best regards Ole -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#978066: pmix transition
Hi Graham Can these bugs be closed ? pmix tests are failing because of an openmpi bug , but its no longer due to pmix. Ditto, ucx errors that caused the failure are fixed in openmpi-4.1.0-6. openmpi 4.1.0-6 fails on libfabric: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979041 I'm working on this now - but the ucx/pmix bugs block mpich which is unrelated. Regards Alastair
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
Ugh. Thanks Drew. What are the contents of /etc/openmpi/openmpi-mca-params.conf on the node? Does a simple hello world (see Debian/tests/hello* ) work without errors in the environment ? Regards Alastair On 15/01/2021, 08:39, "Drew Parsons" wrote: Package: libopenmpi3 Version: 4.1.0-5 Followup-For: Bug #979041 There's evidence this libfabric bug is not fully fixed. pytest-mpi (0.4-3) is failing tests: A process has executed an operation involving a call to the fork() system call to create a child process. As a result, the libfabric EFA provider is operating in a condition that could result in memory corruption or other system errors. For the libfabric EFA provider to work safely when fork() is called, you will need to set the following environment variable: RDMAV_FORK_SAFE However, setting this environment variable can result in signficant performance impact to your application due to increased cost of memory registration. You may want to check with your application vendor to see if an application-level alternative (of not using fork) exists. Your job will now abort. Fatal Python error: Aborted Current thread 0x7f2978647740 (most recent call first): File "/usr/lib/python3.9/subprocess.py", line 1756 in _execute_child File "/usr/lib/python3.9/subprocess.py", line 951 in __init__ File "/usr/lib/python3/dist-packages/_pytest/pytester.py", line 1193 in popen File "/usr/lib/python3/dist-packages/_pytest/pytester.py", line 1234 in run File "/tmp/autopkgtest.5dpwa6/build.XvQ/real-tree/tests/conftest.py", line 44 in runpytest_subprocess File "/tmp/autopkgtest.5dpwa6/build.XvQ/real-tree/tests/conftest.py", line 52 in runpytest File "/tmp/autopkgtest.5dpwa6/build.XvQ/real-tree/tests/test_markers.py", line 113 in test_mpi_xfail_under_mpi File "/usr/lib/python3/dist-packages/_pytest/python.py", line 180 in pytest_pyfunc_call pytest-mpi is also affected by the UCX bug and possibly a pytest6 problem, but I guess they would not trigger this libfabric RDMAV_FORK_SAFE error. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenmpi3 depends on: ii libc62.31-9 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-2 ii libgcc-s110.2.1-6 ii libhwloc-plugins 2.4.0+dfsg-3 ii libhwloc15 2.4.0+dfsg-3 ii libibverbs1 33.0-1 ii libnl-3-200 3.4.0-1+b1 ii libpmix2 4.0.0-3 ii libpsm-infinipath1 3.3+20.604758e7-6.1 ii libpsm2-211.2.185-1 ii libstdc++6 10.2.1-6 ii libucx0 1.10.0~rc1-2 ii zlib1g 1:1.2.11.dfsg-2 libopenmpi3 recommends no packages. libopenmpi3 suggests no packages. -- no debconf information
Bug#980033: libucx0: UCX ERROR rdma_create_event_channel failed: No such device
On 13/01/2021 09:16, Drew Parsons wrote: Package: libucx0 Version: 1.10.0~rc1-2 Severity: serious Justification: debci Our next round of whack-a-mole comes from the new UCX. pmix 4.0.0-3 seems to have fixed the pmix error from bug#979744. debci tests next report a problem with UCX, with openmpi 4.1.0-5 pmix 4.0.0-3 ucx 1.10.0~rc1-2 Thanks. This appears to be unwanted warnings from UCX that RDMA is not present. I'm looking at silencing this via openmpi conf params. Alastair The openmpi debci test at https://ci.debian.net/data/autopkgtest/testing/arm64/o/openmpi/9650495/log.gz reports: autopkgtest [15:16:16]: test hello4: [--- [1610522176.588740] [ci-013-36a60f22:1417 :0] rdmacm_cm.c:638 UCX ERROR rdma_create_event_channel failed: No such device [1610522176.588779] [ci-013-36a60f22:1417 :0] ucp_worker.c:1432 UCX ERROR failed to open CM on component rdmacm with status Input/output error [ci-013-36a60f22:01417] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker node 0 : Hello world autopkgtest [15:16:17]: test hello4: ---] autopkgtest [15:16:18]: test hello4: - - - - - - - - - - results - - - - - - - - - - hello4 FAIL stderr: [ci-013-36a60f22:01417] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker autopkgtest [15:16:18]: test hello4: - - - - - - - - - - stderr - - - - - - - - - - [ci-013-36a60f22:01417] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker autopkgtest [15:16:18]: summary hello1 FAIL stderr: [ci-013-36a60f22:01292] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker hello2 FAIL stderr: [ci-013-36a60f22:01218] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker hello4 FAIL stderr: [ci-013-36a60f22:01417] ../../../../../../ompi/mca/pml/ucx/pml_ucx.c:273 Error: Failed to create UCP worker Other client applications fail with the same error. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libucx0 depends on: ii ibverbs-providers 33.0-1 ii libbinutils2.35.1-7 ii libc6 2.31-9 ii libibverbs133.0-1 ii libnuma1 2.0.12-1+b1 ii librdmacm1 33.0-1 libucx0 recommends no packages. libucx0 suggests no packages. -- no debconf information -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#972420: adios not supporting python3.9
So,
The current head of tree currently fails correctly when it tries to
build against all pythons and fails.
Unfortunately cython3 doesn't appeat to generate code (in some cases)
that works with python 3.9 :
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG
-g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat
-Werror=format-security -g -fwrapv -O2 -g -O2
-fdebug-prefix-map=/srv/build/adios/adios-1.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -D_NOMPI
-I/usr/lib/python3/dist-packages/numpy/core/include -I../../src/public
-I/usr/include -I/usr/include -I/usr/include/hdf5/serial
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include
-I/usr/include -I/usr/include -I/sr/include -I/usr/include -I/sr/include
-I/usr/include -I/usr/include/python3.8 -c adios.cpp -o
build/temp.linux-x86_64-3.8/adios.o -Wno-uninitialized -Wno-unused-function
In file included from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1822,
from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarrayobject.h:12,
from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
from adios.cpp:540:
/usr/lib/python3/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
warning: #warning "Using deprecated NumPy API, disable it with "
"#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
17 | #warning "Using deprecated NumPy API, disable it with " \
| ^~~
adios.cpp:49053:3: error: cannot convert ‘PySequenceMethods*’ to
‘PyNumberMethods*’ in initialization
49053 | &__pyx_tp_as_sequence_softdict, /*tp_as_sequence*/
| ^~
| |
| PySequenceMethods*
adios.cpp:49398:3: error: cannot convert ‘PyObject* (*)(PyObject*)’ {aka
‘_object* (*)(_object*)’} to ‘PyAsyncMethods*’ in initialization
49398 | __pyx_pw_5adios_4file_19__repr__, /*tp_repr*/
| ^~~~
| |
| PyObject* (*)(PyObject*) {aka _object* (*)(_object*)}
regards
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Bug#971669: libopenmpi3: armel mipsel: mca_pmix_pmix3x.so: undefined symbol: OPAL_MCA_PMIX3X_PMIx_Get_version
On 13/10/2020 14:21, Drew Parsons wrote: Source: openmpi Version: 4.0.5-6 Followup-For: Bug #971669 mca_pmix_pmix3x.so and the undefined symbol are still showing in mumps builds with openmpi 4.0.5-6. I did a test build on abel and mca_pmix_ext3x.so (matching other archs) is built instead of *_pmix3x.so. Need to figure out whats different between the sid schroot on abel and the buildds. -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#965352: libopenmpi3: breaks tests in client programs
This is reported upstream (UCX) here: https://github.com/openucx/ucx/issues/5443 On 23/07/2020 06:33, Drew Parsons wrote: Package: libopenmpi3 Version: 4.0.4-2 Followup-For: Bug #965352 Control: affects -1 src:scalapack UCX seems to be affecting the scalapack build also: 87/96 Test #82: xdgsep ... Passed 109.38 sec Start 95: xshseqr 88/96 Test #83: xcgsep ... Passed 101.14 sec Start 96: xdhseqr 89/96 Test #96: xdhseqr ..***Failed 49.20 sec ScaLAPACK Test for PDHSEQR epsilon =1.1102230246251565E-016 threshold =30.000 Residual and Orthogonality Residual computed by: Residual = || T - Q^T*A*Q ||_F / ( ||A||_F * eps * sqrt(N) ) Orthogonality = MAX( || I - Q^T*Q ||_F, || I - Q*Q^T ||_F ) / (eps * N) Test passes if both residuals are less then threshold N NBPQ QR Time CHECK - --- -- [1595480623.088652] [monte:1320201:0] sock.c:344 UCX ERROR recv(fd=28) failed: Bad address [1595480623.199533] [monte:1320189:0] sock.c:344 UCX ERROR sendv(fd=30) failed: Connection reset by peer [monte:1320189] *** An error occurred in MPI_Bcast [monte:1320189] *** reported by process [1297350657,2] [monte:1320189] *** on communicator MPI COMMUNICATOR 5 SPLIT FROM 3 [monte:1320189] *** MPI_ERR_OTHER: known error not in list [monte:1320189] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [monte:1320189] ***and potentially your MPI job) -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#947437: flang in bullseye - llvm 11 ?
Hi, flang is now merged into LLVM base. I can build flang/f18 from the LLVM main install, but this targets llvm-11. Are we likely to have llvm-11 (not necessarily default) in Debian Bullseye ? what approach should be taken ? regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#947437: flang: Please update to llvm-9
On 15/03/2020 00:29, Sandro Tosi wrote: > > has there any progress been achieved in getting flang to build with > llvm-9? currently flang is the last reverse dependency of llvm-7, > which could be removed if flang is ported to llvm-9. Unfortunately no. Flang is undergoing a major overhaul as it is integrated properly into llvm, and the current branch and tree don't build against llvm-9, and likely to remain so for several months. I've been undoing its rdeps so there is little disruption when it is removed from unstable (and is FTBFS ). It would be good if llvm-7 was not removed from _unstable_ until flang gets fixed, though. > Regards, > Sandro -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#935455: test failures with dask, python3.8
reassign 935455 dask thanks This is a problem that occurs with dask and python3.8. python3.7 passes fine. It appears to be fixed upstream: https://github.com/dask/dask/pull/5852 Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#937525: Please remove pyro
Hi, As the 'pyro' maintainer, it should be removed from debian/unstable. Its only rdep is 'cylc', and the latest version of cylc (unstable) does not use pyro; pyro is already removed from testing. (cylc is awaiting a full new release that will be python3 clean, that version (due now) will not use pyro. pyro2 is python3- clean Regards Alastair McKinstry -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#947148: Is this test case correct ?
Checking this:
The test code test_mpi_ocl.c works fine for me ("success").
I see the result described for test_lt_dlopen.c, it returns:
0x559b5c923250 can't close resident module
However I agree with Jeff that this does not appear to be an error.
If lt_dlopen() returns a handle, it was successful, and the handle works
(verified, with a small foo.so that is a print statement).
The error state of dlerror() is set somewhere in the MPI stack "in the past"
and not set to NULL by a successful dlopen() in this code.
So I think the diagnosis is wrong, and cannot proceed further as test_mpi_ocl.c
succeeds for me.
Regards
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Bug#949134: oasis3: FTBFS (Assigning non-zero to $[ is no longer possible at ../../protex/protex line 87.)
Hi, I'm currently packaging the next major version of oasis3, and secondly my key has expired so I can't upload for a few weeks (Also I'm very busy untl Feb 8). I think it would be best to remove oasis3 from testing for the netcdf transition; it has no rdeps. Kind regards Alastair On 19/01/2020 09:11, Sebastiaan Couwenberg wrote: On 1/17/20 11:05 AM, Bas Couwenberg wrote: In preparation of the netcdf-fortran transition as test rebuild of your package was done which FTBFS: make doc make[4]: Entering directory '/build/oasis3-3.mct+dfsg.121022/lib/mct/doc/texsrc' perl ../../protex/protex -b m_Accumulator.F90 > m_Accumulator.tex Assigning non-zero to $[ is no longer possible at ../../protex/protex line 87. make[4]: *** [Makefile:27: m_Accumulator.tex] Error 255 It helps to update protex to a version that works with Perl 5.30 as per the attached patch, but the package still FTBFS further on, see the attached log. Kind Regards, Bas -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#885371: Updates to cylc
Hi, These bugs (dependence on python2, pygtk) are expected to be solved in the upcoming cylc-8 releases. Unfortunately cylc-8 is feature incomplete (current alpha is server-side only, the GUI work not released), and will depend on stuff thats not packaged yet. cylc_8.0a1-1 is in Experimental and I'm packaging upcoming expected dependencies. cylc-7.8.4 may be backported to buster. Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#936049: metview: missing libopenmpi-dev dependency?
odb-api includes mpi-default-dev, which defaults to libopenmpi-dev.
This may be failing if another mpi (mpich-dev) is installed instead. I
agree hard-coding including libopenmpi-dev is needed for the moment.
The CMake code in the ECMWF stack (eccodes, magics++, metview, ...) is
brittle, and leaks dependencies. Adding a dependency lower down the
chain (eg odb-api) breaks packages up the chain (metview) unless they
include all dev libraries, etc. which in turn is bad for transitions.
I've recently packaged the underlying build cmake code (ecbuild,
currently bundled into the ECMWF tarballs), and will start patching it
to fix this brittleness; if eg libodb-api.so is built with libssl.so,
libssl-dev should not be needed for metview to build.
Secondly, i'm refactoring some of the components. eckit, fckit, atlas
are available independently at github so I'm packaging them separately
from odb-api.
regards
Alastair
On 29/08/2019 13:35, Gianfranco Costamagna wrote:
Source: odb-api
Version: 0.18.1-6
Severity: serious
tags: patch
Hello, looks like for some reasons eckit in Ubuntu fails to see the include
directory for openmpi, because it simply doesn't exist
adding libopenmpi-dev dependency to odb-api should fix the issue, bringing the
directory back when cmake tries to find header files
/usr/lib/x86_64-linux-gnu/pkgconfig/odb.pc:ODB_CC=/usr/bin/cc -pthread
-I/usr/lib/x86_64-linux-gnu/openmpi/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -Wdate-time
-D_FORTIFY_SOURCE=2 -pipe -fopenmp -fPIC -I${prefix}/include
/usr/lib/x86_64-linux-gnu/cmake/odb/odb-import.cmake:set(ODB_ENVIRONMENT
"ODB_ROOT=/usr;ODB_SYSPATH=/usr/include;ODB_BINPATH=/usr/bin;ODB_BEBINPATH=/usr/bin;ODB_FEBINPATH=/usr/bin;ODB_LIBPATH=/usr/lib;ODB_RTABLE_PATH=/usr/share/odb;ODB_SYSDBPATH=/usr/share/odb;ODB_CC=/usr/bin/cc
-pthread -I/usr/lib/x86_64-linux-gnu/openmpi/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -Wdate-time -D_FORTIFY_SOURCE=2 -pipe
-fopenmp -fPIC -I/usr/include;ODB_F90=/usr/bin/gfortran -g -O2
-fdebug-prefix-map=/build/odb-api=. -fstack-protector-strong -fopenmp -fPIC
-ffree-line-length-none -I/usr/include -I/usr/module
-I/usr/odb/module;ODB_COMPILER=/usr/bin/odb98.x -V
-O3;ODB_COMPILER_FLAGS=/usr/share/odb/odb98.flags;ODB_STATIC_LINKING=1;ODB_LD_SHARED=none;ODB_LD_SHARED_SFX=.so;ODB_IOASSIGN_MAXPROC=32;ODB_IOASSIGN_PARAMS=-r
1m -w
1m;ODB_AR=/usr/bin/ar;ODB_GZIP=/bin/gzip;ODB_GUNZIP=/bin/gunzip;ODB_SETUP_SHELL=/bin/sh")
it looks like used and needed
snip of the failing log:
-- The following OPTIONAL packages have not been found:
* Git
* fckit (required version >= 0.6.2)
* transi (required version >= 0.4.4)
* CGAL
* gridtools_storage
-- ENABLE_EXPOSE_SUBPACKAGES is On:
-- All packages in the bundle will be installed at the same level into:
-- /usr
-- Configuring done
CMake Error in atlas/src/atlas/CMakeLists.txt:
Imported target "eckit_mpi" includes non-existent path
"/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
CMake Error in atlas/src/atlas/CMakeLists.txt:
Imported target "eckit_mpi" includes non-existent path
"/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
trivial patch here:
https://launchpad.net/ubuntu/+source/odb-api/0.18.1-6ubuntu1
Gianfranco
--
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie,
phone: 087-6847928
Green Party Councillor, Galway County Council
Bug#934159: metview: FTBFS after new magics++
Hi
Thanks, I've been working on this in parallel and discovered the same
fixes :/
I'm testing metview-5.6, will merge changes
regards
Alastair
On 07/08/2019 16:31, Gianfranco Costamagna wrote:
Source: metview
Version: 5.3.0-3
Severity: serious
tags: patch
Hello, magics++ changed interpretAsMatrix prototype, and now metview is FTBFS.
The new upstream release has already a fix, but I'm posting a minimal debdiff
here.
Also, new metview changed the METVIEW_EXTRA_INCLUDES variable, so also a change
in rules file is needed now.
diff -Nru metview-5.3.0/debian/changelog metview-5.3.0/debian/changelog
--- metview-5.3.0/debian/changelog 2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/changelog 2019-08-07 17:13:08.0 +0200
@@ -1,3 +1,10 @@
+metview (5.3.0-4) unstable; urgency=medium
+
+ * debian/rules: fixup includes directive for terralib
+ * Cherry-pick upstream build fix (Closes: #-1)
+
+ -- Gianfranco Costamagna Wed, 07 Aug 2019
17:13:08 +0200
+
metview (5.3.0-3) unstable; urgency=medium
* Standards-Version: 4.4.0
diff -Nru metview-5.3.0/debian/patches/fix-build-new-magics.patch
metview-5.3.0/debian/patches/fix-build-new-magics.patch
--- metview-5.3.0/debian/patches/fix-build-new-magics.patch 1970-01-01
01:00:00.0 +0100
+++ metview-5.3.0/debian/patches/fix-build-new-magics.patch 2019-08-07
17:13:07.0 +0200
@@ -0,0 +1,16 @@
+Description: Cherry-pick upstream fix for the metview build.
+
+Last-Update: 2019-08-07
+
+--- metview-5.3.0.orig/src/Reprojection/ReprojectService.cc
metview-5.3.0/src/Reprojection/ReprojectService.cc
+@@ -57,7 +57,8 @@ ReprojectService::execute()
+
+
+ magics::Matrix *matrix = 0;
+-gribInterpreter.interpretAsMatrix(grib, );
++gribInterpreter.interpretAsMatrix(grib);
++matrix = grib.u();
+ if (!matrix)
+ {
+ MagLog::dev() << "ERROR: interpretAsMatrix failed on file " << gribIn_ <<
"\n";
diff -Nru metview-5.3.0/debian/patches/series
metview-5.3.0/debian/patches/series
--- metview-5.3.0/debian/patches/series 2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/patches/series 2019-08-07 17:12:51.0 +0200
@@ -12,3 +12,4 @@
syserrlist.patch
qt5-transition.patch
g++14.patch
+fix-build-new-magics.patch
diff -Nru metview-5.3.0/debian/rules metview-5.3.0/debian/rules
--- metview-5.3.0/debian/rules 2019-07-18 16:30:29.0 +0200
+++ metview-5.3.0/debian/rules 2019-08-07 17:13:08.0 +0200
@@ -72,7 +72,7 @@
-DMETVIEW_SITE=debian \
-DCMAKE_BUILD_TYPE=Release \
-DMETVIEW_EXTRA_LIBRARIES='terralib -lemosR64 -leccodes
-leckit' \
- -DMETVIEW_EXTRA_INCLUDES='/usr/include/terralib/kernel' \
+ -DMETVIEW_EXTRA_INCLUDE_DIRS='/usr/include/terralib/kernel' \
-DMAGICS_HAVE_METVIEW=True \
--
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie,
phone: 087-6847928
Green Party Councillor, Galway County Council
Bug#927943: libxmlada: FTBFS with unicode-data >= 12.0.0
Source: libxmlada Version: 18-3 Severity: serious Justification: Policy 4.2 unicode-data 12.0.0 is now in unstable/testing (Buster). libxmlada FTBFS with this: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : file name too long: Egyptian_Hieroglyph_Format_Controls make[1]: *** [debian/rules:83: unicode/unicode-names-basic_latin.ads] Error 1 make[1]: Leaving directory '/tmp/libxmlada-18' regards Alastair McKinstry -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927944: node-unicode-data: FTBFS with unicode-data >= 12.0.0
Source: node-unicode-data Version: 0~20181101+gitaddfb440-1 Severity: serious Justification: Policy 4.2 node-unicode-data FTBFS with unicode-data 12.0.0 and needs to be updated. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#927942: gucharmap: FTBFS with unicode-data >= 12
Source: gucharmap
Version: 1:11.0.3-2
Severity: serious
Justification: Policy 4.2
unicode-data 12.0.0 is now in unstable/testing (Buster).
gucharmap FTBFS with this;
In file included from gucharmap-unicode-info.c:33:
unicode-versions.h:331:21: error: ‘GUCHARMAP_UNICODE_VERSION_12_0’ undeclared
here (not in a function); did you mean ‘GUCHARMAP_UNICODE_VERSION_11_0’?
331 | { 0x0C77, 0x0C77, GUCHARMAP_UNICODE_VERSION_12_0 },
| ^~
| GUCHARMAP_UNICODE_VERSION_11_0
unicode-versions.h:863:21: error: ‘GUCHARMAP_UNICODE_VERSION_12_1’ undeclared
here (not in a function); did you mean ‘GUCHARMAP_UNICODE_VERSION_2_1’?
863 | { 0x32FF, 0x32FF, GUCHARMAP_UNICODE_VERSION_12_1 },
| ^~
| GUCHARMAP_UNICODE_VERSION_2_1
regards
Alastair McKinstry
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to
en_IE.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#927941: utf8proc: FTBFS with unicode-data >= 12.0.0
Source: utf8proc Version: 2.2.0-1 Severity: serious Justification: Policy 4.2 unicode-data 12.0.0 is now in unstable/testing (Buster). utf8proc 2.2.0-1 FTBFS with this; it needs updating to 2.3.0. It is expected that unicoode-data will be updated to 12.1.* (probably 12.1.0~pre1-1) for Buster to include 'Reiwa' for Japanese era handling. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#924032: mpqc3: FTBFS: Could NOT find MPI
Hi, This is fixed with an upload to mpich this morning (GCC / MPICH version issue). It builds with the latest version regards Alastair On 18/03/2019 13:06, Andreas Tille wrote: Hi Drew, On Mon, Mar 18, 2019 at 07:09:22PM +0800, Drew Parsons wrote: The log snippet refers to mpich, but most arches use openmpi by default. So that's a clue. The full attached log says it's a simple x86_64. Why then is mpich installed? I think https://salsa.debian.org/debichem-team/mpqc3/blob/master/debian/control line 22+23 are answering the question. If I understand your question correctly you would rather suggest: diff --git a/debian/control b/debian/control index c47f755..8cdb361 100644 --- a/debian/control +++ b/debian/control @@ -19,8 +19,7 @@ Build-Depends: cmake (>= 2.8.11), libpsi3-dev, libtbb-dev, libtiledarray-dev, - libmpich-dev, - mpich, + mpi-default-dev, psi3 Standards-Version: 3.9.6 Homepage: http://www.mpqc.org I tried this but this ends up in: ... -- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS -- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS - Failed -- Found Libint2: -- <--->LIBINT2_LIBRARY=/usr/lib/libint2.so -- <--->LIBINT2_INCLUDE_DIR=/usr/include -- Performing Test PSI3_COMPILES -- Performing Test PSI3_COMPILES - Success -- Performing Test HAVE_PSIO_PURGE -- Performing Test HAVE_PSIO_PURGE - Failed -- Found PSI3: -- <--->PSI3_LIBRARIES=/usr/lib/libPSI_dpd.a;/usr/lib/libPSI_chkpt.a;/usr/lib/libPSI_iwl.a;/usr/lib/libPSI_qt.a;/usr/lib/libPSI_ciomr.a;/usr/lib/libPSI_psio.a -- <--->PSI3_INCLUDE_DIR=/usr/include -- Found TiledArray: -- <--->TiledArray_INCLUDE_DIR=/usr/include;/usr/include/TiledArray/external -- <--->TiledArray_LIBRARIES=tiledarray -- Performing Test TILEDARRAY_COMPILES CMake Error in /build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt: Imported target "tiledarray" includes non-existent path "/usr/include/x86_64-linux-gnu/mpich" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. CMake Error in /build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt: Imported target "tiledarray" includes non-existent path "/usr/include/x86_64-linux-gnu/mpich" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. ... Any further hint? Kind regards Andreas. -- Alastair McKinstry, , , @amckinstry:matrix.org Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#922869: libtool: file date issue
Hi, Where did you see this error ? I cannot repeat it. Builds work fine locally / pdebuild, and it appears the buildds ? regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#896189: update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc
clone 896644 -1 reassign -1 lam: lam alternatives break openmpi/mpich thanks Hi, This is due to lam not supporting the updated semantics for the mpi alternatives. The MPI alternatives in openmpi (default mpi) and mpich now honour multiarch, and the existing mpi alternatives in LAM need to be updated to do so. Alternatively, Lam could be removed (officially dead upstream since 2015 https://blogs.cisco.com/performance/a-farewell-to-lammpi) Regards Alastair On 12/02/2019 23:04, Ivo De Decker wrote: Control: reopen -1 Hi, On Fri, Apr 20, 2018 at 06:56:24PM +0300, Adrian Bunk wrote: [...] Setting up openmpi-bin (3.0.1-6) ... update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun (mpirun) in auto mode update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc dpkg: error processing package openmpi-bin (--configure): installed openmpi-bin package post-installation script subprocess returned error exit status 2 It seems this issue is back in builds for netpipe: https://buildd.debian.org/status/fetch.php?pkg=netpipe=amd64=3.7.2-7.4%2Bb5=1550010019=0 Setting up openmpi-bin (3.1.3-10) ... update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun (mpirun) in auto mode update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc dpkg: error processing package openmpi-bin (--configure): installed openmpi-bin package post-installation script subprocess returned error exit status 2 Ivo -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#919763: adios: armhf FTBFS when built on arm64
Hi Yes, thanka for this patch. I'm reluctant to consider that binaries built on armhf failing on arm64 is an _RC Bug_, but its definitely undesirable. I'll forward the patch to upstream, and let them optimize it better. regards Alastair On 25/01/2019 18:02, Steve Langasek wrote: Package: adios Followup-For: Bug #919763 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Hi Alastair, I'm reopening this bug report because I see that you have closed it by disabling the testsuite. This is a wrong fix for the issue given that the tests are correctly identifying CPU incompatibility in the code. This only results in willingly shipping binaries that will not work on more recent ARM CPUs (and even older CPUs, when using a kernel in a particular mode). If you as maintainer don't want to support adios across the range of CPUs that the Debian armhf port is expected to work on, then it would be better to remove the adios binaries for this architecture instead. (And btw, this issue would also affect sparc64 as an architecture, not only armhf, due to similar alignment constraints.) However, I've just prepared a patch that fixes the unaligned access problems in adios's code. Would you consider applying this as a solution instead? It could stand to be improved - in particular, for cases where we are byteswapping, the code currently writes the variable twice where this could be optimized to be a single write. But I presume the byteswap case is only of interest on big-endian architectures, so not of great concern on modern targets. Thanks for considering, -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#916890: libopenmpi3: I cannot upgrade the lastest version
Dear Vinícius, This was due to a bug in 3.1.3-5 that has since been fixed. The bug was in the postrm scripts, triggered when the package was upgraded, and hence seen in upgrade. As the bug is no longer present, I am marking this fixed; locally I recommend uninstalling and re-installing openmpi to clear. Sorry for this, and thanks for the report, Alastair McKinstry On 17/01/2019 15:28, Vinícius Couto wrote: Package: libopenmpi3 Version: 3.1.3-5 Severity: important Dear Maintainer, When i try to upgrade the files, show: Unpacking libopenmpi3:amd64 (3.1.3-9) over (3.1.3-5) ... rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file or directory rm: cannot remove 'End': No such file or directory rm: cannot remove 'automatically': No such file or directory rm: cannot remove 'added': No such file or directory rm: cannot remove 'section': No such file or directory dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess returned error exit status 1 dpkg: trying script from the new package instead ... dpkg: error processing archive /var/cache/apt/archives/libopenmpi3_3.1.3-9_amd64.deb (--unpack): there is no script in the new version of the package - giving up Unpacking openmpi-common (3.1.3-9) over (3.1.3-5) ... rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file or directory rm: cannot remove 'End': No such file or directory rm: cannot remove 'automatically': No such file or directory rm: cannot remove 'added': No such file or directory rm: cannot remove 'section': No such file or directory dpkg: warning: old openmpi-common package post-removal script subprocess returned error exit status 1 dpkg: trying script from the new package instead ... dpkg: error processing archive /var/cache/apt/archives/openmpi-common_3.1.3-9_all.deb (--unpack): there is no script in the new version of the package - giving up Errors were encountered while processing: /var/cache/apt/archives/libopenmpi3_3.1.3-9_amd64.deb /var/cache/apt/archives/openmpi-common_3.1.3-9_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) dpkg: dependency problems prevent configuration of libopenmpi-dev:amd64: libopenmpi-dev:amd64 depends on libopenmpi3 (= 3.1.3-9); however: Version of libopenmpi3:amd64 on system is 3.1.3-5. libopenmpi-dev:amd64 depends on openmpi-common (>= 3.1.3-9); however: Version of openmpi-common on system is 3.1.3-5. [...] Errors were encountered while processing: libopenmpi-dev:amd64 openmpi-bin libhdf5-openmpi-dev libcoarrays-openmpi-dev:amd64 libhdf5-mpi-dev Reggards, Vinicius Couto -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:$ Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenmpi3 depends on: ii libc6 2.28-5 ii libevent-2.1-6 2.1.8-stable-4 ii libevent-pthreads-2.1-6 2.1.8-stable-4 ii libfabric1 1.6.2-2 ii libgcc1 1:8.2.0-14 ii libgfortran5 8.2.0-14 ii libhwloc-plugins 1.11.12-1 ii libhwloc5 1.11.12-1 ii libibverbs1 21.0-1 ii libnl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libpmix2 3.1.0~rc4-1 ii libpsm-infinipath1 3.3+20.604758e7-6 ii libpsm2-2 11.2.68-4 ii libquadmath0 8.2.0-14 ii libstdc++6 8.2.0-14 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages libopenmpi3 recommends: iu openmpi-bin 3.1.3-9 libopenmpi3 suggests no packages. -- no debconf information Reggards, Vinicius Couto -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#915025: libopenmpi-dev: fails to upgrade from 'stretch': new libopenmpi-dev package pre-installation script subprocess returned error exit status 2
On 16/01/2019 14:01, Alastair McKinstry wrote:
On 16/01/2019 13:49, Andreas Beckmann wrote:
On 2019-01-16 13:58, Alastair McKinstry wrote:
Hi
Would you happen to know syntax for piuparts to enable an upgrade test
from stretch to a new (local) version?
the command line for the normal stretch2{buster,sid} test can be derived
from corresponding log file, you may have to adjust paths etc.
and then its just these three extra:
--bindmount /tmp/openmpi --testdebs-repo /tmp/openmpi
--distupgrade-to-testdebs
with some set of .debs and a Packages file in /tmp/openmpi (or anywhere
else)
I'm trying to debug and need to see whats failing in the preinst
script.
So I've a local 3.1.3-10 version with 'set -x' in the scripts, but
can't
seem to do a stretch-> this upgrade, without putting it in sid or
experimental.
I finally got curious and looked into this last night ... I've
completely overhauled your maintainer scripts and just pushed them to a
branch anbe/alternatives
I hope I understood what your intentions were for the preinst and
reimplemented them in a more readable way. I needed some time to
understand what type of corruption you meant until I found the broken
mpi alternative status file posted by (forgot his name). Because that
code was primarily triggering on "no alternative installed".
I haven't done extensive tests, but it passes the upgrade from
stretch :-)
Thanks, I'll review them.
Thanks, this looks good.
I'll upload with these changes.
Matching changes should probably be made for mpich, the other mpi
alternative.
(There is a third MPI alternative in Debian, lam, which also needs work,
but i've heard nothing from its maintainer,
and the upstream is dead).
PPPS: all that was missing was a single '|| true'
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Bug#915025: libopenmpi-dev: fails to upgrade from 'stretch': new libopenmpi-dev package pre-installation script subprocess returned error exit status 2
On 16/01/2019 13:49, Andreas Beckmann wrote:
On 2019-01-16 13:58, Alastair McKinstry wrote:
Hi
Would you happen to know syntax for piuparts to enable an upgrade test
from stretch to a new (local) version?
the command line for the normal stretch2{buster,sid} test can be derived
from corresponding log file, you may have to adjust paths etc.
and then its just these three extra:
--bindmount /tmp/openmpi --testdebs-repo /tmp/openmpi
--distupgrade-to-testdebs
with some set of .debs and a Packages file in /tmp/openmpi (or anywhere
else)
I'm trying to debug and need to see whats failing in the preinst script.
So I've a local 3.1.3-10 version with 'set -x' in the scripts, but can't
seem to do a stretch-> this upgrade, without putting it in sid or
experimental.
I finally got curious and looked into this last night ... I've
completely overhauled your maintainer scripts and just pushed them to a
branch anbe/alternatives
I hope I understood what your intentions were for the preinst and
reimplemented them in a more readable way. I needed some time to
understand what type of corruption you meant until I found the broken
mpi alternative status file posted by (forgot his name). Because that
code was primarily triggering on "no alternative installed".
I haven't done extensive tests, but it passes the upgrade from stretch :-)
Thanks, I'll review them.
Once we have reached a clean state (with 3.1.3-10 installed), there
should be no need to rerun the preinst cleanup operations for every
subsequent upgrade?
Unfortunately, experience is that we'll see people upgrading from random
old sid versions to the 3.1.3-10.
(Problems in the upgrade scripts before were reported for multiple sid
releases. Just because the code is gone from sid doesn't mean we won't
get reports :-( )
I'm expecting to leave the preinst cleanup operations in the buster
release version, then delete them.
As I just write this, I think you may want to run ldconfig (which
activates the corresponding trigger in glibc) after you add/remove
alternatives that involve shared libraries.
That should be happening automatically; the triggers will be added in
the #DEBHELPER# section, no ?
Andreas
PS: feel free to repost to the corresponding bug
PPS: That's a pretty easy alternatives cleanup and setup, compared the
the nvidia and glx alternatives (which involves diversions) and the mess
I had to recover from when I initially took over the
nvidia-graphics-drivers maintenance. And I did upgrade tests from every
single ancient nvidia-graphics-drivers version available from
snapshot.d.o ... that's how I got involved with piuparts :-)
PPPS: all that was missing was a single '|| true'
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Bug#918588: libtool: generated libtool script is broken, affecting build on AIX
On 07/01/2019 17:02, Vincent Lefevre wrote: Package: libtool Version: 2.4.6-6 Severity: serious There's a major quoting issue in a recent change of libtool. This makes the MPFR build fail on AIX: Hi, I've disabled patch 0010-libtool-mitigate-the-sed_quote_subst-slowdown.patch, which includes the 'func_quote' code in the diff, which should revert back to previous working behavior, but I've no AIX system to debug or test. Can you test with 2.4.6-7 , just uploaded ? regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#917626: Bug #917626 in cctools marked as pending
Control: tag -1 pending Hello, Bug #917626 in cctools reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/neurodebian-team/cctools/commit/9bb57a5b29dbc8909e2828c6bffd3704f1a43b89 * sysmacro.patch: Ensure major/minor macros present on i386. Closes: #917626 * Standards-Version: 4.3.0 (this message was generated automatically) -- Greetings https://bugs.debian.org/917626
Bug#917626: Bug #917626 in cctools marked as pending
Control: tag -1 pending Hello, Bug #917626 in cctools reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/neurodebian-team/cctools/commit/dd1d503a80e2476f9bece911122c1a1675725454 New upstream release, closes: #917626 (this message was generated automatically) -- Greetings https://bugs.debian.org/917626
Bug#917133: openmpi: weird rm -f errors on upgrade
close 917133 thanks On 23/12/2018 05:17, Christoph Anton Mitterer wrote: Source: openmpi Version: 3.1.3-6 Severity: critical Justification: causes serious data loss Thanks for your work, but this bug report is wrong. Hi. On upgrading from 3.1.3-5 I get these: Unpacking libopenmpi3:amd64 (3.1.3-6) over (3.1.3-5) ... rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file or directory rm: cannot remove 'End': No such file or directory rm: cannot remove 'automatically': No such file or directory rm: cannot remove 'added': No such file or directory rm: cannot remove 'section': No such file or directory dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess returned error exit status 1 dpkg: trying script from the new package instead ... dpkg: ... it looks like that went OK The bug here is #916565 (in 3.1.3-5), fixed in 3.1.3-6 Apparently this comes from: if test ! -d /usr/lib/$multiarch/fortran/$base ; then rm -f /usr/lib/$multiarch/fortran/$cmplr fi # End automatically added section This code is correct , and from -6. The buggy code was in -5, where the lack of a trailing newline led to a comment being added to the end of the "rm" statement. in the respective package's postrm, though I can't see any error in it. The bug led to postrm failing in 3.1.3-5. A fix in -6 still calls the buggy postrm script to remove the -5 package if installed, which fails, and then calls 'failed-upgrade' in postrm on 3.1.3-6 (See https://wiki.debian.org/MaintainerScripts). This succeeds and hence the "... it looks like that went OK". Marking this as critical and serious data loss,... as it seems to remove "End", "automatically" in some relative path(?)... (or does dpkg always cd to some fixed location?)... so there is at least a remote chance this could remove user files of these names. This bug is now removed from Debian. The upgrade output is ugly, but upgrade works. Only those who upgraded to -5 will see it. I'm not sure what the default directory that dpkg/apt runs from when executing the upgrades (the users current directory? ). It may hit some users who have a file named "automatically","added","section" or "End" , in their current directory while upgrading openmpi in sid this week, but i'm not sure what to do about it. regards Alastair Cheers, Chris -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#915112: glew: conflicting definitions in glext.h and glew.h cause pymol to FTBFS
Hi, Simple fix attached. Can NMU if needed Alastair On 30/11/2018 16:04, Andreas Beckmann wrote: Source: glew Version: 2.1.0-2 Severity: serious Control: affects -1 + src:pymol Hi, I just noticed that pymol stated to FTBFS, this seems to be caused by glew (which was updated recently, while libglvnd hasn't seen changes for some time): In file included from layer0/os_gl.h:60, from layer1/Ortho.h:28, from layer0/Err.cpp:22: /usr/include/GL/glext.h:12066:105: error: conflicting declaration 'typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, const GLfloat*)' typedef void (APIENTRYP PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum pname, const GLfloat *params); ^ In file included from layer0/os_gl.h:58, from layer1/Ortho.h:28, from layer0/Err.cpp:22: /usr/include/GL/glew.h:18734:28: note: previous declaration as 'typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, GLfloat*)' typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum pname, GLfloat* params); ^~~~ In file included from layer0/os_gl.h:60, from layer1/Ortho.h:28, from layer0/Err.cpp:22: /usr/include/GL/glext.h:12068:103: error: conflicting declaration 'typedef void (* PFNGLFRAGMENTLIGHTIVSGIXPROC)(GLenum, GLenum, const GLint*)' typedef void (APIENTRYP PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, const GLint *params); ^ In file included from layer0/os_gl.h:58, from layer1/Ortho.h:28, from layer0/Err.cpp:22: /usr/include/GL/glew.h:18736:28: note: previous declaration as 'typedef void (* PFNGLFRAGMENTLIGHTIVSGIXPROC)(GLenum, GLenum, GLint*)' typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, GLint* params); ^~~~ and so on... Full log attached. This happens with both pymol in sid and experimental. Andreas -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff Index: pymol-2.2.0+dfsg/layer0/os_gl.h === --- pymol-2.2.0+dfsg.orig/layer0/os_gl.h +++ pymol-2.2.0+dfsg/layer0/os_gl.h @@ -57,7 +57,6 @@ #include #include -#include #define GLDOUBLEMULTMATRIX glMultMatrixd #define GLDOUBLETRANSLATE glTranslated
Bug#913524: python-xarray: failing autopkgtest with cftime 1.0.2
This bug is due to cftime 1.0.2, which now causes : TypeError: Cannot cast datetime.timedelta object from metadata [Y] to [us] according to the rule 'same_kind' in one of the test cases when python3 is used (not python2). AFAICT, this does not affect the code, just the test, so for the moment I am marking the test XFAIL to allow the package to build while the code is fixed in cftime. Thanks Alastair On 11/11/2018 20:31, Jeremy Bicha wrote: Source: python-xarray Version: 0.10.9-1 Severity: serious Affects: cftime X-Debbugs-CC: mckins...@debian.org python-xarray began failing its autopkgtests on October 27. On that date, cftime 1.0.2 was uploaded and appears to be the likely trigger for these failures. I am filing this bug against python-xarray although it's possible the bug is in cftime instead. I am filing as serious. In Ubuntu, autopkgtest failures prevent packages from migrating out of their -proposed repository unless explicitly ignored. In Debian, autopkgtest failures can delay package migration to testing by about a month currently. The autopkgtest failure might indicate a major problem in your package but I don't know enough about the package to know that for sure. Please investigate. You can set the severity level that you feel is appropriate. Thanks, Jeremy Bicha -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#912437: openmpi-bin: Fails to upgrade: update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc
Thanks for this report. I'm unable to reproduce this, and have no failures testing 3.1.2-6 -> 3.1.3-1 upgrade. The change made in the openmpi-bin.postinst script was to enable "set -e" properly (avoiding a conditional in the script that relied on testing non-zero return code). I suspect that /var/lib/dpkg/alternatives/mpi was corrupt from a previous upgrade (quite likely; major changes happened in the 2->3 transition due to multiarch handling). So, I think: (1) the current package is actually technically ok. (2) Some more handling needs to be added to cope with 'inheriting' a corrupt mpi alternatives. regards Alastair On 31/10/2018 14:28, Axel Beckert wrote: Package: openmpi-bin Version: 3.1.3-1 Severity: serious openmpi-bin fails to upgrade from 3.1.2-6 to 3.1.3-1 as follows for me: Setting up openmpi-bin (3.1.3-1) ... update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc dpkg: error processing package openmpi-bin (--configure): installed openmpi-bin package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: openmpi-bin -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages openmpi-bin depends on: ii libc62.27-8 ii libevent-2.1-6 2.1.8-stable-4 ii libevent-pthreads-2.1-6 2.1.8-stable-4 ii libhwloc51.11.11-2 ii libopenmpi3 3.1.3-1 ii openmpi-common 3.1.3-1 ii openssh-client [ssh-client] 1:7.9p1-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openmpi-bin recommends: pn libopenmpi-dev Versions of packages openmpi-bin suggests: ii gfortran 4:8.2.0-2 -- no debconf information -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#910263: openmpi: segfault during lammps and liggghts autopkgtest
Control: tags -1 + forwarded This is now reported upstream: https://github.com/open-mpi/ompi/issues/5842 Regards Alastair On 05/10/2018 09:01, Graham Inggs wrote: Control: tags -1 + ftbfs Control: severity -1 serious Hi Maintainer The recent rebuild of liggghts on i386 failed [1]. However, it no longer times out, as was reported in #907267. Rebuilds on the reproducible builds infrastructure seemed to fail in a similar way on amd64 [2], i386 [2] and arm64 [3]. The arm64 rebuild of lammps [5] on the reproducible builds infrastructure also seemed similar. However, other architectures were successful. Regards Graham [1] https://buildd.debian.org/status/logs.php?pkg=liggghts=i386 [2] https://tests.reproducible-builds.org/debian/history/amd64/liggghts.html [3] https://tests.reproducible-builds.org/debian/history/i386/liggghts.html [4] https://tests.reproducible-builds.org/debian/history/arm64/liggghts.html [5] https://tests.reproducible-builds.org/debian/history/arm64/lammps.html -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#907267: openmpi: liggghts build on i386 times out
:-( On 30/08/2018 18:53, Graham Inggs wrote: Latest build of liggghts on i386 against openmpi 3.1.2-1 timed out. https://buildd.debian.org/status/fetch.php?pkg=liggghts=i386=3.7.0%2Brepack1-1.1=1535641058=0 -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#905418: openmpi: elpa builds hang on multiple architectures
Hi Graham Can you redo tests with openmpi 3.1.2 ? I think this new release fixes the hang issues, i've done some tests on armhf that went ok regards Alastair On 27/08/2018 20:48, Graham Inggs wrote: Hi Alastair Elpa seems to be another package with builds timing out. Confirmed on reproducible builders for i386 [1] and armhf [2]. Regards Graham [1] https://tests.reproducible-builds.org/debian/history/i386/elpa.html [2] https://tests.reproducible-builds.org/debian/history/armhf/elpa.html -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#904779: reassign: depends
retitle 904626 libtool issue leads to intermittent FTBFS failures reassign 904626 openmpi,libtool tags 904626 upstream merge 904626 896861 thanks This is an intermittent build issue that is being worked on with upstream: https://github.com/open-mpi/ompi/issues/5114 The openmpi build runs libtoolize and generates a libtool (see github bug for details of what went wrong). libtool.m4 differs then between upstream and the debian generated version. libtool.m4. Both are 2.4.6 but differ: diff /usr/share/aclocal/libtool.m4 config/libtool.m4 4950,4952d4938 < linux* | k*bsd*-gnu | gnu*) < _LT_TAGVAR(link_all_deplibs, $1)=no < ;; 5015,5017d5000 < linux* | k*bsd*-gnu | gnu*) < _LT_TAGVAR(link_all_deplibs, $1)=no < ;; 5272c5255 < netbsd* | netbsdelf*-gnu) --- > netbsd*) 5793d5775 < _LT_TAGVAR(link_all_deplibs, $1)=no The significance (if any) of this I don't yet understand. regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
For the transport, try: $ mpirun.openmpi -n 2 --mca btl self,tcp ./printf yay! this worked. My bare bones test code with that runs flawlessly: gmulas@capitanata:~/PAHmodels/anharmonica-scalapack$ mpiexec.openmpi ---mca btl self,tcp sample_printf MPI_Init call ok My rank is = 0 number of procs is = 2 MPI_Init call ok My rank is = 1 number of procs is = 2 MPI_Finalize call ok, returned 0 MPI_Finalize call ok, returned 0 The same code, run without the --mca option, yields: gmulas@capitanata:~/PAHmodels/anharmonica-scalapack$ mpiexec.openmpi -n 2 sample_printf -- [[23445,1],1]: A high-performance Open MPI point-to-point messaging module was unable to find any relevant network interfaces: Module: OpenFabrics (openib) Host: capitanata Another transport will be used instead, although this may result in lower performance. NOTE: You can disable this warning by setting the MCA parameter btl_base_warn_component_unused to 0. -- Of course it's a workaround, not a real solution, but way better than nothing :) Hi, Ok, time to dig deeper into btl issues. Can you send me the output of: $ mpirun -n 2 -mca mpi_show_mca_params all ./sample_printf thanks Alastair thanks! Giacomo -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
(0x7f94cc126000) libopen-rte.so.40 => /usr/lib/x86_64-linux-gnu/libopen-rte.so.40 (0x7f94cc06f000) libopen-pal.so.40 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.40 (0x7f94cbfc2000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f94cbfb6000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f94cbe22000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f94cbe1d000) libhwloc.so.5 => /usr/lib/x86_64-linux-gnu/libhwloc.so.5 (0x7f94cbddc000) libevent-2.1.so.6 => /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 (0x7f94cbb86000) libevent_pthreads-2.1.so.6 => /usr/lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.6 (0x7f94cb983000) /lib64/ld-linux-x86-64.so.2 (0x7f94cc4a8000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x7f94cb776000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x7f94cb56c000) Please let me know whatever I can do to help pinpoint this. I need to be able to use my computer to develop my MPI codes, and I cannot understand at all why it abruptly stopped working. Also, if you tell me it does work properly on another current sid system, I'd like to find out what makes the difference. Thanks in advance Giacomo Mulas -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
I cannot reproduce this problem. Can we debug it further ?
(1) How did you execute it ? mpiexec command line , etc?
(2) Can you give the output of :
$ dpkg -l | grep pmix
$ dpkg -l | grep psm
Any changes to /etc/openmpi/* files or environmental variables
Best regards
Alastair
On 27/07/2018 23:53, Giacomo Mulas wrote:
Package: openmpi-bin
Version: 3.1.1.real-4+b1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
since the latest wave of package updates (gnu compilers big version switch +
new openmpi package) even the simplest code, compiled by mpicc.openmpi (or
mpif90.openmpi) hangs forever on first initialisation of MPI. Even the
following "hello world" does it on my machine:
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv){
int nprocs=0, myrank=0, ierr=0;
ierr = MPI_Init( , );
ierr = MPI_Comm_rank(MPI_COMM_WORLD, );
ierr = MPI_Comm_size(MPI_COMM_WORLD, );
printf("MPI_Init call ok\n");
printf("My rank is = %d\n", myrank);
printf("number of procs is = %d\n", nprocs);
printf("\n");
ierr = MPI_Finalize();
printf("MPI_Finalize call ok, returned %d\n", ierr);
return 0;
}
Of course, this makes the package completely unusable for me. I don't know
whether this can be related to bug #584699: in fact my laptop is not really
multihomed. Please let me know if there is something I can do to help
pinpoint this. By the way, the above snippet of code works perfectly if
compiled and run under mpich.
Best regards
Giacomo Mulas
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.8-jak (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to it_IT.utf8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to
it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openmpi-bin depends on:
ii libc62.27-5
ii libevent-2.1-6 2.1.8-stable-4
ii libevent-pthreads-2.1-6 2.1.8-stable-4
ii libhwloc51.11.10-3
ii libopenmpi3 3.1.1.real-4+b1
ii openmpi-common 3.1.1.real-4+b1
ii openssh-client [ssh-client] 1:7.7p1-3
openmpi-bin recommends no packages.
Versions of packages openmpi-bin suggests:
ii gfortran 4:8.1.0-1
-- no debconf information
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Bug#903561: pmix 3.0.0 makes openmpi (and subsequent dependencies) unusable
Package: pmix Version: 3.0.0-1 Severity: grave Justification: renders package unusable pmix 3.0.0 is (or appears to be) incompatible with openmpi 3.1.1. This bug is to block its passage to testing (2.1.2rc1 works ok). The upcoming point release of openmpi (3.1.2) contains an internal release of pmix 2.1.2; when it is released, openmpi will be built with this internal pmix until openmpi compatability with pmix 3.0.0 is included. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#903492: Runtime error "PMIX-XFER-VALUE: UNSUPPORTED TYPE 28016"
This may also be due to recent uploads of a new PMIX (OpenMPI now uses an external pmix library). This linkage seems fragile and I need to come up with package tests in pmix / openmpi to test it. regards Alastair On 10/07/2018 18:57, Anton Gladky wrote: Source: openmpi Version: 3.1.1.real-1 Severity: serious Dear maintainer, it looks like the version 3.1.1.real-1 introduces the regression in autopkgtest. We are preparing some set of autopkgtests for the boost libraries (not in the package yet) [1]. And the MPI-autopkgtests are failing, when they are built against 3.1.1.real-1 [2]: === build: OK [runner-103358cc-project-28133-concurrent-0:04241] PMIX-XFER-VALUE: UNSUPPORTED TYPE 28016 [runner-103358cc-project-28133-concurrent-0:04241] PMIX ERROR: ERROR in file ../../../src/server/pmix_server.c at line 332 ERROR: Job failed: exit code 1 === The compiled code is here [3] and the run-command is the following: mpirun --oversubscribe --allow-run-as-root -np 8 ./demo1 It compiles just fine in the Debian Buster against the version 3.1.0-7 [4]. [1] https://salsa.debian.org/gladk/boost/pipelines [2] https://salsa.debian.org/gladk/boost/-/jobs/30504 [3] https://salsa.debian.org/gladk/boost/blob/master/debian/tests/srcs/graph-parallel/demo1.cpp [4] https://salsa.debian.org/gladk/boost/-/jobs/30510 Thanks, Anton -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#897417: Any chance of fixing its compatibility with openjdk-10?
On 03/05/2018 09:52, Boyuan Yang wrote: > On Wed, 02 May 2018 16:27:22 +0000 Alastair McKinstry <mckins...@debian.org> > wrote: >> Source: openmpi >> Source-Version: 3.0.1.real-2 >> Changes: >> openmpi (3.0.1.real-2) unstable; urgency=medium >> . >>* Builds against openjdk-9 as openjdk-19 (now default) doesn't ship >> javah, which we need for java bindings. Closes: > Hi Alastair, > > Thank you for the quick fix; however, I'm wondering if you could forward this > issue to upstream to deal with the disapperance of javah. > > According to https://openjdk.java.net/jeps/313 , javah was deprecated in > OpenJDK 9 and removed in OpenJDK 10. I'm wondering if you could forward this > information to upstream to have the problem solved so that we don't have to > depend on the non-default Java version. > > -- > Best Regards, > Boyuan Yang Hi Boyuan Yes, thats my plan. Its just that I needed to get some fixes into openmpi quickly to complete the openmpi3 transition. regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#896861: openmpi: frequent FTBFS linking libmpi_usempi_ignore_tkr.la
On 25/04/2018 10:04, Adrian Bunk wrote: > On Wed, Apr 25, 2018 at 09:55:08AM +0100, Alastair McKinstry wrote: >> This build-failure was fixed with the 3.0.1-5 release (incorrect >> selections in the Makefile filter syntax). > To me it looks like the same failure in -4, -5 and -8. > > On 3 different architectures. > Ok, this does look like a different bug. >> The current build failure on i386 looks different - nothing relevant has >> changed since -5 (in openmpi; perhaps gcc changes? ) > The whole pattern looks like a race condition somewhere that randomly > causes this FTBFS. > > Just look at > https://buildd.debian.org/status/logs.php?pkg=openmpi=arm64 > > -5 did FTBFS, but just an hour later the same sources built on > the same architecture. Agreed, looks like a race condition (on slower architectures ? ) I will enable the verbose debugging (#896861). Perhaps --no-parallel would be a good idea, but I will avoid inserting that in the next upload until we understand the failure. >> regards >> >> Alastair > cu > Adrian > -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#896861: openmpi: frequent FTBFS linking libmpi_usempi_ignore_tkr.la
This build-failure was fixed with the 3.0.1-5 release (incorrect selections in the Makefile filter syntax). The current build failure on i386 looks different - nothing relevant has changed since -5 (in openmpi; perhaps gcc changes? ) regards Alastair On 25/04/2018 07:02, Adrian Bunk wrote: > Source: openmpi > Version: 3.0.1-4 > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=openmpi=i386=3.0.1-8=1524561636=0 > https://buildd.debian.org/status/fetch.php?pkg=openmpi=arm64=3.0.1-4=1523694740=0 > https://buildd.debian.org/status/fetch.php?pkg=openmpi=ppc64el=3.0.1-5=1523910115=0 > > ... > make[3]: Entering directory > '/<>/ompi/mpi/fortran/use-mpi-ignore-tkr' > FCLD libmpi_usempi_ignore_tkr.la > /usr/bin/i686-linux-gnu-ld: cannot find -l-L/usr/lib/gcc/i686-linux-gnu/7 > collect2: error: ld returned 1 exit status > Makefile:1866: recipe for target 'libmpi_usempi_ignore_tkr.la' failed > make[3]: *** [libmpi_usempi_ignore_tkr.la] Error 1 -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#889210: stretch update for libdap
On 26/02/2018 21:00, Adrian Bunk wrote: > On Sat, Feb 03, 2018 at 01:51:18PM +, Debian Bug Tracking System wrote: >> ... >> libdap (3.19.1-2) unstable; urgency=medium >> ... >>* Add libdap-doc.docs to install docs. Closes: #889210 >> ... > Thanks a lot for fixing this bug for unstable. > > It is still present in stretch, could you also fix it there? > Alternatively, I can fix it for stretch if you don't object. Please do so, thanks > Thanks > Adrian > -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
On 23/11/2017 16:05, Andreas Beckmann wrote:
> On 2017-11-23 16:28, Alastair McKinstry wrote:
>> There are three _implementations_ of the Process Management Interface
>> (PMI): the Slurm one, the OpenMPI ("PMix") and the MPICH one. They are
>> all expected to have the same ABI.
>> Unlike jpeg, the three implementations will converge on the SOVERSION(s)
>> as they are in the agreed ABI.
>> Hence we will have differing behaviours with libraries with the same name.
> Which is *not* the case now, as they have different SOVERSIONs currently
> (slurm:0, pmix:1, mpich:?nosharedlib?), so you shouldn't use
> alternatives to mix them *now*.
alternatives need not be implemented now (and so won't be, to mimimize
code to debug), but file layout would be done
to make alternatives trivial.
That is, the prefix for pmix pmi libs and includes will be
/usr/lib/${multiarch}/pmi/{include, lib}
with a symlink for the library
/usr/lib/${multiarch}/libpmi.so.2.1.3 ->
/usr/lib/${multiarch}/pmi/lib/libpmi.so.2.1.3
>> Currently we have three possible 'users' of PMI: SLURM and the two MPI
>> implementations, OpenMPI and MPICH.
>> Each can be configured to use either its 'own' PMI or another; the
>> libraries do the same thing but can have
>> different implementation behaviours, (eg. MPICH calls its version
>> 'simple' while PMIX from OpenMPI aims to scale well at ~10^6 processes).
>>
>> Its a realistic use case then to ship a simple PMI as default, but also
>> allow another high-performance version to be available via alternatives,
>> switchable at runtime.
> In that case you would still only need one -dev package, that can be
> used with the different implementations. Or does each one have different
> "extensions" beyond the common API subset?
We currently ship a static libpmi.a in the -dev package; this would be
different in each implementation, so a different
-dev is still needed.
> BTW, how do you plan to do library alternatives in multiarch? Keep them
> in sync? How? or Why not?
See for example blas and lapack, which are in the same situation. The
alternatives file in /etc/alternatives has the multiarch extension
attached, eg.; liblapack.a-x86_64-linux-gnu
> Andreas
Alastair
--
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
On 23/11/2017 13:33, Andreas Beckmann wrote:
> Luckily we have a limited number of users:
>
> libpmix2
> Reverse Depends:
> libpmix-dev
> libopenmpi3
> libpmi2-0
> Reverse Depends:
> libpmi2-0-dev
>
> There are no users (B-D) for libpmi2-0-dev
>
> So slurm itself isn't even using the library it provides, therefore
> maybe it would be the easiest to just drop it from the slurm packaging?
>
> And we can continue discussion once a potential user for the old version
> from slurm comes up ...
There are three _implementations_ of the Process Management Interface
(PMI): the Slurm one, the OpenMPI ("PMix") and the MPICH one. They are
all expected to have the same ABI.
> On 2017-11-23 09:22, Gennaro Oliva wrote:
>> On Wed, Nov 22, 2017 at 10:20:17AM +, Alastair McKinstry wrote:
>>> Yes, this would be my preferred solution. Shipping:
>>> libpmi-pmix-dev
>>> libpmi-slurm-dev
> Is slurm shipping a "modified" version compared to the "official"
> release? In that case this naming would make sense. Otherwise
> distinguish them by an API version (or SOVERSION).
>
>>> and then providing alternatives.
>> great! Shouldn't we provide alternatives for the library package too?
> Please stop this insanity now!
>
> *** No alternatives for shared libraries. ***
> *** No alternatives for .so links. ***
>
> I think the best case comparable to yours is libjpeg.so
> In sid we have three packages shipping this file, but only one can be
> installed at a time.
> But libjpeg62-turbo and libjpeg9 can be installed at the same time.
>
Unlike jpeg, the three implementations will converge on the SOVERSION(s)
as they are in the agreed ABI.
Hence we will have differing behaviours with libraries with the same name.
Currently we have three possible 'users' of PMI: SLURM and the two MPI
implementations, OpenMPI and MPICH.
Each can be configured to use either its 'own' PMI or another; the
libraries do the same thing but can have
different implementation behaviours, (eg. MPICH calls its version
'simple' while PMIX from OpenMPI aims to scale well at ~10^6 processes).
Its a realistic use case then to ship a simple PMI as default, but also
allow another high-performance version to be available via alternatives,
switchable at runtime.
>
> In no way libpmi2.so.0 can be used as a replacement for libpmi2.so.1
> (and vice versa), otherwise there shouldn't have been a SOVERSION bump.
>
> It's nice to have consistent naming ...
>
> The command from the policy [8.1] suggests these package names:
> libpmi2-0, libpmi2-1
I'd agree with those names, if we weren't expecting alternatives.
> [8.1] https://www.debian.org/doc/debian-policy/#run-time-shared-libraries
>
> The -dev packages providing the same .so link need to conflict with each
> other. And at most one of them may use the "generic" name "libpmi2-dev"
> (or Provides: libpmi2-dev).
>
>
> Andreas
>
> PS: I have no clue at all what these libraries are about ...
Best regards
Alastair
--
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
On 22/11/2017 09:32, Gennaro Oliva wrote: > Hi Alastair, > > On Wed, Nov 22, 2017 at 08:36:00AM +, Alastair McKinstry wrote: >> I was unfortunately not aware of pmi2 from slurm when packaging pmix2 >> from openmpi. > thanks for packaging pmix. > >> Possible solutions include: >> (1) pmix splitting its conflictng files into another package >> libpmix-pmi-dev ? (name?) >> (2) Shipping only one pmi-dev package ? > what about using alternatives? By doing so, every resource manager and > mpi library can install it's own implementation. > Best regards Yes, this would be my preferred solution. Shipping: libpmi-pmix-dev libpmi-slurm-dev and then providing alternatives. regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
Please see the upstream discussion at: https://github.com/open-mpi/ompi/issues/4072 I was unfortunately not aware of pmi2 from slurm when packaging pmix2 from openmpi. Possible solutions include: (1) pmix splitting its conflictng files into another package libpmix-pmi-dev ? (name?) (2) Shipping only one pmi-dev package ? regards Alastair On 17/11/2017 19:22, Andreas Beckmann wrote: > Package: libpmi2-0-dev,libpmix-dev > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite > Control: found -1 2.1.0~rc1-1 > Control: found -1 17.02.9-1 > > Hi, > > automatic installation tests of packages that share a file and at the > same time do not conflict by their package dependency relationships has > detected the following problem: > > Selecting previously unselected package libpmix-dev:amd64. > Preparing to unpack .../12-libpmix-dev_2.1.0~rc1-1_amd64.deb ... > Unpacking libpmix-dev:amd64 (2.1.0~rc1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-Y3Z8bF/12-libpmix-dev_2.1.0~rc1-1_amd64.deb (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libpmi2.so', which is also > in package libpmi2-0-dev 17.02.9-1 > Errors were encountered while processing: >/tmp/apt-dpkg-install-Y3Z8bF/12-libpmix-dev_2.1.0~rc1-1_amd64.deb > > This is a serious bug as it makes installation fail, and violates > sections 7.6.1 and 10.1 of the policy. An optimal solution would > consist in only one of the packages installing that file, and renaming > or removing the file in the other package. Depending on the > circumstances you might also consider Replace relations or file > diversions. If the conflicting situation cannot be resolved then, as a > last resort, the two packages have to declare a mutual > Conflict. Please take into account that Replaces, Conflicts and > diversions should only be used when packages provide different > implementations for the same functionality. > > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > usr/lib/x86_64-linux-gnu/libpmi2.so > > This bug is assigned to both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may > also register in the BTS that the other package is affected by the bug. > > Cheers, > > Andreas > > PS: for more information about the detection of file overwrite errors > of this kind see https://qa.debian.org/dose/file-overwrites.html -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Bug#881967: libopenmpi3: ships libpmix.so.* which has a different SOVERSION than all other libs
Thanks for this report. With openmpi3, I intend to use the external package pmix (which will then be used by both openmpi and mpich). pmix was accepted into unstable yesterday, and I am doing test builds of openmpi3 against it. I need to fix arch regressions on both pmix and openmpi3 in experimental before it is fit to proceed to a transition. best regards Alastair On 16/11/2017 23:37, Andreas Beckmann wrote: > Package: libopenmpi3 > Version: 3.0.0-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation.
Bug#868071: ggcov FTBFS
Notes on this: The file format for gcno / gcna files has changed in gcc 7.1. I've opened an issue on this in ggcov upstream: https://github.com/ggcov/ggcov/issues/1 -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#859421: python-tz orphaning
Hi, Looking closer I realize you didn't mean _you_ were orphaning python-tz, but looking for others to do so. I see its technically managed by the Zope team (but in practice not). Looking at #858133 I see you've been working on it. I don't want to step on your toes, are you uploading / looking to be maintainer? Best regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#859421: Volunteer as maintainer
Ok, I volunteer to take over as maintainer (and move python-tz into team ownership in python team). Best regards Alastair McKinstry -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#850229: openmpi-bin: default for oversubscription changed
On 09/02/2017 09:51, Santiago Vila wrote: > On Thu, Feb 09, 2017 at 09:28:45AM +0100, Ansgar Burchardt wrote: >> On Thu, 2017-02-09 at 00:05 +0100, Santiago Vila wrote: >>> In either case I'm setting this to serious again because it makes >>> packages to fail on single-CPU systems, and having more than one CPU >>> is >>> definitely *not* part of the build-essential definition. >> > for example, so it is something definitely useful, not comparable > with building in a path which includes spaces. > > (For the record, I am paying for some of my autobuilders directly from my > pocket) > > Thanks. Respectfully disagree here. I appreciate that you're paying for autobuilders. While multi-cores is not a requirement for build-essential (though dh, etc now default to parallel builds), running MPI on a single core is definitely an exception, and oversubscribing is typically a user bug. We have had users waste thousands of euro in compute attempting to run 10,000 core jobs on 1000 cores by mistake, and they are the target audience for this change in default behaviour. For our particular case (building and testing on 1 core in Debian) I recommend just setting export OMPI_MCA_rmaps_base_oversubscribe=1 Regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - Terry. Pratchett, Snuff
Bug#850559: openmpi-bin: default for oversubscription changed
Hi, Debian stretch is now frozen. The next version of openmpi 2.0.2 (released last week!) contains an SOVERSION transition, and hasn't a hope of making stretch, IMO. While I can file an upstream bug to get the default changed, it would happen at best in the next release, June-July timeframe. This gives realistically two options: (1) Cherry pick a fix / patch to undo the change to openmpi to revert the behavior. Have the same program fail to work across different platforms due to our local version of openmpi. (2) Add the '--oversubscribe' flag / set -np correctly on the test cases of the packages affected. Personally I favour (2). (In the interests of disclosure, I will have to do an upload of a new version of openmpi anyway for stretch, to fix #848574. This will be a copy of 2.0.2 backing out the API change that necessitated the SOVERSION change, but only that). Best regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#848574: Fwd: Re: [open-mpi/ompi] Failure on mips64el (#2922)
This hints at a linker issue on stretch
Forwarded Message
Subject:Re: [open-mpi/ompi] Failure on mips64el (#2922)
Date: Sun, 05 Feb 2017 09:18:36 -0800
From: Paul H. Hargrove <notificati...@github.com>
Reply-To: open-mpi/ompi
<reply+000df6ae2813a40fb4299d91cfa44a62cfe446305bee9acb92cf000114af206c92a169ce0c3b0...@reply.github.com>
To: open-mpi/ompi <o...@noreply.github.com>
CC: Alastair McKinstry <alastair.mckins...@sceal.ie>, Author
<aut...@noreply.github.com>
@ggouaillardet <https://github.com/ggouaillardet>
Yes, I have both mips64 and mips64el and test thee ABIs
(|-mabi={32,n32,64}|) on each.
All 6 passed my testing of 2.0.2rc4, which included running the ring
examples (|ring_{c,mpih,usempi,usempif08}|) with two ranks on 1 node.
My tests are on Octeon II systems running Debian Wheezy, and are not
mine to upgrade.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/open-mpi/ompi/issues/2922#issuecomment-277533817>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA32rhNdErcRgpC2EaiaqjamKYwiI-_Xks5rZgRsgaJpZM4L2fjI>.
Bug#790352: New maintainer
Hi, As pyro is a dependency of a package I maintain (cylc), I will step in as maintainer. I request that pyro(3) _not_ be removed from stretch, as we are now passing the Jan. 5 freeze; were I to upload a new pyro4, it would not make stretch in time for the freeze, and especially not with testing its dependency(ies). For buster, I will package pyro4 and remove pyro3. Best regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#848732: g2clib: FTBFS: gcc: error: g2_unpack3.o: No such file or directory
Hi, Can you re-run this rebuild in your environment ? g2clib has built in all autobuilders (the day before), and I've retested locally both by hand, with pbuilder and sbuild, and its worked successfully. The log has no hint as to what failed; the .o files appeared to build, and then disappear - disk space? best regards Alastair On 19/12/2016 21:09, Lucas Nussbaum wrote: > Source: g2clib > Version: 1.6.0-5 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20161219 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): >> gcc -Wl,-z,relro -Wl,-as-needed -shared -o libgrib2c.so.0d >> -Wl,-soname,libgrib2c.so.0d gridtemplates.o drstemplates.o pdstemplates.o >> gbits.o g2_unpack1.o g2_unpack2.o g2_unpack3.o g2_unpack4.o g2_unpack5.o >> g2_unpack6.o g2_unpack7.o g2_free.o g2_info.o g2_getfld.o simunpack.o >> comunpack.o pack_gp.o reduce.o specpack.o specunpack.o rdieee.o mkieee.o >> int_power.o simpack.o compack.o cmplxpack.o misspack.o jpcpack.o jpcunpack.o >> pngpack.o pngunpack.o dec_jpeg2000.o enc_jpeg2000.o jpeg2000_openjpeg.o >> dec_png.o enc_png.o g2_create.o g2_addlocal.o g2_addgrid.o g2_addfield.o >> g2_gribend.o getdim.o g2_miss.o getpoly.o seekgb.o `pkg-config --libs >> libpng` -lopenjp2 -lm >> gcc: error: g2_unpack3.o: No such file or directory >> gcc: error: g2_unpack6.o: No such file or directory >> gcc: error: g2_info.o: No such file or directory >> gcc: error: g2_getfld.o: No such file or directory >> gcc: error: pack_gp.o: No such file or directory >> gcc: error: reduce.o: No such file or directory >> gcc: error: specpack.o: No such file or directory >> gcc: error: g2_addlocal.o: No such file or directory >> gcc: error: getdim.o: No such file or directory >> gcc: error: seekgb.o: No such file or directory >> makefile:159: recipe for target 'libgrib2c.so.0d' failed >> make[1]: *** [libgrib2c.so.0d] Error 1 > The full build log is available from: >http://aws-logs.debian.net/2016/12/19/g2clib_1.6.0-5_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#847806: openmpi 2.0.2
> I actually meant the 2.0.2~gitsomething in experimental, but that > question was already answered by an upload to unstable around the time I > wrote that mail. > > I was primarily asking, if I was to look into improving that > "conditional install stuff" - should I do it in experimental or sid > (which is now the same version). > > > Andreas > I say leave until post-stretch release. I'm fixing the multiarch now (which fixes #833728, #842881; tagged as mpich and ldconfig bugs but in practice due to mpich being multiarch and openmpi not). Getting this in place by the freeze on Jan 5 is the limits of my mpi ambitions at the moment :-) regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#847806: openmpi 2.0.2
> What are the plans regarding 2.0.2? Do you expect that version to reach > stretch in time? Or will it be be delayed to stretch+1? 2.0.2 unfortunately has a SOVERSION change in two libraries, which means it missed the transition for stretch (which is why I used a git snapshot of 2.0.1+, which has some important fixes but not the ones in question, I believe, that break the fortran ABI/API). best regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Bug#847966: python-cylc: ails to upgrade from 'jessie' - trying to overwrite /usr/lib/python2.7/dist-packages/xdot.py
Hi Andreas, AIUI, I need to just add a Breaks: xdot (<< 0.7-2) for python-cylc. This is because I want to force xdot to be upgraded first in the jessie->stretch upgrade, and I'm not replacing files in xdot (so, not adding Replaces:) Is this correct ? How do I do a piuparts upgrade to test this? best regards Alastair On 12/12/2016 16:54, Andreas Beckmann wrote: > Package: python-cylc > Version: 6.11.2-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'jessie', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > > >From the attached log (scroll to the bottom...): > > Selecting previously unselected package python-cylc. > Preparing to unpack .../python-cylc_6.11.2-1_amd64.deb ... > Unpacking python-cylc (6.11.2-1) ... > dpkg: error processing archive > /var/cache/apt/archives/python-cylc_6.11.2-1_amd64.deb (--unpack): >trying to overwrite '/usr/lib/python2.7/dist-packages/xdot.py', which is > also in package xdot 0.6-2 > > > Interestingly there is no conflict with xdot 0.7-2 in stretch/sid. > > > cheers, > > Andreas -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#847966: python-cylc: ails to upgrade from 'jessie' - trying to overwrite /usr/lib/python2.7/dist-packages/xdot.py
python-cylc is a new package which hasn't been in testing before (or tested properly against piuparts). xdot 0.7-2 supplies /usr/lib/python3/dist-packages/xdot.py instead. I'll need to add a versioned breaks / replaces for xdot, thanks. regards Alastair On 12/12/2016 16:54, Andreas Beckmann wrote: > Package: python-cylc > Version: 6.11.2-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'jessie', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > > >From the attached log (scroll to the bottom...): > > Selecting previously unselected package python-cylc. > Preparing to unpack .../python-cylc_6.11.2-1_amd64.deb ... > Unpacking python-cylc (6.11.2-1) ... > dpkg: error processing archive > /var/cache/apt/archives/python-cylc_6.11.2-1_amd64.deb (--unpack): >trying to overwrite '/usr/lib/python2.7/dist-packages/xdot.py', which is > also in package xdot 0.6-2 > > > Interestingly there is no conflict with xdot 0.7-2 in stretch/sid. > > > cheers, > > Andreas -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
