On 2024-05-26 12:44, Santiago Vila wrote:
To track that, what does `lscpu` report on your failing system?
(the thread,core,socket lines are probably the relevant ones)
It's an AWS machine of type m6a.large. These are the most relevant
specs.
Thread(s) per core: 2
Core(s) per
On 2024-05-25 18:31, Santiago Vila wrote:
El 25/5/24 a las 16:42, Drew Parsons escribió:
adios4dolfinx is building cleanly in reproducibility builds.
Perhaps the problem was a temporary glitch on your test system?
No, this is unlikely to be a temporary glitch:
...
My system has 2 CPUs
Control: retitle 1061243 needs update for xsimd 13
Now xsimd 13 is available.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Source: adios4dolfinx
Followup-For: Bug #1071722
Control: tags -1 ftbfs
adios4dolfinx is building cleanly in reproducibility builds.
Perhaps the problem was a temporary glitch on your test system?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: paraview
Version: 5.12.0+dfsg-4
Severity: important
Tags: ftbfs
paraview 5.12 has started failing to build on i386.
paraview 5.11 previously built on i386.
The problem appears to be an implicit conversion from
‘long unsigned int*’ to ‘const int*’ in getArrayType in XdmfArray.cpp
Package: paraview
Version: 5.11.2+dfsg-7
Severity: important
Control: forwarded -1
https://gitlab.kitware.com/paraview/paraview/-/issues/22620
The Debian build of paraview (5.11.2) fails CI tests on the s390x architecture.
Test logs can be found at
Package: paraview
Followup-For: Bug #900364
Control: tags 900364 moreinfo
Fractional scaling seems to be working now, at least for eDP-1 > 1.
Can you confirm if the problem is fixed in paraview 5.11.2 or later?
--
debian-science-maintainers mailing list
Package: paraview
Followup-For: Bug #842405
Control: tags 842405 moreinfo
HDF5 is a general data format, it has no natural viewing format.
When you load a file into paraview you need to specify which reader
you want to open it with. Which reader are you expecting to use with
your .h5 file?
Your
Package: paraview
Followup-For: Bug #820453
"Help -> ParaView Guide" now (5.11.2) provides a (functioning) url
link to https://docs.paraview.org/en/v5.11.2/
which opens normally in the web browser.
Not so helpful if you don't have internet access, but at least it's
not giving an error now.
Package: paraview
Version: 5.11.2+dfsg-6+b9
Followup-For: Bug #982601
X-Debbugs-Cc: Petter Reinholdtsen
Petter, paraview might never be aligned with vtk.
See https://gitlab.kitware.com/paraview/paraview/-/issues/18751
If facet-analyser needs to be able to work with either (both)
Source: slepc
Followup-For: Bug #1070894
Control: tags -1 ftbfs fixed-upstream
Control: forwarded -1 https://gitlab.com/slepc/slepc/-/issues/83
Fixed upstream in 3.20.2,
https://gitlab.com/slepc/slepc/-/merge_requests/639
--
debian-science-maintainers mailing list
Source: hypre
Followup-For: Bug #1069321
It's passing in reproducibility rebuilds.
Perhaps it was a transitory glitch.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: hypre
Followup-For: Bug #1069321
Control: tags -1 ftbfs
hypre is passing debci and reproducibility tests on armhf.
Looks like the error reported here was a transitory issue,
possibly related to openmpi upgrades.
--
debian-science-maintainers mailing list
Source: mpi4py
Followup-For: Bug #1066449
Control: tags -1 ftbfs
The bug report stopped scanning at the first "error", which is not an
error (it's a check). The last error is the relevant one
testIReadIWrite (test_io.TestIOSelf.testIReadIWrite) ... ok
testIReadIWriteAll
Source: mpi4py
Followup-For: Bug #1069432
There have been ongoing issues with OpenMPI on 32-bit architectures,
partly related to drop of 32-bit support by pmix.
This bug is likely related to that i.e. not a bug in mpi4py itself.
--
debian-science-maintainers mailing list
Source: adios2
Version: 2.10.0+dfsg1-1
Severity: normal
Tags: ftbfs
Control: forwarded -1 https://github.com/ornladios/ADIOS2/issues/4156
Building the debian package for adios 2.10.0 (in experimental) fails with
"libadios2_serial_evpath.so.2.10.0: undefined reference to
Source: dolfin
Followup-For: Bug #1062405
Control: severity 1062405 testing
Control: tags 1062405 moreinfo
This time_t patch was never applied. Is it not needed after all?
Can we close this bug now?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: fenics-dolfinx
Followup-For: Bug #1062587
Control: severity 1062587 important
Control: tags 1062587 moreinfo
This time_t patch was never applied. I presume it's not needed after
all and we can close this bug now?
--
debian-science-maintainers mailing list
Source: armci-mpi
Followup-For: Bug #1068319
armci-mpi is already building for mpich so the transition should be
manageable. Will just need to make sure it switches off the openmpi
build cleanly.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: deal.ii
Version: 9.5.1-2
Severity: normal
Tags: ftbfs
I'm getting an error running deal.ii tests building against petsc 3.20
(from experimental)
[100%] Built target dealii_release
make -f tests/CMakeFiles/test.dir/build.make tests/CMakeFiles/test.dir/depend
make[5]: Entering directory
Source: python-meshplex
Followup-For: Bug #1067308
Control: tags -1 ftbfs
I can't reproduce this error now. It must have been resolved by a
separate library transition, or possibly a numpy update.
If 0.17.1-3 passes tests successfully then we can close this bug.
--
debian-science-maintainers
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pe...@packages.debian.org, francesco.balla...@unicatt.it
Control: affects -1 + src:petsc
User: release.debian@packages.debian.org
Usertags: transition
The petsc patch for the 64-bit time_t transition was deeply invasive.
It makes
Source: petsc
Followup-For: Bug #1065323
petsc has a complex set of symlink farms since it needs to enable
multiple alternative build profiles.
I'll implement the patch in a way that doesn't let t64 get in the way
of updating subsequently (to 3.20 in the near future).
Drew
--
On 2024-02-24 12:40, Francesco Poli wrote:
On Thu, 04 Jan 2024 12:18:21 +0100 Drew Parsons
Can you confirm paraview 5.11 is meeting your image quality
expectations?
Only if I disable FXAA (which, by the way, is enabled by default, but
can luckily be disabled in the settings!).
...
Could
Source: scikit-learn
Version: 1.4.1.post1+dfsg-1
Severity: normal
sklearn 1.4 is passing most tests but two remain "failing" on armhf.
test_tfidf_no_smoothing and test_qda_regularization are "expected to
fail" by emitting a divide-by-zero warning, but they emit no such
exception.
I guess it's a
Source: scikit-learn
Version: 1.2.1+dfsg-1
Followup-For: Bug #1029701
Control: severity 1029701 serious
scipy 1.11 is now uploaded to unstable,
so bumping this bug severity to serious.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: scikit-learn
Version: 1.2.1+dfsg-1
Followup-For: Bug #1029701
scikit-learn continues to fail with scipy 1.11 from experimental
648s FAILED
../../../../usr/lib/python3/dist-packages/sklearn/linear_model/tests/test_quantile.py::test_incompatible_solver_for_sparse_input[interior-point]
Source: adios2
Followup-For: Bug #1062356
The flakey test is adios2-mpi-examples. debian/tests is building and
running them manually, and running on only 3 processors (mpirun -n 3)
So the problem can't be overload of the machine.
I'll just skip insituGlobalArraysReaderNxN_mpi.
For reference,
Source: adios2
Followup-For: Bug #1062356
Can't be quite as simple as just the host machine.
https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41403641/log.gz
completed in 9 minutes,
while
https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41496866/log.gz
failed with
Package: libxtensor-dev
Followup-For: Bug #1061386
Control: fixed 1061386 0.24.7-1
I'm a bit confused why you're installing libxtensor-dev:arm64 on
amd64. Wouldn't it make more sense to install libxtensor-dev:amd64?
In any case this was fixed in libxtensor-dev 0.24.7 (actually in
0.24.4-1exp1),
Package: python3-spglib
Version: 2.2.0-2
Severity: normal
We have dh_python3 to help automatically identify python package
dependencies when building a package.
It's unable to identify spglib, however. For instance a pymatgen build
log shows
dh_python3 -a -O--buildsystem=pybuild
I: dh_python3
On 2024-01-22 09:28, Andrius Merkys wrote:
Hi Drew,
spglib should be configured to build for all available python
versions.
In other libraries (e.g. fenics-basix) this is done by building the C
library separately from the the python module.
Thanks for a pointer, I will give fenics-basix a
Package: python3-spglib
Version: 2.2.0-2
Severity: normal
python3-spglib fails with python3.12, since the python extension is
built only for python3.11.
spglib should be configured to build for all available python versions.
In other libraries (e.g. fenics-basix) this is done by building the C
Package: libxtensor-dev
Version: 0.24.7-4
Severity: important
Tags: upstream
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2769
xtensor 0.24.7 is configured to use xsimd 10. xtensor upstream head
supports xsimd 11. But xsimd 12 has been recently released and is
required to
Source: h5py
Followup-For: Bug #1061063
Control: forwarded 1061063 https://github.com/h5py/h5py/issues/1927
The problem was raised upstream at
https://github.com/h5py/h5py/issues/1927
Makes it difficult to test if we can't reproduce it on all armhf
environments.
A patch was suggested for the
Package: paraview
Followup-For: Bug #837796
Control: fixed -1 5.11.0+dfsg-1
I think this problem is now dealt with (paraview 5.11).
The query-based selection is not segfaulting now. The values are
found as described in the tutorial, and the 3D can image gets
highlighting indicated the selection
Package: paraview
Followup-For: Bug #894462
The png generated by the procedure in this bug looks fine to me, using
current paraview (5.11). It's slightly blurry but no more than you'd
expect for a png file (it's raster image format, not a vector image
format, you can't expect to main high
Package: paraview
Followup-For: Bug #754968
find_package(ParaView) is now operating successfully in cmake.
(needs libgdal-dev)
That's with paraview-dev 5.11.2+dfsg-4 and cmake 3.28.1-1.
Can you confirm paraview is now working for you from cmake, and we can
close this bug?
--
Package: paraview
Followup-For: Bug #959677
The calculator seems to be working fine
e.g. tutorial steps at
https://docs.paraview.org/en/latest/UsersGuide/filteringData.html#python-calculator
change the colour of the sphere depending on the value entered in the
calculator.
Can you confirm you
Package: paraview
Followup-For: Bug #753685
I suspect the problem with ColorMaps is fixed in paraview 5.11 but
can't confirm since paraview.simple has other issues. It wants to use
inspect.getargspec, but there's no such function anymore (python 3.11).
$ python3 -c "import paraview.simple"
(
Package: paraview
Followup-For: Bug #688875
I can't see a "Current Time Controls" toolbar in paraview 5.11.
Is it the "Time Inspector" tool bar?
Are your requirements now met in paraview 5.11?
Can we close this bug?
--
debian-science-maintainers mailing list
Package: paraview
Followup-For: Bug #954329
I can't see a problem with the test file using latest paraview 5.11.
It displays a translucent sphere coloured red on one side, blue on the
other.
Can you confirm this bug has now been fixed?
--
debian-science-maintainers mailing list
Package: python3-hdf5plugin
Version: 4.0.1-3
Severity: serious
Justification: FTBFS
python3-hdf5plugin has started failing testZfp,
causing both FTBFS and debci failure.
The error message from debci is
56s ERROR: testZfp (__main__.TestHDF5PluginRW.testZfp) (options={'lossless':
False},
Package: python3-mpi4py
Version: 3.1.5-2
Severity: normal
Control: forwarded -1 https://github.com/mpi4py/mpi4py/issues/147
sparc64 has started giving a Bus Error (Invalid address alignment) in
testPackUnpackExternal (test_pack.TestPackExternal),
testProbeRecv
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pe...@packages.debian.org
Control: affects -1 + src:petsc
I'd like to upgrade PETSc (and SLEPc, and their python packages)
from 3.18 to 3.19. This is expected to fix the
Source: slepc4py
Followup-For: Bug #1057863
Correction: curexc_traceback is not used in slepc4py 3.19.
Maybe it's time to upgrade to PETSc 3.19.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: slepc4py
Followup-For: Bug #1057863
slepc4py does not use curexc_traceback.
Perhaps this is a bug in cython?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Source: adios2
Followup-For: Bug #1058353
Damn, something went badly wrong in debian/rules. Sorry about that.
I'll fix it as soon as possible, in the meantime use the version in
testing.
Drew
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: adios2
Followup-For: Bug #1058018
Control: severity -1 important
Call it teething issues. This is a new package, so I'm trying to avoid
making debian/control more verbose than it needs to be by not crowding
the fields with the strict specifications needed to avoid this error.
Once the
On 2023-12-10 21:55, Kingsley G. Morse Jr. wrote:
Hi Rebecca, Julian and all science minded pythonistas of debian, great
and small!
3.) The following one-liner suggests 44 debian
packages might be affected by the breaks
Rebecca said would be caused by pandas 2.x:
$ for s in augur
On 2023-12-06 08:29, Jochen Sprickerhof wrote:
Hi Drew,
* Drew Parsons [2023-12-05 10:10]:
On 2023-12-05 05:18, Bastian Blank wrote:
On Mon, Dec 04, 2023 at 11:27:53PM +0100, Drew Parsons wrote:
On 2023-12-04 23:24, Debian FTP Masters wrote:
paraview source: lintian output: 'license
On 2023-12-05 05:18, Bastian Blank wrote:
On Mon, Dec 04, 2023 at 11:27:53PM +0100, Drew Parsons wrote:
On 2023-12-04 23:24, Debian FTP Masters wrote:
> paraview source: lintian output: 'license-problem-json-evil
>
VTK/ThirdParty/fides/vtkfides/thirdparty/rapidjson/fidesrapidjson/licen
On 2023-12-04 23:24, Debian FTP Masters wrote:
paraview source: lintian output: 'license-problem-json-evil
VTK/ThirdParty/fides/vtkfides/thirdparty/rapidjson/fidesrapidjson/license.txt',
automatically rejected package.
paraview source: If you have a good reason, you may override this
lintian
On 2023-11-13 22:31, Kurt Kremitzki wrote:
Hello Drew,
...
Debian builds were only succeeding on amd64 but failing on all the
other architectures: i386, armel, armhf, arm64, mipsel, mips64el,
ppc64el, and s390x.
I was able to fix some of the problems by switching to an older
version (thus
Package: netgen
Followup-For: Bug #1016430
I've prepared netgen 6.2.2305 in experimental. I guess we might as
well close this bug when it gets uploaded to unstable.
Still, I'd also be interested to hear what the motivation was for the
+really6.2.1905 version.
--
debian-science-maintainers
Package: python3-netgen
Version: 6.2.2006+really6.2.1905+dfsg-10
Followup-For: Bug #910247
As a workaround, initialise MPI before importing netgen.gui.
> from mpi4py import MPI
> import netgen.gui
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: ensmallen
Followup-For: Bug #1054712
Should be noted that the problem is linked to debian patch
0002-use-system-catch.patch, which disables upstream's local copy of
catch in order to use the system catch2 library.
So one workaround could be to disable 0002-use-system-catch.patch.
--
Source: ensmallen
Followup-For: Bug #1054712
Control: forwarded 1054712 https://github.com/mlpack/ensmallen/issues/372
This error occurs because of the upgrade of catch2 from v2 to v3.
Unfortunately ensmallen upstream don't sound very enthusiastic about
dealing with it,
Package: paraview
Version: 5.11.0+dfsg-2
Severity: normal
paraview offers a GMSH plugin, providing the capability to visualise
gmsh meshes. It's not built by default, can it be added to the debian
paraview package?
Actually there's two of them,
Source: xtensor
Version: 0.24.7-4
Followup-For: Bug #1053090
Control: severity 1053090 important
xsimd support is optional for xtensor.
Use of batch is apparently not expected to be routinely used
anyway. See further discussion at
https://github.com/xtensor-stack/xsimd/issues/945
In summary,
Source: xsimd
Version: 10.0.0-3
Severity: important
Control: forwarded -1 https://github.com/xtensor-stack/xsimd/issues/954
Control: affects -1 libxtensor-dev
xtensor 0.24.7 tests are exposing an error in xsimd 10.0.0 on less
common architectures armel, ppc64el and s390x, seen in debian CI tests
On 2023-10-10 09:26, Rafael Laboissière wrote:
* Rafael Laboissière [2023-10-09 08:30]:
[…] At least, I hope that version 3.1.0+dfsg2-5 will really fix
Bug#1053314 and the h5py transition will be completed.
Unfortunately, it is still not working:
On 2023-10-09 08:30, Rafael Laboissière wrote:
Thanks for this detailed explanation, Drew. I released version
3.1.0+dfsg2-5 of the xmds2 package before reading it. I added
python3-h5py to Build-Depends and libhdf5-mpi-dev to Depends, as you
suggested (even though there is a typo in the
Nilesh explained most of the situation correctly. I can give some more
background.It made sense (to me) to have h5py built against
hdf5-mpi, since I figured that if you need the complexity of the hdf5
file format then you probably want to use it in an MPI environment.
There was a
Package: libxsimd-dev
Followup-For: Bug #1053090
Control: reassign 1053090 libxtensor-dev
Control: forwarded 1053090 https://github.com/xtensor-stack/xtensor/issues/2733
xsimd upstream https://github.com/xtensor-stack/xsimd/issues/945
identified the problem that neon64 does not support bool.
A
forwarded 1053341 https://github.com/h5py/h5py/issues/2315
thanks
I suspect it can be resolved by casting the int returned by addressof to
ctypes.c_int. Waiting to hear what upstream thinks.
Note it's not quite as simple as "32-bit". sparc64 is also affected.
--
debian-science-maintainers
Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci
xmds2 Depends: python3-h5py-mpi without depending on python3-h5py
python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace,
not h5py. Hence tests using h5py without specifying _debian_h5py_mpi
fail. This is
On 2023-09-29 09:28, Stuart Prescott wrote:
Control: reopen -1
...
I can't see the fixed files for this dist-info metadata in the updated
package:
...
BTW a simple test that it is all working is:
python3 -c "from importlib.metadata import distribution;
distribution('h5py')"
For what
Source: petsc
Followup-For: Bug #1049903
Control: severity 1049903 important
Control: tags 1049903 moreinfo
I said previously I'd apply the patch, but I wanted to check the
problem first. No problem is showing at
https://tests.reproducible-builds.org/debian/rb-pkg/petsc.html
even in the
Source: h5py
Followup-For: Bug #1051781
I'm reorganising the package with separate distinfo metadata for the
different variants. I think this will fix your problem
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: mpi4py
Followup-For: Bug #1052748
Control: severity 1052748 important
Control: tags 1052748 moreinfo
I can't reproduce this error, and debci tests at
https://ci.debian.net/packages/m/mpi4py/ continue to pass
So I'm downgrading severity.
I figure there are two possibilities
- it was a
Source: mpi4py
Followup-For: Bug #1052748
Control: retitle 1052748 mpi4py fails test_dynproc.TestDPM.testJoin:
socket.gaierror: [Errno -2] Name or service not known
The failure was incorrectly identified. The build log says the problem
was in testJoin:
ERROR: testJoin
Source: xtensor
Version: 0.24.7-1
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2729
xtensor 0.24.7-1 fails debci test on armel (gnueabi) architecture with clang
16.0.6.
The tests pass with g++ 13.2.0, and pass with clang-16 on other architectures.
A test
Source: xtensor
Followup-For: Bug #1052882
Control: fixed 1052882 0.24.7-1
This bug is weird, in the sense that xtensor 0.24.3-2 in testing
failed its test against xsimd 10.0.0-3 from unstable.
So why then did the migration daemon allow xsimd to migrate from
unstable to testing?
--
Package: libxsimd-dev
Version: 10.0.0-3
Severity: serious
Justification: debci
libxsimd-dev 10 triggers an error in xtensor tests on arm64
xsimd passes its own tests, and xtensor passes on other arches (except
armel which has known issues)
The error output from
Source: petsc
Followup-For: Bug #1049903
Thanks for the clarification. I'll apply the patch.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Hi Tim, I'm not sure if the Debian Bug Tracking System forwarded
messages to you from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041480
Does it fix your package configuration if you specify Depends:
python3-h5py in your debian/control file?
Drew
--
debian-science-maintainers
Source: petsc
Followup-For: Bug #1049903
Hi Steve, thanks for the bug report.
With patching, wouldn't it be simpler to just add -lstdc++ to
CXX_LINKER_FLAGS at configuration time (in debian/rules) rather than
hacking the upstream detection code? As you say, hardcoding in the
upstream scripts
Source: mshr
Followup-For: Bug #1043307
[reportbug has not been able to send emails.
testing configuration here. Please ignore]
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: mshr
Followup-For: Bug #1043307
[testing reportbug. please ignore]
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Source: superlu
Followup-For: Bug #1043313
Upstream has just released a new version to fix it.
Apparently it introduced other problems however.
Let's see what upstream's response to that is.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: xtensor
Followup-For: Bug #1042560
Control: forwarded 1042560
https://github.com/xtensor-stack/xtensor/issues/2718#issuecomment-1664157116
Something weird going on here. This is a string comparison not a
floating point comparison. The string is supposed to be the type of
the values, so
Package: python3-h5py
Followup-For: Bug #1041480
If your package does not specifically need the serial or mpi version,
then you should just use the common package python3-h5py rather than
python3-h5py-serial
Depends: python3-h5py
Does that fix your configuration?
--
debian-science-maintainers
Package: python3-h5py
Followup-For: Bug #1040107
Control: severity 1040107 normal
Control: forwarded 1040107 https://github.com/h5py/h5py/issues/2292
asyncore is only used in the example file swmr_inotify_example.py,
so this bug is not really Severity: important
--
debian-science-maintainers
Source: fenics-dolfinx
Followup-For: Bug #1042003
Control: tags 1042003 fixed-upstream
The issue with PETSc 3.19 has been dealt with upstream by a complete
overhaul of the Mesh python wrappers in PR#2611.
The patch does not apply cleanly to dolfinx 0.6.0. A large chunk of
the patches introduces
forwarded 1041372 https://github.com/xtensor-stack/xtensor/issues/2718
thanks
Evidently triggered by excess precision changes in gcc-13,
see https://gcc.gnu.org/gcc-13/porting_to.html
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: mu...@packages.debian.org, debian-scie...@lists.debian.org
Control: affects -1 + src:mumps
I'd like clear out some transitions in the numerical library stack:
combblas:
Package: python3-dolfinx
Version: 1:0.6.0-6
Severity: normal
Control: forwarded -1 https://github.com/FEniCS/dolfinx/issues/2736
The python unit test python/test/unit/fem/test_vector_function.py
fails after building dolfinx 0.6.0 against PETSc 3.19
$ pytest-3 -v
Package: python3-dolfin
Version: 2019.2.0~legacy20230609.8b85e9d.ar-3
Severity: normal
Control: forwarded -1 https://bitbucket.org/fenics-project/dolfin/issues/1138/
Building dolfin against PETSc 3.19 passes all tests except one, from
python/test/unit/nls/test_PETScSNES_solver.py:
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
Package: libopenblas64-pthread-dev
Version: 0.3.23+ds-2
Severity: important
I'm trying to build hypre 2.29.0. It uses lapack+blas, configuring
via pkg-config to get the appropriate -llapack -lblas flags. The
debian hypre package builds both 32 bit and 64 bit variants of
libhypre.so.
On my
Package: python3-mpi4py-fft
Version: 2.0.5-1
Followup-For: Bug #1035186
Tests are currently failing inside openmpi libraries. Not sure if it
means hdf5 needs to be rebuilt against latest openmpi.
Tests should be launched from the tests subdir with
H5PY_ALWAYS_USE_MPI=1 ./runtests.sh
--
libscotchmetisv5.so
+(v5 not v3, to match libmetis), and point libparmetis.so at the
+corresponding int-build of libptscotchparmetisv3.so. Likewise for
+static .a libraries. Closes: #1036576.
+
+ -- Drew Parsons Tue, 23 May 2023 17:23:49 +0200
+
scotch (7.0.3-1) unstable; urgency=medium
Package: libscotchmetis-dev
Version: 7.0.3-1
Followup-For: Bug #1036576
Awkward. Thanks for catching it.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Source: lmfit-py
Version: 1.1.0-1
Severity: normal
lmfit-py 1.1.0-1 introduced debian patch preserve_version.patch to
prevent the python package build from introducing a spurious package
version.
If I correctly understand the way pybuild-plugin-pyproject interacts
with setuptools_scm,
reassign 1023820 src:hdf5
retitle 1023820 hdf5: Dependencies not tight enough
affects 1023820 python3-h5py
thanks
Bug#1023820 reported a failure in h5py:
import h5py
...
ImportError: /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103: version
`HDF5_SERIAL_1.10.7' not found (required by
3.1~beta-7) unstable; urgency=medium
+
+ * Team upload.
+ * run build-time tests on only 1 process if only 1 CPU is available.
+Closes: #1031064.
+ * debian/tests: don't run mpich tests on s390x. Closes: #1009772.
+
+ -- Drew Parsons Sun, 19 Mar 2023 14:08:54 +0100
+
armci-mpi (0.3.1~beta-
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
On 2023-02-07 08:33, Graham Inggs wrote:
Hi Drew
I think python3-scipy should declare a Breaks on python3-skbio less
than the version in unstable (0.5.8-3).
This should sort out the autopkgtest regressions of emperor,
python-skbio itself, q2-metadata and q2-quality-control, which are all
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
1 - 100 of 507 matches
Mail list logo
