Bug#875267: [Debichem-devel] Bug#875267: FTBFS: dpkg-source fails due to changes in upstream source
On Sun, 2018-06-24 at 18:40 +0200, Michael Banck wrote: > Hi Drew, > > On Sun, Sep 10, 2017 at 01:48:09PM +0800, Drew Parsons wrote: > > nwchem cannot build on its own, since changes are made to some > > upstream files outside of the debian/patches system. ... > > web/doc/user.4.6/user.html.bak, use --include-removal to override > > dpkg-source: info: local changes detected, the modified files > > are: > >nwchem/src/config/NWCHEM_CONFIG > >nwchem/src/config/nwchem_config.h > > So I guess all it would take is rm those two files in > dh_override_auto_clean, after the dh_auto_clean? > > I have pushed such a change to master now if you would like to test > it. > I think I don't see it cause I hacked my dpkg-buildpackage -S to no > look > at upstream, bad me. Thanks Michael. The build proceeds now in pbuilder using the new source (apt-get source nwchem). Buildds are happy (at least, with the fix for this bug). Drew
Bug#902198: octave-odepkg FTBFS with octave 4.4.0
On Sat, 23 Jun 2018 12:54:19 +0300 Adrian Bunk wrote: > ... > odepkg_octsolver_mebdfdae.cc:42:10: fatal error: config.h: No such file or directory > #include > ^~ The patch is trivial. Replace all with . config.h was already deprecated, and is now removed in octave 4.4.0. Drew
Bug#902198: octave-odepkg FTBFS with octave 4.4.0
On Thu, 28 Jun 2018 20:57:52 +0200 =?iso-8859-1?Q?S=E9bastien?= Villemot wrote: > > > > The patch is trivial. Replace all with . > > > > config.h was already deprecated, and is now removed in octave 4.4.0. > > Yes, but then you get many numerical test failures, which are not trivial at > all to fix… > Does https://bitbucket.org/odepkg/odepkg/commits/d4f56c4f3678f7f55d8dc84c96fbd0f98f8d4191 help? Perhaps with https://bitbucket.org/odepkg/odepkg/commits/d60b477d520c762ba4093e1a8f7a036d50b80db1 Or does latest the upstream git work, should we just grab that? Drew
Bug#790196: Rasmol needs severe contribution to stay in Debian
On Tue, 2018-07-03 at 15:25 +0100, Carnë Draug wrote: > On 3 July 2018 at 14:59, Andreas Tille wrote: > > Hi, > > > > the bug log of #790196[1] shows that rasmol in its current state > > will > > not be distributable with Buster. Upstream is dead so if we want > > to > > keep it in Debian we have the option: > > > >1) Port it to Gtk+ 3 (see porting guide [2]) > >2) Find a Gtk+ 2 replacement for libvte > >3) Give up and remove this package from Debian > > > > ... > Maybe option 3 is not that bad. Debian also packages pymol which is > used even more [4] so it's not like rasmol users will be left without > an > alternative. I'd be joyful if someone kept rasmol alive. But viewmol is also an alternative which I've continued to find useful. Drew
Bug#903492: Runtime error "PMIX-XFER-VALUE: UNSUPPORTED TYPE 28016"
On Tue, 10 Jul 2018 19:57:57 +0200 Anton Gladky > > it looks like the version 3.1.1.real-1 introduces the regression in autopkgtest. > Not just the autopkgtest, it's fouling up petsc and dolfin too ;(
Bug#903492: Runtime error "PMIX-XFER-VALUE: UNSUPPORTED TYPE 28016"
On Wed, 11 Jul 2018 13:29:54 +0800 Drew Parsons wrote: > > Not just the autopkgtest, it's fouling up petsc and dolfin too ;( Might be worth mentioning though, openmpi 3.1.1.real-1 has been with us over a week now, but the problem with the dolfin build (unable to build with petsc, and getting the 28016 error) only started today. Something else might be involved. Drew
Bug#903655: libopenmpi-dev: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version
Package: libopenmpi-dev Version: 3.1.1.real-2 Severity: grave Justification: renders package unusable Did something get missed in 3.1.1.real-2? It still depends on libpmix2 (e.g. /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so), and petsc tests fail, reporting: cd src/snes/examples/tutorials >/dev/null; /usr/bin/make --no-print-directory PETSC_ARCH=x86_64-linux-gnu-real-debug PETSC_DIR=/home/drew/projects/petsc/build/petsc testex19 Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html [grendel:25623] mca_base_component_repository_open: unable to open mca_pmix_pmix2x: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version (ignored) [grendel:25623] [[7790,0],0] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 325 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): opal_pmix_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenmpi-dev depends on: ii libc62.27-4 ii libevent-2.1-6 2.1.8-stable-4 ii libevent-pthreads-2.1-6 2.1.8-stable-4 ii libhwloc-dev 1.11.10-2 ii libhwloc51.11.10-2 ii libibverbs-dev 19.0-1 ii libopenmpi3 3.1.1.real-2 ii openmpi-bin 3.1.1.real-2 ii openmpi-common 3.1.1.real-2 libopenmpi-dev recommends no packages. Versions of packages libopenmpi-dev suggests: pn openmpi-doc -- no debconf information
Bug#903655: libopenmpi-dev: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version
On Thu, 12 Jul 2018 22:35:04 +0800 Drew Parsons wrote: > > and petsc tests fail, reporting: Never mind petsc, a simpler test will do: $ mpirun -np 2 date [grendel:03595] mca_base_component_repository_open: unable to open mca_pmix_pmix2x: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version (ignored) [grendel:03595] [[29810,0],0] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 325
Bug#902198: octave-odepkg FTBFS with octave 4.4.0
On Mon, 2018-07-16 at 13:54 +0200, Rafael Laboissière wrote: > > I tried to build the package using the tip of the Mercurial > repository > for the odepkg package [1]. After some tweaks in the documentation, > I > was able to compile the source code, but the unit tests fail > miserably. > > I just noticed that odepkg was removed from the list of supported > Octave-Forge packages That's regrettable if odepkg has been abandoned ;( (just as well I've been moving my computations over to FEniCS/dolfin...) Rafael, could you push your tip efforts to a branch on odepkg salsa? I can build and test against my own octave scripts that use odepkg. Drew
Bug#902198: octave-odepkg FTBFS with octave 4.4.0
On Tue, 2018-07-17 at 00:30 +0800, Drew Parsons wrote: > On Mon, 2018-07-16 at 13:54 +0200, Rafael Laboissière wrote: > > > > I tried to build the package using the tip of the Mercurial > > repository > Weird though, https://wiki.octave.org/Odepkg points at https://bitbucket.org/odepkg/odepkg Is this a fork? The recent commits diverge from sourceforge. (more importantly, does it build, and pass tests?)
Bug#844683: libreoffice-common 5.3 preinst fails when removing missing directories
Package: libreoffice-common Version: 1:5.3.0~alpha1-1 Severity: serious Justification: Policy 6.2 The new libreoffice 5.3 in experimental fails to install. libreoffice-common fails during preinst attempting to remove directories which are not there: Preparing to unpack .../libreoffice-common_1%3a5.3.0~alpha1-1_all.deb ... dpkg-maintscript-helper: error: conffile '"/etc/bash_completion.d/libreoffice.sh"' is not an absolute path dpkg: error processing archive /var/cache/apt/archives/libreoffice-common_1%3a5.3.0~alpha1-1_all.deb (--unpack): subprocess new pre-installation script returned error exit status 1 rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory dpkg-maintscript-helper: error: conffile '"/etc/bash_completion.d/libreoffice.sh"' is not an absolute path dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/libreoffice-common_1%3a5.3.0~alpha1-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) The chain of dependencies then prevents the other libreoffice 5.3 packages from completing their configuration. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice-common depends on: ii dpkg 1.18.15 iu libreoffice-style-galaxy [libreoffice-style-default] 1:5.3.0~alpha1-1 iu libreoffice-style-tango [libreoffice-style] 1:5.3.0~alpha1-1 ii ure 5.3.0~alpha1-1 Versions of packages libreoffice-common recommends: ii fonts-liberation1:1.07.4-2 ii libexttextcat-data 3.4.4-2 iu python3-uno 1:5.3.0~alpha1-1 Versions of packages libreoffice-common suggests: pn libreoffice-style-breeze pn libreoffice-style-hicontrast pn libreoffice-style-oxygen pn libreoffice-style-sifr iu libreoffice-style-tango 1:5.3.0~alpha1-1 Versions of packages python3-uno depends on: ii libc6 2.24-5 ii libgcc1 1:6.2.0-13 ii libpython3.5 3.5.2-7 iu libreoffice-core 1:5.3.0~alpha1-1 ii libstdc++66.2.0-13 ii python3 3.5.1-4 ii python3.5 3.5.2-7 pn python3:any ii uno-libs3 5.3.0~alpha1-1 ii ure 5.3.0~alpha1-1 -- no debconf information
Bug#883619: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev
On 2019-02-26 14:54, Andreas Tille wrote: I just pushed +ceres-solver (1.14.0-4) UNRELEASED; urgency=medium ... to Git. Is there any reason not to upload this and simply fix #883619. Looks like a pretty low hanging fruit to fix an RC bug and save the package for Buster that I can not imagine nobody else would have harvested it. It's only downstream dependency is colmap. If colmap is happy with the new version then it sounds like a good idea to upload it, especially if it fixes an RC bug. Drew
Bug#856349: mpi4py: FTBFS (Exception: MPI_ERR_WIN: invalid window)
On Tue, 28 Feb 2017 10:46:53 + Santiago Vila wrote: > Package: src:mpi4py > Version: 2.0.0-2 ... > > I tried to build this package in stretch with "dpkg-buildpackage -A" > but it failed: ... > MPI.Win.Create(None, 1, MPI.INFO_NULL, MPI.COMM_SELF).Free() > File "MPI/Win.pyx", line 73, in mpi4py.MPI.Win.Create (src/mpi4py.MPI.c:123760) > Exception: MPI_ERR_WIN: invalid window The error occurs during tests. Has something changed in the API for mpi4py.MPI.Win.Create? Looks like wrong input parameters to the function might be being passed in the test script. The FTBFS is readily fixed (worked around) by treating the test errors as warnings using || /bin/true in debian/rules: /usr/bin/python$$v /usr/bin/nosetests -v --exclude='testPackUnpackExternal' -A "not network" || /bin/true ; \ If you don't time to debug the root cause of the errors, I'll upload an NMU with the warning workaround. Drew
Bug#856349: mpi4py: FTBFS (Exception: MPI_ERR_WIN: invalid window)
On Wed, 2017-03-08 at 11:30 +0100, Andreas Tille wrote: > Hi Drew, > > ... your suggestion to > turn an error about "invalid window" into a warning seems to be an > apropriate action in this case. Thanks Andreas. > May be the bug could be reopened later with lower severity to make > sure > the issue is not totally lost for the future. > I have in mind to not close the bug in fact, but just to fix the FTBFS and then downgrade the severity, leaving the error itself for further discussion. Drew
Bug#856349: mpi4py: FTBFS (Exception: MPI_ERR_WIN: invalid window)
On Wed, 2017-03-08 at 14:19 +0100, Andreas Tille wrote: > > Perfect. I was just wondering whether closing + reopening is > somehow > easier to handle technically since testing migration requires closing > an RC bug - but yes, we both mean the same in the end. That's a fair point. For the sake of migration we can treat it by closing first.
Bug#856349: mpi4py: FTBFS (Exception: MPI_ERR_WIN: invalid window)
Source: mpi4py Version: 2.0.0-2.1 Followup-For: Bug #856349 The git repo for mpi4py is not configured to give me commit access: $ git push origin debian/2.0.0-2.1 Counting objects: 8, done. Delta compression using up to 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.10 KiB | 0 bytes/s, done. Total 8 (delta 6), reused 0 (delta 0) remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://git.debian.org/git/pkg-exppsy/mpi4py.git ! [remote rejected] debian/2.0.0-2.1 -> debian/2.0.0-2.1 (unpacker error) error: failed to push some refs to 'ssh://dpars...@git.debian.org/git/pkg-exppsy/mpi4py.git' I'm attaching the patches instead, for treating test errors as warnings. I've already uploaded 2.0.0-2.1. Drew -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) >From dd69f5f6bafeb518cd236ca167aff5233ab0daeb Mon Sep 17 00:00:00 2001 From: Drew Parsons Date: Fri, 10 Mar 2017 11:53:14 +0800 Subject: [PATCH 1/2] NMU: fix FTBFS by treating test errors as warnings Closes: #856349 --- debian/rules | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 91e16af..6a5bbed 100755 --- a/debian/rules +++ b/debian/rules @@ -88,8 +88,9 @@ override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) set -e; for v in $(PY2VERS) $(PY3VERS); do \ echo "I: testing using python$$v"; \ + echo "Note: test errors here are treated as warnings"; \ PYTHONPATH=`/bin/ls -d $(CURDIR)/build/lib.*-$$v` \ - /usr/bin/python$$v /usr/bin/nosetests -v --exclude='testPackUnpackExternal' -A "not network" ; \ + /usr/bin/python$$v /usr/bin/nosetests -v --exclude='testPackUnpackExternal' -A "not network" || /bin/true ; \ done else : # Skip unittests due to nocheck -- 2.11.0 >From 3de2caecd31ca7747fff2ffaf5cbe0bbc73b06ea Mon Sep 17 00:00:00 2001 From: Drew Parsons Date: Fri, 10 Mar 2017 11:54:28 +0800 Subject: [PATCH 2/2] NMU: upload 2.0.0-2.1 to unstable * Non-maintainer upload. * In debian/rules:override_dh_auto_test, treat test errors as warnings. Closes: #856349. --- debian/changelog | 8 1 file changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index a6e5ba3..c11ff23 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +mpi4py (2.0.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * In debian/rules:override_dh_auto_test, treat test errors as warnings. +Closes: #856349. + + -- Drew Parsons Wed, 08 Mar 2017 16:18:00 +0800 + mpi4py (2.0.0-2) unstable; urgency=medium * Point to libm.so.6 in the test, not libm.so (Closes: #817884) -- 2.11.0
Bug#854228: Libraries not linked with their deps
On Wed, 08 Feb 2017 14:25:12 +0100 =?ISO-8859-1?Q?S=E9bastien?= Villemot wrote: > > I don't know what's the proper solution to this issue. The circularity > can easily be dealt with (using patchelf for closing the loop in > DT_NEEDED entries). > > The problem is rather that the Cblacs_pinfo symbol is provided by two > alternative (and mutually exclusive) libraries. Input from the > maintainer would be helpful here. There is some discussion upstream at http://www.netlib.org/blacs/mpiblacs_issues.ps They say the alternative libraries are needed for invoking MPI_INIT. Since blacs doesn't know which language you'll be accessing it with, it can only be determined at link time by linking against either blacsCinit* or blacsF77init*. They're saying it's a constraint of the MPI standard. That document is from 1997 though. The MPI standard has moved through 2 major versions since then. But blacs remains unchanged. Drew
Bug#854228: Libraries not linked with their deps
On Tue, 21 Mar 2017 10:50:29 +0800 Drew Parsons wrote: > > That document is from 1997 though. The MPI standard has moved through > 2 major versions since then. But blacs remains unchanged. Further, BLACS is now part of (packaged with) scalapack, see http://netlib.org/scalapack/scalapack-2.0.0.html#_7_3_blacs_revamping Probably the solution we want is to update our scalapack to 2.0.2, and remove this blacs package, at least as a separate source package. That won't happen for stretch, obviously. Drew
Bug#905264: im-config: incorrect if syntax prevents login
Package: im-config Version: 0.36-1 Severity: critical Justification: breaks unrelated software im-config currently generates an error at login: /usr/lib/gdm3/gdm-x-session[6333]: /etc/gdm3/Xsession: 59: /usr/share/im-config/data/21_ibus.rc: Syntax error: "fi" unexpected (expecting "then") This prevents login (when using gdm3). The fix is trivial: add the semicolon in 21_ibus.rc. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages im-config depends on: ii gettext-base 0.19.8.1-6+b1 Versions of packages im-config recommends: ii kdialog 4:17.08.3-2 ii whiptail0.52.20-5 ii x11-common 1:7.7+19 ii zenity 3.28.1-1 im-config suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/share/im-config/data/21_ibus.rc (from im-config package)
Bug#917722: pybind11: FTBFS: dh_auto_test: returned exit code 2
Source: pybind11 Followup-For: Bug #917722 This looks like more fallout from the new numpy. Bad numpy, bad.
Bug#918713: libopenmpi3: test failure triggered by mca_pmix_pmix2x.so: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version
Package: libopenmpi3 Version: 3.1.3-8 Severity: serious Justification: Policy 8.6 openmpi 3.1.3-8 is triggering test failure on a wide range of client packages, including combblas, dolfin and family, petsc and family, superlu-dist. dolfin and petsc (etc) leave a record of the fault, e.g. petsc https://ci.debian.net/data/autopkgtest/unstable/amd64/p/petsc/1662208/log.gz run SNES testex19 Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html [ci-1546915814:12491] mca_base_component_repository_open: unable to open mca_pmix_pmix2x: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so: undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version (ignored) [ci-1546915814:12491] [[63830,0],0] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 325 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): opal_pmix_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS hypre and scotch are unaffected. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenmpi3 depends on: ii libc62.28-4 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.1-5 ii libgcc1 1:8.2.0-13 ii libgfortran5 8.2.0-13 ii libhwloc-plugins 2.0.0-1 ii libhwloc51.11.12-1 ii libibverbs1 21.0-1 ii libnl-3-200 3.4.0-1 ii libnl-route-3-2003.4.0-1 ii libpmix2 3.1.0~rc2-2 ii libpsm-infinipath1 3.3+20.604758e7-6 ii libpsm2-211.2.68-4 ii libquadmath0 8.2.0-13 ii libstdc++6 8.2.0-13 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages libopenmpi3 recommends: ii openmpi-bin 3.1.3-7 libopenmpi3 suggests no packages. -- no debconf information
Bug#917670: python-pbcore: FTBFS: dh_auto_test: numpy 1.16 arraysetops dtype error
Source: python-pbcore Followup-For: Bug #917670 Control: title -1 FTBFS: dh_auto_test: numpy 1.16 arraysetops dtype error Control: forwarded -1 https://github.com/PacificBiosciences/pbcore/issues/120 Confirmed, still occurs with pbcore 1.6.5. Bug filed upstream. Drew
Bug#917670: Bug #917670 in python-pbcore marked as pending
Control: tag -1 pending Hello, Bug #917670 in python-pbcore 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/med-team/python-pbcore/commit/9f8a0d4c84e5f544ecfbe544d16ade0da672cd1a add fix_numpy_1.16_9c065b7.patch applying upstream commit Upstream commit 9c065b724ddfa2b78ddf3e2e6671cd30a50b0a66 fixes dtypes for build against numpy 1.16. Upstream issue #120. Closes: #918212, #917670. (this message was generated automatically) -- Greetings https://bugs.debian.org/917670
Bug#919000: spyder: 1
Package: spyder Version: 3.3.2+dfsg1-1 Followup-For: Bug #919000 Control: severity -1 normal It's hardly critical. Please don't overinflate bug severities. https://www.debian.org/Bugs/Developer#severities
Bug#919000: spyder: 1
On 2019-01-12 10:08, Adrian Bunk wrote: https://www.debian.org/Bugs/Developer#severities "serious" is the severity that is commonly used for missing dependencies. "Grave" could also be justified, "makes the package mostly unusable". Drew
Bug#920882: libpmix2: unable to open mca_pmix_ext2x: libpmix.so.2: No such file or directory
Package: libpmix2 Version: 3.1.2-1 Severity: grave Justification: renders package unusable The new version of libpmix2 is confusing client packages, breaking CI tests in many packages, e.g. for petsc: run SNES testex19 Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html [ci-1548795660:12338] mca_base_component_repository_open: unable to open mca_pmix_ext2x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored) [ci-1548795660:12338] [[65452,0],0] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 325 The error references mca_pmix_ext2x which I presume means mca_pmix_ext2x.so from libopenmpi3. Does it simply mean that openmpi needs to be rebuilt against the new pmix? Please reassign this bug to libopenmpi3 if needed. Drew -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpmix2 depends on: ii libc62.28-5 ii libevent-2.1-6 2.1.8-stable-4 ii libevent-pthreads-2.1-6 2.1.8-stable-4 ii libhwloc-plugins 2.0.0-1 ii zlib1g 1:1.2.11.dfsg-1 libpmix2 recommends no packages. libpmix2 suggests no packages. -- no debconf information
Bug#921437: nmu: mpi4py_2.0.0-3+b2
Package: release.debian.org Severity: serious User: release.debian@packages.debian.org Usertags: binnmu dolfin has started to FTBFS, see https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/dolfin_2018.1.0.post1-13.rbuild.log.gz The dolfin build error comes from mpi4py. The dolfin build succeeds when made with mpi4py rebuilt against with cython 0.29.2-2. Current mpi4py was built with cython 0.28.2-4. The new cython version was uploaded in January. The problem is discussed some more at https://bitbucket.org/mpi4py/mpi4py/issues/112/ For the forthcoming Debian release, it is sufficient to rebuild mpi4py against cython 0.29.2-2 (then we can rebuild dolfin), so please trigger the binNMU. I've marked this bug as "serious" since it involves a FTBFS (of dolfin). nmu mpi4py_2.0.0-3+b2 . ANY . unstable . -m "Rebuild against cython 0.29.2" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#802706: slepc: FTBFS: Unable to link with PETSc
On Thu, 2017-01-05 at 14:10 +0100, Santiago Vila wrote: > found 802706 3.7.3+dfsg1-3 > thanks > > Hi. > > Sorry for the reopening but this is happening again in stretch. > (I built this package 200 times, and it failed 200 times). > > Build logs available here: > > https://people.debian.org/~sanvila/build-logs/slepc/ > > Thanks. It's not the same bug. Attach the configure.log mentioned in the build log. It's hdf5 this time. Drew
Bug#851966: texlive-bibtex-extra: biblatex breaks compatibility with biber
Package: texlive-bibtex-extra Version: 2016.20170118-1 Severity: grave Justification: renders package unusable The new version of biblatex in this package cannot be used with biber. That makes this biblatex unusable. Output looks like: $ biber project INFO - This is Biber 2.6 INFO - Logfile is 'project.blg' INFO - Reading 'project.bcf' ERROR - Error: Found biblatex control file version 3.3, expected version 3.2. This means that your biber (2.6) and biblatex (3.7) versions are incompatible. See compat matrix in biblatex or biber PDF documentation. INFO - ERRORS: 1 -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-bibtex-extra depends on: ii tex-common 6.06 ii texlive-base2016.20170118-1 ii texlive-binaries2016.20160513.41080.dfsg-1 ii texlive-latex-base 2016.20170118-1 texlive-bibtex-extra recommends no packages. texlive-bibtex-extra suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.18.18 ii ucf 3.0036 Versions of packages tex-common suggests: ii debhelper 10.2.3 Versions of packages texlive-bibtex-extra is related to: ii tex-common6.06 ii texlive-binaries 2016.20160513.41080.dfsg-1 -- no debconf information
Bug#852011: petsc (libpetsc3.7.4-dev) depends on libgfortran-5-dev
On Fri, 20 Jan 2017 18:22:01 +0100 Matthias Klose wrote: > > The severity of this report is likely to be raised before the release, > so that the gcc-5 package can be removed for the release. > "Likely to be raised..." ?? The severity is already serious! Drew
Bug#1036576: libscotch{,par}metis-dev: broken symlinks: /usr/lib//*metis-*/lib*metis.* -> ../scotch-*/lib*metis.*
Package: libscotchmetis-dev Version: 7.0.3-1 Followup-For: Bug #1036576 Awkward. Thanks for catching it.
Bug#1030408: duecredit: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '0.9.1.debian1'
Package: python3-duecredit Followup-For: Bug #1030408 Control: forwarded -1 https://github.com/duecredit/duecredit/pull/184 This bug is affecting unrelated packages, confirming the Severity:serious. For instance the new mp_api module tries to read its version using pkg_resources.get_distribution, but fails with InvalidVersion: Invalid version: '0.9.1.debian1' duecredit is the only package with version 0.9.1.debian1 (mp_api's version is 0.27.5) Upstream has seen the issue and provided a patch, just released in v0.9.2 Could upgrade to that version, or alternatively could pull in just the patch from https://github.com/duecredit/duecredit/pull/184 Might as well upgrade to 0.9.2 since there is only one other commit, it won't be disruptive.
Bug#1029690: marked as pending in python-scipy
Control: tag -1 pending Hello, Bug #1029690 in python-scipy 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/scipy/-/commit/5b51c3695ddc2750e7c04644f6f4e82484a9148a add debian patch fix_cast_PR17726.patch applies upstream PR17726 to fix 32-bit/64-bit casting. Closes: #1029690. (this message was generated automatically) -- Greetings https://bugs.debian.org/1029690
Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))
On 2023-02-09 15:02, Andreas Tille wrote: Control: tags -1 help Am Thu, Feb 09, 2023 at 12:50:45AM +0100 schrieb Santiago Vila: Package: src:umap-learn Version: 0.4.5+dfsg-3 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in bookworm, your package failed to build: In Salsa CI you can find a more informative log: https://salsa.debian.org/med-team/umap-learn/-/jobs/3923570 Looking at line 1307 and following I'm wondering, whether this issue is rather caused by scikit-learn which is not fully converted to numpy 1.24. Any ideas how to fix this? tldr; https://github.com/lmcinnes/umap/pull/946 There's a couple of strange aspects to this problem. The np.matrix seems to be generated by scipy.sparse. np.matrix is "not recommended" by numpy, but not actually deprecated (at least not removed) yet. scikit-learn is jumping the gun by declaring it's not supported. On the other hand, scitkit-learn has been "not supporting" it for two years now. This corner of the debian archive is quite a bit out of date. The current version of umap (i.e. umap-learn) is 0.5.3, released April last year. That said, the np.matrix discrepancy was only just fixed recently, in December, by https://github.com/lmcinnes/umap/pull/946 Drew
Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))
On 2023-02-09 20:37, Andreas Tille wrote: Hi again, Am Thu, Feb 09, 2023 at 05:52:13PM +0100 schrieb Andreas Tille: > That said, the np.matrix discrepancy was only just fixed recently, in > December, by > https://github.com/lmcinnes/umap/pull/946 I've updated the packaging, added the PR, fixed some test issues that were not yet addressed by these patches but there are remaining issues: https://salsa.debian.org/med-team/umap-learn/-/jobs/3925631 Any idea how to fix these? First error looks like it might be https://github.com/lmcinnes/umap/commit/949abd082524fce8c45dfb147bcd8e8ef49eade3 Error 2 *might* be https://github.com/lmcinnes/umap/pull/952 via umap/utils.py:161: in csr_unique
Bug#1030775: xtensor: baseline violation: builds with -march=native
Source: xtensor Followup-For: Bug #1030775 Control: tags -1 wontfix moreinfo I think this is not a bug. xtensor is a header-only library. The builds you're seeing with -march=native are in the tests only, not compiled into the binary package. We could make some effort to prevent the tests running with -march=native. But I prefer to leave the flag there for tests, since it better reflects how the package might be used by an end-user. I think we can close this bug, but I'll leave it open for a little while in case further discussion is needed.
Bug#1031705: pymatgen: 7th item of test_babel randomly hangs autopkgtest
Source: pymatgen Followup-For: Bug #1031705 The situation is not entirely clear. That is, there is another timeout in https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pymatgen/31542441/log.gz but in this case in test_cif.py. test_babel.py passed. Does it mean there are two separate tests subject to timeout, and both should be skipped? Or does it mean the timeout is actually a hold-up in an earlier test which eventually gets resolved, but too late for all the remaining tests to pass before the time cut-off. In this case that earlier test would be the one that should be skipped.
Bug#1031705: pymatgen: 7th item of test_babel randomly hangs autopkgtest
Source: pymatgen Followup-For: Bug #1031705 Apart from that one case of test_cif.py, every other timeout occurs in test_babel.py. If it were a 3rd test being held up and resolving too late for other tests to pass, then the timeout would occur more randomly. So looks like the 7th item (test_localopt) of test_babel is indeed the main problem. Maybe the test_cif.py error was one-off (or maybe blocked by the test_localopt timeout)
Bug#1032488: opendrop: arkode (sundials) error prevents interfacial tension analysis
Package: opendrop Version: 3.3.1-4 Severity: grave Tags: patch upstream Justification: renders package unusable debian patch sundials_nvector_API6.patch enabled opendrop to build against sundials 6. Nevertheless it still fails when attempting to analysis interfacial tension measurements: [ARKODE::ERKStep ERROR] erkStep_FullRHS At t = inf, the right-hand side routine failed in an unrecoverable manner. [ARKODE ERROR] ARKODE At t = 0, the right-hand side routine failed in an unrecoverable manner. Exception in callback PendantAnalysisJob._ylfit_done() handle: )> concurrent.futures.process._RemoteTraceback: """ Traceback (most recent call last): File "/usr/lib/python3.11/concurrent/futures/process.py", line 256, in _process_worker r = call_item.fn(*call_item.args, **call_item.kwargs) ^ File "/usr/lib/python3/dist-packages/opendrop/fit/younglaplace/__init__.py", line 51, in young_laplace_fit model.set_params(initial_params) File "/usr/lib/python3/dist-packages/opendrop/fit/younglaplace/model.py", line 86, in set_params dr_dBo, dz_dBo = radius * shape.DBo(s) File "opendrop/fit/younglaplace/shape.pyx", line 71, in opendrop.fit.younglaplace.shape.YoungLaplaceShape.DBo File "opendrop/fit/younglaplace/shape.pyx", line 89, in opendrop.fit.younglaplace.shape.YoungLaplaceShape.DBo_array RuntimeError: ERKStepEvolve() failed. """ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/opendrop/vendor/aioglib/_loop.py", line 463, in __call__ self._context.run(self._callback, *self._args) File "/usr/lib/python3/dist-packages/opendrop/app/ift/services/analysis.py", line 219, in _ylfit_done raise e File "/usr/lib/python3/dist-packages/opendrop/app/ift/services/analysis.py", line 217, in _ylfit_done result = fut.result() RuntimeError: ERKStepEvolve() failed. Upstream has prepared a patch to update properly for sundials 6 in commit cf9d5aa (development branch), https://github.com/jdber1/opendrop/commit/cf9d5aa2f06d625f306114d001a99934cb913ff0 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendrop depends on: ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gtk-3.03.24.36-4 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libpython3.11 3.11.2-5 ii libstdc++612.2.0-14 ii libsundials-arkode5 6.4.1+dfsg1-3 ii python3 3.11.2-1 ii python3-cairo 1.20.1-5+b1 ii python3-gi3.42.2-3+b1 ii python3-injector 0.20.1-1 ii python3-matplotlib3.6.3-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-opencv4.6.0+dfsg-11 ii python3-scipy 1.10.1-2 opendrop recommends no packages. Versions of packages opendrop suggests: ii opendrop-doc 3.3.1-4.1 -- no debconf information
Bug#1030220: xrayutilities: missing dependency on python3-h5py breaks armel tests
Source: xrayutilities Version: 1.7.4-1 Severity: serious Justification: debci python3-xrayutilities has an inconsistent Dependency on h5py It declares python3-h5py-serial [alpha, hppa, m68k, sparc64, x32], in other words is not declared for most architectures. But xrayutilities needs h5py in io/helper.py, so the missing dependency of python3-h5py cases armel tests to fail. The failure is triggered by scipy 1.10. Other arches pass. I think that they are passing due to an indirect dependency from some other package, which isn't applied to armel. Since python3-xrayutilities uses h5py directly, it needs Depends: python3-h5py xrayutilities does have Build-Depends: python3-h5py. Evidentally dh-python3 isn't able to determine the correct dependency for h5py (likely it gets confused by python3-h5py-serial). Until that's fixed, python3-xrayutilities should declare Depends: python3-h5py explicitly.
Bug#1030221: statsmodels: 32 bit arches fail tests using int64
Source: statsmodels
Version: 0.13.5+dfsg-4
Severity: serious
Justification: debci
scipy 1.10 is triggering a problem with tests using int64 on 32 bit
arches (armhf, i386, armel)
Affected tests are in test_discrete.py:
TestDiscretizedGamma.test_basic
TestDiscretizedExponential::test_basic
TestDiscretizedLomax::test_basic
TestDiscretizedBurr12::test_basic
with the same error message
E TypeError: Cannot cast array data from dtype('int64') to dtype('int32')
according to the rule 'safe'
Some 32-bit dtype issues were raised upstream at
https://github.com/statsmodels/statsmodels/issues/7736
but that doesn't seem to be the same problem.
Bug#1030220: xrayutilities: missing dependency on python3-h5py breaks armel tests
On 2023-02-01 22:40, Stefano Rivera wrote: Hi Drew (2023.01.31_18:48:32_-0400) xrayutilities does have Build-Depends: python3-h5py. Evidentally dh-python3 isn't able to determine the correct dependency for h5py (likely it gets confused by python3-h5py-serial). Until that's fixed, python3-xrayutilities should declare Depends: python3-h5py explicitly. This sounds like an issue in the way the python3-h5py package is structured. python3-h5py-serial has the .egg-info, so that's the dependency that's being generated. You can customize this with a PyDist override file, see: /usr/share/doc/dh-python/README.PyDist That sounds like a good solution. h5py will be the better for it. Thanks, Stefano. Drew
Bug#1030220: xrayutilities: missing dependency on python3-h5py breaks armel tests
Control: reopen 1030220 h5py 3.7.0-4 is uploaded fixing the source of the problem, but xrayutilities will need to be rebuilt to use the new pydist definitions.
Bug#1037854: scipy: ftbfs with GCC-13
Source: scipy Followup-For: Bug #1037854 The errors in the build log refer to pythran, not scipy.
Bug#1037823: marked as pending in pythran
Control: tag -1 pending Hello, Bug #1037823 in pythran 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/pythran/-/commit/3dedbc4004f9321559311ad246d77ddccebbbcb3 add debian patch gcc13_PR2029.patch applies upstream PR#2029 to fix build with gcc-13. Closes: #1037823. (this message was generated automatically) -- Greetings https://bugs.debian.org/1037823
Bug#1041705: dolfin: libdolfin needs ABI bump
Source: dolfin Version: 2019.2.0~legacy20230609.8b85e9d.ar-2 Severity: serious Justification: Policy 8.6.2 Control: affects -1 python3-mshr The accumulation of git changes and gcc-13 fixes has apparently introduced an ABI inconsistency in libdolfin.so, such that mshr can no longer be imported in python, and mshr tests fails. see https://ci.debian.net/data/autopkgtest/testing/amd64/f/fenics/36044020/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/m/mshr/36044021/log.gz A rebuild of mshr fixes the issue, but really dolfin shouldn't migrate to testing if it's doing this, so marking severity: serious. A new upstream release is expected soon which we'll treat as an ABI upgrade to resolve the issue.
Bug#1028097: mplcursors: remove Build-Depends: libopenblas0 (use libblas-dev instead)
Source: mplcursors Version: 0.5.2-1 Severity: serious Justification: debci mplcursors Build-Depends:libopenblas0 This is bad for several reasons. Firstly, OpenBLAS is not available on all architectures. In particular it's not available on armel (and mipsel), and therefore debci testing on armel fails, due to the missing libopenblas0. That's why I'm filing this bug as Severity: serious (debci). Secondly, it's wrong to specify a specific library binary package in Build-Depends. Build-Depends should be made using the development package instead, i.e. Build-Depends: libblas-dev. Note that is not Build-Depends: libopenblas-dev, see next point. Thirdly, in regards to BLAS support, all BLAS packages are binary-compatible, with the preferred BLAS implementation controllable using the debian alternatives mechanisms. Even where OpenBLAS is available, it may not be the best BLAS implementation for the activity that a particular system performs. That is, the local admin might determine that blis or atlas (or intel-mkl) performs better. Not to mention the various threaded builds which would generally have better performance than libopenblas0, which is a serial build. For this reason, debian packages using blas are usually built against the generic (slow) libblas-dev. Then one of the performant BLAS implementation is installed at runtime by the system administrator. On your own machine you'll want one of the optimised BLAS implementations installed (libopenblas0, for instance). So to allow for this the Build-Depends can include alternatives. But the first alternative should be the generic development package, libblas-dev, so that it's used by the debian buildds to build the package. Thus, the Build-Depends should be something like Build-Depends: libblas-dev | libopenblas-dev | libblis-dev | libatlas-base-dev
Bug#1028097: mplcursors: remove Build-Depends: libopenblas0 (use libblas-dev instead)
Actually looking more closely at the source, mplcursors doesn't even use BLAS at all. In that case just remove the libopenblas0 dependency altogether (both Build-Depends: and Depends: for the binary package).
Bug#1027230: python-dmsh: autopkgtest fail with numpy/1.24.1
Source: python-dmsh Followup-For: Bug #1027230 I can't reproduce this error. debci tests are passing fine on all architectures.
Bug#1026346: petsc4py: autopkgtest needs update for new version of numpy: OverflowError: Python int too large to convert to C int
Source: petsc4py Followup-For: Bug #1026346 Control: affects 1027044 src:petsc4py As far as I can tell, this error is the python/numpy verson of "missing symbol" error after a library update with ABI bump. A similar error was found in many packages depending on numpy during the recent upgrade to numpy 1.23. Packages built after that (in unstable) saw the same error from their older version in testing, which cleared once the new packages (numpy and these new packages) migrated to testing. We have sonames to manage shared library dependencies, and manage library package updates using Transition bugs. In principle we have the same mechanism with numpy, python3-numpy Provides: python3-numpy-abi9, python3-numpy-api16 and correspondingly python3-petsc4py-real3.18 Depends: python3-numpy-abi9 and there is a new Transition bug filed (Bug#1027044) to now update numpy to 1.24. I'm not sure why the numpy abi mechanism has failed this time with petsc4py and numpy 1.23. Perhaps the abi declaration is buggy and numpy 1.23 does not actually provide python3-numpy-abi9. In any case, I expect the error to clear after rebuilding petsc4py against the latest numpy. Since the numpy transtion Bug#1027044 is filed, the problem should clear as part of that transition.
Bug#1027285: matplotlib: axes3d.quiver() fails when providing args to Line3DCollection
Source: matplotlib Version: 3.6.2-3 Severity: serious Justification: debci Control: forwarded -1 https://github.com/matplotlib/matplotlib/issues/24842 Control: block 1027170 by -1 mplot3d.axes3d.quiver() accepts boths args and kwargs in its function definition. Both args (any remaining after the first 6 values) and kwargs are passed onwards to art3d.Line3DCollection at matplotlib/lib/mpl_toolkits/mplot3d/axes3d.py Line 2655 in 3393a4f: linec = art3d.Line3DCollection(lines, *args[argi:], **kwargs) But arguments for Line3DCollection are passed directly to LineCollection. In matplotlib PR#23076 appearing in matplotlib 3.6, LineCollection was changed so that it no longer accepts positional args. All excess arguments must now be provided in kwargs. This means axes3d.quiver() now fails with matplotlib 3.6. An example failure is in 3D plot tests from dolfin. The python backtrace running* this demo script (on a debian system) looks like Traceback (most recent call last): File "/projects/fenics/build/tests/dolfin/demo-python/undocumented/curl-curl/demo_curl-curl.py", line 172, in plot(J) File "/usr/lib/petsc/lib/python3/dist-packages/dolfin/common/plotting.py", line 440, in plot return _plot_matplotlib(object, mesh, kwargs) File "/usr/lib/petsc/lib/python3/dist-packages/dolfin/common/plotting.py", line 306, in _plot_matplotlib return mplot_function(ax, obj, **kwargs) File "/usr/lib/petsc/lib/python3/dist-packages/dolfin/common/plotting.py", line 218, in mplot_function return ax.quiver3D(*args, length=length, **kwargs) File "/usr/lib/python3/dist-packages/matplotlib/__init__.py", line 1427, in inner return func(ax, *map(sanitize_sequence, args), **kwargs) File "/usr/lib/python3/dist-packages/mpl_toolkits/mplot3d/axes3d.py", line 2567, in quiver linec = art3d.Line3DCollection(lines, *args[argi:], **kwargs) TypeError: LineCollection.__init__() takes 2 positional arguments but 3 were given The TypeError occurs because of the use of args, which, to reiterate, was removed in matplotlib 3.6 PR#23076. I gather that any options which were previously provided to axes3d.quiver and intended for use in Line3DCollection must now be provided in kwargs instead. quiver should no longer use args at all at l.2655. * Note, to run that dolfin demo to reproduce the error, dolfin/common/plotting.py also needed updating for matplotlib 3.6 near l.279: -ax = plt.gca(projection='3d') +ax = plt.axes(projection='3d') This patch will be applied to dolfin to close Bug#1027170. For matplotlib itself, I propose simply removing the use of args in axes3d.py l.2655: - linec = art3d.Line3DCollection(lines, *args[argi:], **kwargs) + linec = art3d.Line3DCollection(lines, **kwargs)
Bug#1026421: Bug #1026421 rclone should have a build dependency on golang >= 1.17
severity 1026421 important thanks The version of rclone in testing is not directly intended to be built on stable, hence this bug is not Severity: serious (it builds fine in unstable and testing). Severity: serious is intended to mark packages which are not fit for release in testing (the future stable release).
Bug#930577: coinor-libipopt-dev: uses uninitialized memory with MUMPS >= 5.1.0
Package: coinor-libipopt-dev Version: 3.11.9-2.1+b2 Severity: serious Justification: causes memory leaks IPOPT causes memory leaks due to use of not initialized memory with MUMPS >= 5.1.0. The problem affects idyntree, see https://github.com/robotology/idyntree/issues/456 The latest version of ipopt 3.12.11 fixes the problem, so ipopt should be upgraded, see Bug#929265. It would be helpful if the specific patch could be cherry picked for buster, https://github.com/traversaro/Ipopt/commit/170c48dcc591c679a11d0198d6186cad56feddee -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coinor-libipopt-dev depends on: ii coinor-libipopt1v5 3.11.9-2.1+b2 ii libmumps-seq-dev5.2.0-1 coinor-libipopt-dev recommends no packages. coinor-libipopt-dev suggests no packages. -- no debconf information
Bug#933536: FTBFS: PYGAC_CONFIG_FILE is not a file or does not exist
Source: satpy Version: 0.16.1-1 Severity: serious Justification: FTBFS Control: affects -1 src:python-scipy satpy now FTBFS (and fails tests) because of the recent upgrade of python3-pygac to 1.1.0-2. test_basic_check_satpy (satpy.tests.test_config.TestCheckSatpy) Test 'check_satpy' basic functionality. ... ERROR:pygac.gac_io:Environment variable PYGAC_CONFIG_FILE not set! Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pygac/gac_io.py", line 48, in CONFIG_FILE = os.environ['PYGAC_CONFIG_FILE'] File "/usr/lib/python3.7/os.py", line 678, in __getitem__ raise KeyError(key) from None KeyError: 'PYGAC_CONFIG_FILE' ERROR test_specific_check_satpy (satpy.tests.test_config.TestCheckSatpy) Test 'check_satpy' with specific features provided. ... ok test_areas_pyproj (satpy.tests.test_config.TestBuiltinAreas) Test all areas have valid projections with pyproj. ... ok test_areas_rasterio (satpy.tests.test_config.TestBuiltinAreas) Test all areas have valid projections with rasterio. ... ok == ERROR: test_basic_check_satpy (satpy.tests.test_config.TestCheckSatpy) Test 'check_satpy' basic functionality. -- The failed tests prevent scipy from migrating to testing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933844: libpmi-pmix-dev: MPI failure in dolfin tests
Package: libpmi-pmix-dev Version: 3.1.4~rc2-1 Severity: serious Justification: breaks MPI client tests Hi Alistair and Debian science, I'm upgrading dolfin/fenics to 2019.1.0 alongside HYPRE 2.16.0, PETSc 3.11.3, pybind11 2.3.0. The tests of the libraries have passed, but the build is failing badly with an MPI error: Run C++ regressions tests (serial) Test project /home/projects/fenics/build/dolfin/obj-x86_64-linux-gnu ... Start 13: demo_eigenvalue_serial 3/51 Test #13: demo_eigenvalue_serial ***Failed0.02 sec *** The MPI_Comm_rank() function was called before MPI_INIT was invoked. *** This is disallowed by the MPI standard. *** Your MPI job will now abort. [grendel:16518] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! The same error is also triggered when running with mpirun, so the problem is not due to running an MPI-linked program as a serial job. I tested the build last week before proceeding with the upgrades and package uploads, all was fine then. The nature and the timing of the error suggests to me that pmix 3.1.4~rc2-1 (built last Thursday 1/8/2019) might be involved. It doesn't make sense that pmix should trigger an error like this, but I've filed this RC bug against pmix to halt migration while we look into it. I've raised a discussion thread with FEniCS upstream at https://fenicsproject.slack.com/archives/C26N589GV/p1564913720002300 Drew -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpmi-pmix-dev depends on: ii libpmi1-pmix 3.1.4~rc2-1 ii libpmi2-pmix 3.1.4~rc2-1 libpmi-pmix-dev recommends no packages. libpmi-pmix-dev suggests no packages. -- no debconf information
Bug#933844: libpmi-pmix-dev: MPI failure in dolfin tests
On 2019-08-04 19:04, Drew Parsons wrote: I'm upgrading dolfin/fenics to 2019.1.0 alongside HYPRE 2.16.0, PETSc 3.11.3, pybind11 2.3.0. The tests of the libraries have passed, but the build is failing badly with an MPI error: Run C++ regressions tests (serial) Test project /home/projects/fenics/build/dolfin/obj-x86_64-linux-gnu ... Start 13: demo_eigenvalue_serial 3/51 Test #13: demo_eigenvalue_serial ***Failed0.02 sec *** The MPI_Comm_rank() function was called before MPI_INIT was invoked. *** This is disallowed by the MPI standard. *** Your MPI job will now abort. [grendel:16518] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! Probably this is a clue: libdolfin.so should link to libpetsc.so. But it is missing in the new libdolfin.so. That means pmix is not the problem, so I'll close this bug once I can confirm. Drew
Bug#933845: Bug#933844: libpmi-pmix-dev: MPI failure in dolfin tests
On 2019-08-04 19:17, Drew Parsons wrote: On 2019-08-04 19:04, Drew Parsons wrote: Probably this is a clue: libdolfin.so should link to libpetsc.so. But it is missing in the new libdolfin.so. That means pmix is not the problem, so I'll close this bug once I can confirm. Yes, dolfin's cmake could not link against the new PETSc so the build proceeded without petsc. The failing tests use petsc. The error message was misleading, it should have traced back to a petsc call. Closing the pmix bug now. This bug is a dialogue between petsc and dolfin. Drew
Bug#933845: Bug#933844: libpmi-pmix-dev: MPI failure in dolfin tests
On 2019-08-04 19:04, Drew Parsons wrote: I'm upgrading dolfin/fenics to 2019.1.0 alongside HYPRE 2.16.0, PETSc 3.11.3, pybind11 2.3.0. The tests of the libraries have passed, but the build is failing badly with an MPI error: Run C++ regressions tests (serial) Test project /home/projects/fenics/build/dolfin/obj-x86_64-linux-gnu ... Start 13: demo_eigenvalue_serial 3/51 Test #13: demo_eigenvalue_serial ***Failed0.02 sec *** The MPI_Comm_rank() function was called before MPI_INIT was invoked. *** This is disallowed by the MPI standard. *** Your MPI job will now abort. [grendel:16518] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! Probably this is a clue: libdolfin.so should link to libpetsc.so. But it is missing in the new libdolfin.so. That means pmix is not the problem, so I'll close the bug against pmix once I can confirm. Drew
Bug#933845: Bug#933844: libpmi-pmix-dev: MPI failure in dolfin tests
On 2019-08-04 19:19, Drew Parsons wrote: Probably this is a clue: libdolfin.so should link to libpetsc.so. But it is missing in the new libdolfin.so. That means pmix is not the problem, so I'll close the bug against pmix once I can confirm. CMake logs confirm the that petsc test fail linking with /usr/lib/petscdir/petsc3.11/x86_64-linux-gnu-real/include/petscis.h:317:10: fatal error: H5Ipublic.h: No such file or directory #include ^ compilation terminated. PETSC 3.11.3 inserted H5Ipublic.h into petscis.h, requiring hdf5 header paths be included for compilation. Fixed upstream with commit 6a0bd7522af7eb76a79ca5f1af77fc9a30e8cdb2 Drew
Bug#933848: pygalmesh: 1
Source: pygalmesh Severity: important Tags: moreinfo,unreproducible Followup-For: Bug #933848 I'm quite confused by this bug report. pygalmesh is configured to build using pybuild not cmake, and it does build that way without cmake (whether built via 'fakeroot debian/rules binary' or 'dpkg-buildpackage'), whether cmake is installed or not. Your log snippet shows dh_auto_install -O--buildsystem=pybuild I: pybuild base:217: dh_auto_install --buildsystem=cmake So your system starts building with pybuild, but in the middle of it triggers cmake instead. That's not normal, and not expected. It doesn't behave that way for me. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933914: python3-pytest: pytest v4 breaks existing tests
Package: python3-pytest Version: 4.6.4-1 Severity: serious Justification: breaks autopkgtest tests Control: affects -1 + src:apipkg src:betamax src:ccdproc src:chardet Control: affects -1 + src:dask src:django-axes src:doit src:drms Control: affects -1 + src:fiat src:mpi4py src:pandas src:pygalmesh Control: affects -1 + src:pyjwt src:pytest-sugar src:pytest-xdist Control: affects -1 + src:pytest-xvfb src:python-dbfread Control: affects -1 + src:python-dugong src:python-graphviz Control: affects -1 + src:python-hypothesis src:python-parameterized Control: affects -1 + src:python-transliterate src:setuptools-scm Control: affects -1 + src:spyder-line-profiler src:spyder-reports Control: affects -1 + src:spyder-unittest src:sudsy python3-pytest v4 has changed the pytest API, causing many existing tests to fail. This upgrade should be treated as a Transition, uploading the package to experimental first. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pytest depends on: ii python3 3.7.3-1 ii python3-atomicwrites1.1.5-2 ii python3-attr18.2.0-1 ii python3-importlib-metadata 0.18-2 ii python3-more-itertools 4.2.0-1 ii python3-packaging 19.0-1 ii python3-pkg-resources 41.0.1-1 ii python3-pluggy 0.12.0-1 ii python3-py 1.8.0-1 ii python3-six 1.12.0-1 ii python3-wcwidth 0.1.7+dfsg1-6 python3-pytest recommends no packages. python3-pytest suggests no packages. -- no debconf information
Bug#933914: python3-pytest: pytest v4 breaks existing tests
On 2019-08-05 16:37, Novy, Ondrej wrote:
Tags: wontfix
On Mon, 05 Aug 2019 11:43:39 +0800 Drew Parsons
wrote:
This upgrade should be treated as a Transition, uploading the
package to
experimental first.
We are not using Transitions for Python upgrades because almost every
module upgrade breaks something. It's too much overhead for us. Last
time I uploaded pytest to experimental first and send information to
ML, nothing happened [1].
There seem to be regularities in the pytest4 error message, i.e. the
same errors are reported in the different packages.
It would be helpful to have an indication of the common patches that
will be needed to address them.
e.g what to do about
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py",
line 206, in wrap_session
INTERNALERROR> session.exitstatus = doit(config, session) or 0
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py",
line 250, in _main
INTERNALERROR> config.hook.pytest_runtestloop(session=session)
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/hooks.py",
line 289, in __call__
INTERNALERROR> return self._hookexec(self, self.get_hookimpls(),
kwargs)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 87, in
_hookexec
INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 81, in
INTERNALERROR> firstresult=hook.spec.opts.get("firstresult") if
hook.spec else False,
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in
_multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in
get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
_multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py",
line 271, in pytest_runtestloop
INTERNALERROR> item.config.hook.pytest_runtest_protocol(item=item,
nextitem=nextitem)
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/hooks.py",
line 289, in __call__
INTERNALERROR> return self._hookexec(self, self.get_hookimpls(),
kwargs)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 87, in
_hookexec
INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 81, in
INTERNALERROR> firstresult=hook.spec.opts.get("firstresult") if
hook.spec else False,
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in
_multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in
get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
_multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/flaky/flaky_pytest_plugin.py", line 81,
in pytest_runtest_protocol
INTERNALERROR> self.runner.pytest_runtest_protocol(item, nextitem)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/_pytest/runner.py", line 78, in
pytest_runtest_protocol
INTERNALERROR> runtestprotocol(item, nextitem=nextitem)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/_pytest/runner.py", line 87, in
runtestprotocol
INTERNALERROR> rep = call_and_report(item, "setup", log)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/flaky/flaky_pytest_plugin.py", line 118,
in call_and_report
INTERNALERROR> call = self.call_runtest_hook(item, when, **kwds)
INTERNALERROR> File
"/usr/lib/python3/dist-packages/flaky/flaky_pytest_plugin.py", line 272,
in call_runtest_hook
INTERNALERROR> when=when,
INTERNALERROR> TypeError: __init__() missing 3 required positional
arguments: 'excinfo', 'start', and 'stop'
Bug#933914: python3-pytest: pytest v4 breaks existing tests
On 2019-08-07 03:41, Novy, Ondrej wrote: Hi, Drew Parsons píše v Út 06. 08. 2019 v 17:25 +0800: e.g what to do about ... "/usr/lib/python3/dist-packages/flaky/flaky_pytest_plugin.py", line 272, in call_runtest_hook INTERNALERROR> when=when, INTERNALERROR> TypeError: __init__() missing 3 required positional arguments: 'excinfo', 'start', and 'stop' this fix looks related: https://github.com/box/flaky/pull/140/commits/9f29ed0350391c821f04118fde3f019d970dc8b2 I see, coming from flaky. Thanks Ondrej. Drew
Bug#933914: python3-pytest: pytest v4 breaks existing tests
On 2019-08-08 15:57, Ondřej Nový wrote: I see, coming from flaky. Thanks Ondrej. this should be fixed now with python-flaky 3.6.1-1. Thanks again Ondrej. That fixes the mpi4py 3.0.2-10 tests. Drew
Bug#934375: golang-github-anacrolix-ffprobe: FTBFS in sid (failing tests)
Package: src:golang-github-anacrolix-ffprobe Followup-For: Bug #934375 Control: reassign -1 src:golang-github-anacrolix-missinggo The bug is in github.com/anacrolix/missinggo/leaktest i.e. missinggo -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#934375: marked as pending in golang-github-anacrolix-missinggo
Control: tag -1 pending Hello, Bug #934375 in golang-github-anacrolix-missinggo 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/go-team/packages/golang-github-anacrolix-missinggo/commit/43b1fc689006fc4c9b0f17312e0b939129b98f4d reorganise packages to split Go source from binary files - make golang-github-anacrolix-missinggo-dev (Arch: all) with Go source code and provides Go package Depends. Closes: #934375. - place binary files in golang-github-anacrolix-missinggo-bin (this message was generated automatically) -- Greetings https://bugs.debian.org/934375
Bug#987618: petsc: please add some Breaks for smoother upgrades from buster
Source: petsc Followup-For: Bug #987618 ACK. Thanks for finding this, Andreas. I'll upload once the current update (-3) is migrated. Drew
Bug#988250: golang-go.opencensus: flaky autopkgtest: timebased test causes mismatched expectation
Source: golang-go.opencensus Followup-For: Bug #988250 Control: forwarded -1 https://github.com/census-instrumentation/opencensus-go/issues/1259 Prevented from emailing cont...@bugs.debian.org directly because of https://github.com/roundcube/roundcubemail/issues/6438#issuecomment-835782075
Bug#988250: golang-go.opencensus: flaky autopkgtest: timebased test causes mismatched expectation
Source: golang-go.opencensus Followup-For: Bug #988250 Control: severity -1 normal debian patch skip_flaky_test.patch skips the flaky test in 0.22.4-2 Hence downgrading severity to normal. Ignores the problem, doesn't actually fix it, so not closing the bug.
Bug#959946: grace: fails to start: failed request: 12 (X_ConfigureWindow)
Package: grace Version: 1:5.1.25-8 Severity: grave Justification: renders package unusable On a clean installation, grace fails to launch: $ xmgrace X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 12 (X_ConfigureWindow) Value in failed request: 0x0 Serial number of failed request: 2821 Current serial number in output stream: 2822 This happens both with the latest official build from the archive and with a fresh local rebuild. backtrace from gdb adds a reference to libthread_db.so: Starting program: /usr/bin/xmgrace [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". X Error of failed request: BadValue (integer parameter out of range for operation) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grace depends on: ii fontconfig2.13.1-4 ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4 ii libc6 2.30-7 ii libfftw3-double3 3.3.8-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libnetcdf18 1:4.7.4-1 ii libpng16-16 1.6.37-2 ii libx11-6 2:1.6.9-2+b1 ii libxbae4m 4.60.4-7+b11 ii libxm42.3.8-2 ii libxmhtml1.1 1.1.10-3 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt61:1.1.5-1+b3 ii xterm 356-1 Versions of packages grace recommends: ii xfonts-100dpi 1:1.0.4+nmu1 ii xfonts-75dpi 1:1.0.4+nmu1 Versions of packages grace suggests: ii gconf2 3.2.6-6 ii ghostscript 9.52~dfsg-1 pn texlive-extra-utils -- no debconf information
Bug#960391: evdi-dkms: drmP.h removed in linux 5.5
Package: evdi-dkms Version: 1.6.4+dfsg-1 Severity: grave Justification: renders package unusable evdi-dkms is currently unable to build the kernel module. /var/lib/dkms/evdi/1.6.4+dfsg/build/make.log reports: CC [M] /var/lib/dkms/evdi/1.6.4+dfsg/build/evdi_gem.o /var/lib/dkms/evdi/1.6.4+dfsg/build/evdi_drv.c:11:10: fatal error: drm/drmP.h: No such file or directory 11 | #include | ^~~~ compilation terminated. The problem is known upstream, https://github.com/DisplayLink/evdi/issues/185 https://github.com/DisplayLink/evdi/issues/199 Marking this bug with severity grave since it affects the standard linux kernel in unstable, linux-image-amd64 5.6.7-1 -- 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.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evdi-dkms depends on: ii dkms 2.8.1-5 Versions of packages evdi-dkms recommends: ii libevdi0 1.6.4+dfsg-1 evdi-dkms suggests no packages. -- no debconf information
Bug#960391: evdi-dkms: drmP.h removed in linux 5.5)
The drmP.h build error can be addressed with https://gitweb.frugalware.org/frugalware-current/raw/master/source/lib-extra/evdi/kernel-5.5-test.patch from https://aur.archlinux.org/packages/evdi-git/#comment-744589 But then it hits the fatal error: linux/reservation.h: No such file or directory reported in Bug#954396. https://aur.archlinux.org/packages/evdi-git/#comment-744589 provides some clues to that problem in https://crazy.dev.frugalware.org/evdi-all-in-one-fixes.patch but it doesn't fully fix the build.
Bug#960391: evdi-dkms: drmP.h removed in linux 5.5
Probably evdi 1.7.0 will help, released just 3 hours ago.
Bug#979290: pytest-mpi autopkgtests fail with pytest 6
forwarded 979290 https://github.com/aragilar/pytest-mpi/issues/14 thanks There is a proposed fix in PR12, https://github.com/aragilar/pytest-mpi/pull/12
Bug#980033: libucx0: UCX ERROR rdma_create_event_channel failed: No such device
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 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
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
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#972246: numba ftbfs in unstable with python3.9 as supported python3 version
Source: numba Followup-For: Bug #972246 X-Debbugs-Cc: Andreas Tille Hi Andreas, check the upstream bug. The fix was merged only 4 days ago, 0.52.0 does not have it. We could try backporting PR#6579 to 0.52.0. Maybe it will work but there is a reasonable chance that it won't.
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
Package: libopenmpi3 Version: 4.1.0-6 Followup-For: Bug #979041 Control: reopen 979041 We need to reopen this bug unfortunately. The libfabric (RDMAV_FORK_SAFE) issue is still live in python MPI applications. You can see it in pytest-mpi tests as reported previously, or in a rebuild of mpi4py, e.g. https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/mpi4py_3.0.3-7.rbuild.log.gz Drew -- 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-4 ii zlib1g 1:1.2.11.dfsg-2 libopenmpi3 recommends no packages. libopenmpi3 suggests no packages. -- no debconf information
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
On 2021-01-15 23:14, Alastair McKinstry wrote: 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 ? Hi Alastair, sorry for the delay replying to these questions. I'm attaching /etc/openmpi/openmpi-mca-params.conf In summary, the lines at the end that I think would be dealing with libfabric are # Silence this warning on Debian, as many systems don't have openfabric # but the warning breaks higher layers or application btl_base_warn_component_unused=0 # Avoid openib an in case applications use fork: see https://github.com/ofiwg/libfabric/issues/6332 # If you wish to use openib and know your application is safe, remove the following: # Similarly for UCX: https://github.com/open-mpi/ompi/issues/8367 btl = ^uct,openib pml = ^ucx osc = ^ucx (the last line with osc doesn't have a newline at the end, but I guess that's not important for runtime) hello world doesn't generate any error. The error seems to be specific to python execution, perhaps when forking mpi process from python? That said, petsc4py is not generating the error. mpi4py is probably the most direct way of probing the problem. The test log for hello world is: $ autopkgtest -B -- null 2>&1 | tee ../openmpi-test.log autopkgtest [14:37:31]: starting date: 2021-01-19 autopkgtest [14:37:31]: version 5.15 autopkgtest [14:37:31]: host sandy; command line: /usr/bin/autopkgtest -B -- null autopkgtest [14:37:31]: testbed dpkg architecture: amd64 autopkgtest [14:37:31]: testbed running kernel: Linux 5.10.0-1-amd64 #1 SMP Debian 5.10.5-1 (2021-01-09) autopkgtest [14:37:31]: unbuilt-tree . autopkgtest [14:37:32]: testing package openmpi version 4.1.0-6 autopkgtest [14:37:32]: build not needed autopkgtest [14:37:32]: test hello1: preparing testbed autopkgtest [14:37:32]: test hello1: [--- Hello world from processor sandy, rank 0 out of 1 processors autopkgtest [14:37:37]: test hello1: ---] autopkgtest [14:37:37]: test hello1: - - - - - - - - - - results - - - - - - - - - - hello1 PASS autopkgtest [14:37:37]: test hello2: preparing testbed autopkgtest [14:37:37]: test hello2: [--- node 0 : Hello world autopkgtest [14:37:39]: test hello2: ---] autopkgtest [14:37:39]: test hello2: - - - - - - - - - - results - - - - - - - - - - hello2 PASS autopkgtest [14:37:39]: test hello4: preparing testbed autopkgtest [14:37:39]: test hello4: [--- node 0 : Hello world autopkgtest [14:37:41]: test hello4: ---] autopkgtest [14:37:41]: test hello4: - - - - - - - - - - results - - - - - - - - - - hello4 PASS autopkgtest [14:37:41]: summary hello1 PASS hello2 PASS hello4 PASS $ echo $? 0 # # Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana # University Research and Technology # Corporation. All rights reserved. # Copyright (c) 2004-2005 The University of Tennessee and The University # of Tennessee Research Foundation. All rights # reserved. # Copyright (c) 2004-2005 High Performance Computing Center Stuttgart, # University of Stuttgart. All rights reserved. # Copyright (c) 2004-2005 The Regents of the University of California. # All rights reserved. # Copyright (c) 2006-2017 Cisco Systems, Inc. All rights reserved # Copyright (c) 2018 Intel, Inc. All rights reserved. # $COPYRIGHT$ # # Additional copyrights may follow # # $HEADER$ # # This is the default system-wide MCA parameters defaults file. # Specifically, the MCA parameter "mca_param_files" defaults to a # value of # "$HOME/.openmpi/mca-params.conf:$sysconf/openmpi-mca-params.conf" # (this file is the latter of the two). So if the default value of # mca_param_files is not changed, this file is used to set system-wide # MCA parameters. This file can therefore be used to set system-wide # default MCA parameters for all users. Of course, users can override # these values if they want, but this file is an excellent location # for setting system-specific MCA parameters for those users who don't # know / care enough to investigate the proper values for them. # Note that this file is only applicable where it is visible (in a # filesystem sense). Specifically, MPI processes each read this file # during their startup to determine what default values for MCA # parameters should be used. mpirun does not bundle up the values in # this file from the node where it was run and send them to all nodes; # the default value decisions are effectively distributed. Hence, # these values are only applicable on nodes that "see" this file.
Bug#980709: dolfin: FTBFS: tests failed
Lucas Nussbaum wrote: Source: dolfin Version: 2019.2.0~git20200629.946dbd3+lfs-4 ... During a rebuild of all packages in sid, your package failed to build on amd64. Hi Lucas, there have been various test failures associated with the recent openmpi upgrade. They seem to be resolved now. debci now reports dolfin test success. Your test log gives an odd error message. Can you run your version of the test again to confirm if dolfin is now passing for you with the latest openmpi updates (including slepc 3.14.1+dfsg1-1+b1) ? Drew
Bug#976404: mpi4py: flaky ppc64el autopkgtest on ci.debian.net: regularly times out
Source: mpi4py Followup-For: Bug #976404 mpi4py tests seem to have started passing stably on ppc64el after the upgrade of libpmix2 from 3.2.0-1 to 3.2.1-1 (other test errors after that are other known openmpi problems, recently fixed, not these timeout errors) Tests are now passing reliably in both unstable and testing. Looks like ppc64el performance has been fixed in pmix. I think we can close this bug now.
Bug#983404: python3-scipy: scipy 1.6.1 changed API for sparse (COO) matrices
Package: python3-scipy Version: 1.6.1-1 Severity: serious Tags: upstream Justification: FTBFS Control: forwarded -1 https://github.com/scipy/scipy/issues/13585 Control: affects -1 src:pandas src:qutip scipy 1.6.1 marketed itself as "bug-fix only", but in fact introduced a change in the API handling sparse matrices with COO constructor. Reported upstream at https://github.com/scipy/scipy/issues/13585 with PR proposed at https://github.com/scipy/scipy/pull/13586 This causes pandas and qutip test to fail, so treating as FTBFS (severity serious). scipy 1.6.1 is not fit for bullseye. The signature of the problem is error messages concerning discrepancy dtyped of COO matrices e.g. * pandas (pandas.tests.arrays.sparse.test_array.TestAccessor.test_from_coo): index = pd.MultiIndex.from_arrays([[0, 0, 1, 3], [0, 2, 1, 3]]) expected = pd.Series([4, 9, 7, 5], index=index, dtype="Sparse[int]") > tm.assert_series_equal(result, expected) E AssertionError: Attributes of Series are different E E Attribute "dtype" are different E [left]: Sparse[float64, nan] E [right]: Sparse[int64, 0] /usr/lib/python3/dist-packages/pandas/tests/arrays/sparse/test_array.py:1196: AssertionError * qutip (tests.test_piqs.TestDicke.test_lindbladian): > self.data = np.array(obj, copy=copy, dtype=data_dtype) E TypeError: can't convert complex to float /usr/lib/python3/dist-packages/scipy/sparse/coo.py:161: TypeError
Bug#983404: marked as pending in python-scipy
Control: tag -1 pending Hello, Bug #983404 in python-scipy 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/scipy/-/commit/5acfe43c748bc487f497c276e875ba3413135181 mark new upstream release in changelog: fixes matrix dtypes Fixes matrix dtypes (affecting COO sparse matrices). Closes: #983404. (this message was generated automatically) -- Greetings https://bugs.debian.org/983404
Bug#972385: petsc4py: autopkgtest failure on amd64: Caught signal number 11 SEGV
Source: petsc4py Followup-For: Bug #972385 When the petsc4py tests fail, it seems to correlate with mpiexec -n 48 python3 test_mat_cg.py When the tests pass, they pass with mpiexec -n 2 python3 test_mat_cg.py Evidently the MPI tests are calling on the full number of available CPUs. The tests are not large enough to run successfully over 48 processes. In that case we should be able to resolve the problem by constraining the number of processes used with mpiexec.
Bug#972592: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#972592: fixed in mdtraj 1.9.4-6)
On 2020-10-21 18:29, Adrian Bunk wrote: On Wed, Oct 21, 2020 at 10:21:10AM +, Debian Bug Tracking System wrote: ... mdtraj (1.9.4-6) unstable; urgency=medium . * debian patch check_sse2.patch checks if system supports SSE2 (i.e. if system is x86 or amd64) before compiling with -msse2. Closes: #972592. ... Unfortunately this does not work for two reasons: 1. The i386 architecture and all buildds do support SSE2, but using it without runtime check is a baseline violation. 2. The software does use handwritten SSE, which won't compile on non-x86 architectures (the arm64 support in upstream master adds an alternative NEON implementation). I see. Would the i386 issue be the cause of the segfault in test_image_molecules? https://ci.debian.net/data/autopkgtest/testing/i386/m/mdtraj/7659912/log.gz tests/test_trajectory.py::test_smooth PASSED [ 90%] tests/test_trajectory.py::test_image_molecules bash: line 1: 4754 Segmentation fault bash -ec 'pytest-3' 2> >(tee -a /tmp/autopkgtest-lxc.1gyatnly/downtmp/command1-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.1gyatnly/downtmp/command1-stdout)
Bug#972592: mdtraj non-amd64
On 2020-10-21 20:56, Adrian Bunk wrote: On Wed, Oct 21, 2020 at 06:43:56PM +0800, Drew Parsons wrote: I see. Would the i386 issue be the cause of the segfault in test_image_molecules? https://ci.debian.net/data/autopkgtest/testing/i386/m/mdtraj/7659912/log.gz ... Doesn't look SSE related at first sight. Is anyone else using this code on 32bit? Anaconda provides a version for win-32. I can't locate other i386 builds though.
Bug#972385: 5 cpu also fails
forwarded 972385 https://gitlab.com/petsc/petsc4py/-/issues/7 thanks The problem is not as simple as the kspsolve demo being too small to distribute over 48 CPUs. The failure happens also with 5 processes.
Bug#972385: petsc4py: autopkgtest failure on amd64: Caught signal number 11 SEGV
Seems the problem is that the kspsolve demo needs the number of processors to be a power of 2. Not 5, not 48.
Bug#972246: numba, python3.9, dolfinx
On 2020-11-03 07:33, Rebecca N. Palmer wrote: As this bug cannot immediately be fixed, numba may be removed from testing to unblock the python3.9 transition (#966426). ... pandas will drop its python3-numba build/autopkgtest-dependency (#973589). Other reverse dependencies that can do so (dolfinx??) should do the same if they wish to stay in testing. Thanks Rebecca, I'll keep watch for dolfinx. Drew
Bug#973767: dolfin FTBFS: The MPI_Comm_rank() function was called before MPI_INIT was invoked.
Source: dolfin Followup-For: Bug #973767 This is a strange new error to be sure. I suspect it's related to the SLEPc upgrade, there seem to be some inconsistencies in the new slepc configuration. I'm looking into it. If it's not slepc, then it might be some new behaviour from an openmpi upgrade. But my first guess is slepc, especially since it's the eigenvalue test which is failing (SLEPc computes eigenvalues)
Bug#973767: dolfin FTBFS: The MPI_Comm_rank() function was called before MPI_INIT was invoked.
Source: dolfin Followup-For: Bug #973767 Yeah, I'm more certain SLEPc is the problem. In the new release they abolishing SLEPc.pc, renaming it slepc.pc. Since pkg-config is case-sensitive, the unexpected change is causing problems. Notice how the reported error is only with dolfin64. Because the proper SLEPc is not detected, the 64-bit build is mixing up 32-bit and 64-bit builds of PETSc and SLEPc. Resolution in progress.
Bug#980701: sasview: FTBFS: error: [Errno 2] No such file or directory: '/<>/docs/sphinx-docs/build/latex/SasView.pdf'
Package: sasview-doc Followup-For: Bug #980701 The cutting point is: > reading sources... [ 16%] dev/sasview-api/sas.qtgui.UnitTesting > qt.qpa.xcb: could not connect to display > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though > it was found. > This application failed to start because no Qt platform plugin could be > initialized. Reinstalling the application may fix this problem. > > Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, > offscreen, vnc, xcb. On my system it reports reading sources... [ 16%] dev/sasview-api/sas.qtgui.UnitTesting Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. reading sources... [ 16%] dev/sasview-api/sas.qtgui.Utilities reading sources... [ 17%] dev/sasview-api/sas.sascalc reading sources... [ 17%] dev/sasview-api/sas.sascalc.calculator Reprodicibilty tests last succeeded on 2020-12-27. Something must have changed in the environment after that, though it wasn't Qt. Probably the best solution is to figure out how to activate the "offscreen" platform plugin to build with.
Bug#981378: paraview: segfaults at startup via libvtkCommonCore-pv5.9.so
Package: paraview Version: 5.9.0-1 Severity: grave Justification: renders package unusable Thanks for packaging the new paraview release. The latest version of python-meshio should be able to run with it. paraview is segfaulting (SIGBABRT) at start up though, $ paraview Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. double free or corruption (out) Loguru caught a signal: SIGABRT gdb points the finger at libvtkCommonCore-pv5.9.so.1, or possibly via vtkCommonCore (VTK's version, not paraview's) $ gdb paraview (gdb) run Starting program: /usr/bin/paraview ... [New Thread 0x7fffb63ff700 (LWP 219883)] double free or corruption (out) Thread 1 "paraview" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x77e2a537 in __GI_abort () at abort.c:79 #2 0x77e83768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x77f91e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x77e8aa5a in malloc_printerr (str=str@entry=0x77f94210 "double free or corruption (out)") at malloc.c:5347 #4 0x77e8c088 in _int_free (av=0x77fc3b80 , p=0x5627d1a0, have_lock=) at malloc.c:4314 #5 0x75c51ee3 in () at /usr/bin/../lib/x86_64-linux-gnu/libvtkCommonCore-pv5.9.so.1 #6 0x75c5138d in vtkInformationKeyLookup::RegisterKey(vtkInformationKey*, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) () at /usr/bin/../lib/x86_64-linux-gnu/libvtkCommonCore-pv5.9.so.1 #7 0x75c50791 in vtkInformationKey::vtkInformationKey(char const*, char const*) () at /usr/bin/../lib/x86_64-linux-gnu/libvtkCommonCore-pv5.9.so.1 #8 0x75c4e38f in vtkInformationInformationVectorKey::vtkInformationInformationVectorKey(char const*, char const*) () at /usr/bin/../lib/x86_64-linux-gnu/libvtkCommonCore-pv5.9.so.1 #9 0x7fff7890108c in () at /usr/lib/python3/dist-packages/vtkmodules/../../../x86_64-linux-gnu/libvtkCommonCore-9.0.so.1 #10 0x77fe1fb2 in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffe1e8, env=env@entry=0x559fa600) at dl-init.c:72 #11 0x77fe20b9 in call_init (env=0x559fa600, argv=0x7fffe1e8, argc=1, l=) at dl-init.c:30 #12 _dl_init (main_map=0x56827fd0, argc=1, argv=0x7fffe1e8, env=0x559fa600) at dl-init.c:119 #13 0x77f3d2bd in __GI__dl_catch_exception (exception=, operate=, args=) at dl-error-skeleton.c:182 #14 0x77fe6028 in dl_open_worker (a=a@entry=0x7fff5ef0) at dl-open.c:758 #15 0x77f3d260 in __GI__dl_catch_exception (exception=0x7fff5ed0, operate=0x77fe5c70 , args=0x7fff5ef0) at dl-error-skeleton.c:208 #16 0x77fe58ca in _dl_open (file=0x7fffc6d50450 "/usr/lib/python3/dist-packages/vtkmodules/vtkCommonCore.cpython-39-x86_64-linux-gnu.so", mode=-2147483646, caller_dlopen=0x734db3e0 <_PyImport_FindSharedFuncptr+368>, nsid=-2, argc=1, argv=0x7fff5ed0, env=0x559fa600) at dl-open.c:837 #17 0x717e1258 in dlopen_doit (a=a@entry=0x7fff6110) at dlopen.c:66 #18 0x77f3d260 in __GI__dl_catch_exception (exception=exception@entry=0x7fff60b0, operate=0x717e1200 , args=0x7fff6110) at dl-error-skeleton.c:208 #19 0x77f3d31f in __GI__dl_catch_error (objname=0x556eca50, errstring=0x556eca58, mallocedp=0x556eca48, operate=, args=) at dl-error-skeleton.c:227 #20 0x717e1a65 in _dlerror_run (operate=operate@entry=0x717e1200 , args=args@entry=0x7fff6110) at dlerror.c:170 #21 0x717e12e4 in __dlopen (file=, mode=) at dlopen.c:87 #22 0x734db3e0 in _PyImport_FindSharedFuncptr (prefix=0x73618eab "PyInit", shortname=0x7fffc6d3f170 "vtkCommonCore", pathname=0x7fffc6d50450 "/usr/lib/python3/dist-packages/vtkmodules/vtkCommonCore.cpython-39-x86_64-linux-gnu.so", fp=0x0) at ../Python/dynload_shlib.c:100 #23 0x734a028a in _PyImport_LoadDynamicModuleWithSpec (fp=0x0, spec=0x7fffc6d3f970) at ../Python/importdl.c:134 #24 _imp_create_dynamic_impl (module=, file=, spec=0x7fffc6d3f970) at ../Python/import.c:2297 #25 _imp_create_dynamic (module=, args=, nargs=) at ../Python/clinic/import.c.h:330 #26 0x733e8e84 in cfunction_vectorcall_FASTCALL (func=0x7fffd759fc20, args=0x7fffc6d3f1d8, nargsf=, kwnames=) at ../Objects/methodobject.c:426 #27 0x7334b719 in do_call_core (kwdict=0x7fffc6d5a840, callargs=0x7fffc6d3f1c0, func=0x7fffd759fc20, tstate=0x55840cf0) at ../Python/ceval.c:5120 #28 _PyEval_EvalFrameDefault (tstate=, f=, throwflag=) at ../Python/ceval.c:3580 #29 0x7347bddc in _PyEval_EvalFrame (throwflag=0, f=0x7fffc6d73900, tstate=0x55840cf0) at ../Include/internal/pycore_ce
Bug#981378: paraview: segfaults at startup via libvtkCommonCore-pv5.9.so
Package: paraview Followup-For: Bug #981378 Control: reassign 981378 meshio-tools 4.3.5-2 Aha, the segfault disappears if meshio-tools is not installed. It must be related to the meshio plugin. I'll transfer this bug report to python-meshio.
Bug#981378: paraview: segfaults at startup via libvtkCommonCore-pv5.9.so
Package: meshio-tools Followup-For: Bug #981378 Control: severity -1 important Control: forwarded -1 https://gitlab.kitware.com/paraview/paraview/-/issues/20412 Probably severity grave is overegging it. paraview and meshio-tools won't necessarily be installed at the same time. paraview will work fine if meshio-tools is not installed. The meshio-tools themselves (apart from the plugin) work fine. Downgrade severity to important.
Bug#974560: marked as pending in mpi4py
Control: tag -1 pending Hello, Bug #974560 in mpi4py 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/science-team/mpi4py/-/commit/1ee01a245b7097a46da95489a5e962c3165ebfa2 extend debian patch skip_failing_test_rma.patch to openmpi <4.1 skip the affected tests for any openmpi release >=4.0.4,<4.1. Review failures again when openmpi 4.1 is released. Closes: #974560. (this message was generated automatically) -- Greetings https://bugs.debian.org/974560
Bug#972246: numba, python3.9, dolfinx
On 2020-11-16 00:07, Adrian Bunk wrote: On Mon, Nov 02, 2020 at 11:33:05PM +, Rebecca N. Palmer wrote: ... pandas will drop its python3-numba build/autopkgtest-dependency (#973589). Other reverse dependencies that can do so (dolfinx??) should do the same if they wish to stay in testing. It seems numba might get fixed in time for bullseye: https://github.com/numba/numba/issues/6345#issuecomment-721738251 Yes, they're already sitting on rc3. We might as well pull that in, in case there's unexpected delay with final release. Drew
Bug#972246: numba, python3.9, dolfinx
On 2020-11-16 01:27, Adrian Bunk wrote: On Mon, Nov 16, 2020 at 12:54:53AM +0800, Drew Parsons wrote: On 2020-11-16 00:07, Adrian Bunk wrote: > > It seems numba might get fixed in time for bullseye: > https://github.com/numba/numba/issues/6345#issuecomment-721738251 Yes, they're already sitting on rc3. We might as well pull that in, in case there's unexpected delay with final release. If I understand it correctly the rc is for 0.52.0, and 3.9 support will be in 0.52.1 Oh yeah, looks like you're right. I had assumed they were converging to the py3.9 version since the timing nearly lines up. They must be thinking to release 0.52.1 very soon after 0.52.0, if they're aiming 0.52.1 before mid-December. Drew
Bug#975092: python-meshio: autopkgtest regression on armhf and i386: KeyError: 'uint32'
Source: python-meshio Followup-For: Bug #975092 Control: forwarded -1 https://github.com/nschloe/meshio/issues/970 Already reported upstream. Can Nico's application for DD be accelerated? He'll need access to 32 bit porterboxes to get to the bottom of the bug. Drew
Bug#975470: python-meshplex: autopkgtest regression on 32 bit archs: TypeError: Cannot cast array data from dtype('int64') to dtype('int32') according to the rule 'safe'
Control: forwarded 975470 https://github.com/nschloe/meshplex/issues/90 Yeah, issue #90 already raised upstream. Drew
