Package: paraview
Followup-For: Bug #842405
p.s.
paraview does still crash when trying to read a .h5 file using an
XDMF reader. But I'll keep this bug closed all the same, since the
XDMF reader should be used to open .xdmf files, not .h5 files.
--
debian-science-maintainers mailing list
debian
Source: pyzoltan
Followup-For: Bug #1081631
Ah, correction, zoltan is not built on the 32-bit arches, so we don't
need to worry about pyzoltan and mpi4py interacting with mpich.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.deb
Source: pyzoltan
Followup-For: Bug #1081631
Control: tags -1 ftbfs
Looks like one of the two solutions at
https://github.com/mpi4py/mpi4py/issues/525#issuecomment-2256633404
is what's needed.
We'll need to see how it goes with mpich (on the 32-bit arches).
--
debian-science-maintainers mailing
Source: deal.ii
Version: 9.5.1-3
Severity: important
sundials 7 (in experimental) introduced enough API changes that
probably break deal.ii 9.5. deal.ii 9.6 has already been updated to
support sundials 7, so please update to the latest upstream release.
Note that sundials 7 moves MPI support int
Source: dyssol
Version: 1.1.1+ds1-2.1
Severity: important
Tags: ftbfs
Control: forwarded -1 https://github.com/DyssolTEC/Dyssol-open/issues/188
dyssol fails to build against sundials 7 (in experimental)
We'll want to upload sundials 7 soon to unstable (transition
#1082552), at which point this bu
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pe...@packages.debian.org, debian-scie...@lists.debian.org
Control: affects -1 + src:petsc
User: release.debian@packages.debian.org
Usertags: transition
I'd like to update the numerical library stack, for petsc and related
libraries. L
Source: scikit-learn
Version: 1.4.2+dfsg-6
Severity: normal
scikit-learn tests fail with scipy 1.14 from experimental
Perhaps it's been fixed in the latest upstream release, I don't know.
https://ci.debian.net/packages/s/scikit-learn/unstable/amd64/51759247/
648s ___ test_standard_scaler_par
The issue is known upstream, and in fact is deliberate. In that sense it is
not a bug, but may be
an issue for reverse dependencies.
The change in behaviour comes from the introduction of SUNComm in PR#370
https://github.com/LLNL/sundials/pull/370
committed at
https://github.com/LLNL/sundials/c
Package: libsundials-dev
Version: 7.1.1+dfsg1-1exp1
Severity: normal
The build for sundials 7.1.1 seems to hardcode support for MPI, placing
#define SUNDIALS_MPI_ENABLED 1
in /usr/include/sundials/sundials_config.h
This makes it more difficult than it should be to use components of
SUNDIALS in se
Source: sundials
Followup-For: Bug #1015672
This issue seems to have metastasised, such that the suggested SUSE
patch is no longer sufficient. sunlinsol is now affected, not
the nvector components
With sundials 7.1.1, optimize=+lto gets
[ 82%] Linking Fortran executable test_fsunlinsol_spbcgs_m
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: fenics-dolf...@packages.debian.org
Control: affects -1 + src:fenics-dolfinx
User: release.debian@packages.debian.org
Usertags: binnmu
nmu fenics-dolfinx_1:0.8.0-11 . ANY . unstable . -m "rebuild against mpi4py 4"
nmu dolfin_2019.2.0~le
Source: h5py
Followup-For: Bug #1080198
As far as I can read the test log, the mpich (32-bit) tests are not
actually failing. It looks like the error conditions is occuring
afterwards during shutdown. Perhaps some test files need to be
explicitly closed before shutdown.
--
debian-science-maint
reassign 1081631 src:pyzoltan
thanks
MPI_Session is defined in mpi4py.h
(/usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.h)
pyzoltan is not including it
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi
Package: python3-mpi4py
Followup-For: Bug #1081631
mpi4py is scrupulously tested. It's more likely a bug in pyzoltan.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Package: python3-mpi4py
Version: 4.0.0-2
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: forwarded -1 https://github.com/mpi4py/mpi4py/issues/545
mpi4py 4 was building fine in experimental but shows tests error in
unstable:
testTestAll (test_util_pkl5.TestPKL5World.testTestAll) ... ok
Source: statsmodels
Version: 0.14.2+dfsg-1
Severity: normal
Control: forwarded -1 https://github.com/statsmodels/statsmodels/issues/7866
statsmodels is failing tests on arm64 with scipy 1.14 (from
experimental)
1504s __ TestZeroInflatedModel_probit.test_fit_regularized
__
Source: python-fluids
Version: 1.0.22-2
Severity: normal
python-fluids is failing tests with scipy 1.14 (from experimental)
due to a change in API.
The problem is fixed in the latest upstream release.
The error looks like
84s __ test_integrate_drag_sphere
Source: python-ltfatpy
Version: 1.0.16-10
Severity: normal
python-ltfatpy is failing tests with scipy 1.14 (from experimental)
94s _ TestGabWin.test_str_entries
__
94s
94s self =
94s
94s def test_str_entries(self):
94s a = ran
Source: petsc
Version: 3.21.4+dfsg1-1exp1
Severity: normal
Control: forwarded -1 https://gitlab.com/petsc/petsc/-/issues/1634
petsc 3.21 is failing to successfully run build-time tests
(with build dir identified by PETSC_ARCH at build time).
The check_build rule invokes testex19 in src/snes/tutor
Source: petsc
Version: 3.20.6+dfsg1-1
Followup-For: Bug #1075380
petsc still fails this way with scotch 7.0.5 (which has fixed scotch's
own gcc-14 problem).
The issue is that petsc is configured to use default scotch (integer
not specified, meaning int). But the petsc64 build gets PetscInt
defin
Source: scikit-learn
Version: 1.4.2+dfsg-5
Severity: normal
Control: forwarded -1 https://github.com/scikit-learn/scikit-learn/issues/29633
scipy 1.13 is triggering test failure in
test_svc_ovr_tie_breaking[NuSVC] on i386 architecture.
The error can be seeing in debian CI tests,
https://ci.debia
Source: petsc
Followup-For: Bug #1075380
Control: block 1075380 by 1075495
The error refers to scotch.
I'm working through the scotch gcc-14 error first.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/
Source: openmpi
Version: 4.1.6-13.3
Severity: normal
libopenmpi3t64 4.1.6-13.3 Depends on libucx0 for ppc64el,
but ucx 1.17.0+ds-2 dropped ppc64el as a supported arch.
Does openmpi 4.1.6 need to be reconfigured to build on ppc64el without
UCX, or does it only need a binNMU?
--
debian-science-m
Source: slepc
Followup-For: Bug #1076130
Control: block 1076130 by 1076579
As far as I can tell this test failure simply got caught in the mpi
transition (mpich on 32-bit).
Nothing seems to be blocking mpi migration to testing apart from ucx
being removed from ppc64el (see Bug#1076579).
I thin
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: u...@packages.debian.org
Control: affects -1 + src:ucx
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 src:mpich
ucx 1.17.0+ds-2 has temporarily dropped ppc64el as a supported arch to
allow it to proceed.
But the
Source: dijitso
Followup-For: Bug #1076466
32-bit (mpich) tests are passing in unstable.
I guess this bug is caught in the middle of the mpi transition.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/l
Subject: Re: lammps: FTBFS with mpich as default MPI provider on armel, armhf:
Fatal error in internal_Comm_set_errhandler: Invalid communicator
Followup-For: Bug #1076234
Package: lammps
Control: tags -1 ftbfs
This looks like a bug in libfakeroot rather than lammps.
--
debian-science-maintaine
Source: h5py
Followup-For: Bug #1076028
Control: tags -1 ftbfs
Control: blocks 1076028 by 1075980
I'm not certain this is a bug in h5py. More likely the problem is
mpi4py, Bug#1075980.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-l
Source: pyswarms
Version: 1.3.0-6
Severity: normal
pyswarms is failing tests with matplotlib 3.8 from experimental:
57s ERROR collecting tests/utils/plotters/test_plotters.py
57s ImportError while importing test module
'/tmp/autopkgtest-lxc.ljy3li2v/downtmp/autopkgte
Source: pytorch-geometric
Version: 2.4.0-2
Severity: important
Control: affects -1 src:scipy
pytorch-geometric is failing tests with scipy 1.13 from experimental,
evidently due to use of a deprecated API.
The error message is
187s test/distributed/test_rpc.py On WorkerInfo(id=0, name=dist-featur
Source: gensim
Version: 4.3.2+dfsg-1
Severity: important
Control: affects -1 src:scipy
gensim is failing to start tests using scipy 1.13 from experimental,
apparently due to use of a decprecated API.
Error is
278s ___ ERROR collecting gensim/test/test_aggregation.py
___
On 2024-06-11 16:53, Timo Röhling wrote:
Hi,
I gave it a bit of thought and tightened the dependency from
python3-nanobind on nanobind-dev, so both packages will be installed
with the same version. I also added a pydist override so that
python3-nanobind will automatically emit a versioned dep
Package: paraview
Version: 5.12.0+dfsg-4
Severity: important
Control: forwarded -1 https://gitlab.kitware.com/vtk/vtk/-/issues/19352
paraview FTBFS on armel with
bin/vtkWrapPython-pv5.12 -MF
/<>/build.python3.12/CMakeFiles/vtkRemotingServerManagerPython/vtkSMDataSourceProxyPython.cxx.d
@/<>/
I meant to add, the testClickOnBackToParentTool failure was on ppc64el.
--
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: silx
Version: 2.0.1+dfsg-3
Severity: serious
Justification: debci
Control: affects -1 src:scipy
silx has started failing debci tests.
This is blocking migration of scipy 1.12 to testing
(though in principle scipy shouldn't be causing the problem, since
tests passed recently against the ve
On 2024-05-31 14:04, Santiago Vila wrote:
El 31/5/24 a las 13:21, Drew Parsons escribió:
Source: adios4dolfinx
Followup-For: Bug #1071722
Santiago, could you try running with
export OMPI_MCA_rmaps_base_oversubscribe=true
added to the top of debian/rules?
That seems to work.
And also it
Source: adios4dolfinx
Followup-For: Bug #1071722
Santiago, could you try running with
export OMPI_MCA_rmaps_base_oversubscribe=true
added to the top of debian/rules?
I think that will get it working on your test system.
I think the problem is that openmpi does not use hwthreads or
oversubscrib
Source: adios4dolfinx
Followup-For: Bug #1071722
Control: severity 1071722 important
This bug appears to arise from how openmpi needs to be invoked on a
specific system. It doesn't affect all systems, and doesn't affect
debian buildds or debci, so downgrading severity.
--
debian-science-maintai
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 socke
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
https
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
paravie
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
https://ci.debian.net/packages/p/paraview/unsta
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
debian-science-maintainers@alioth-lists.d
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. Perha
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)
python3-paravie
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
debian-science-maintainers@alio
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
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
debian-science-maintainers@aliot
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 (test_io.TestIOSelf.testI
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
debian-science-maintain
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
`cmfabric_add_static_tran
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
h
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
debian-science-maintainers@alio
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
https
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 m
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 petsc
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
--
debian-science-ma
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
https://alioth-li
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]
648s
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, ups
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 time
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), m
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 l
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
li
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 ups
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 resolut
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?
--
debian-science-mai
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 inst
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"
( 0.
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
debian-science-maintainers@alioth-li
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
debian-science-
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}, dtype=)
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 (test_p2p_obj_matched.TestP2PMatched
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 py
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
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
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
https://a
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 new
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 c
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: 'li
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/
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 tag
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 th
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 maili
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
http
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.
--
deb
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, https://github.com/mlpack/
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,
https://salsa.debian.org/science-team/paraview/-/tr
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, xte
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 a
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:
https://ci.debian.net/data/autopkgtest/testin
1 - 100 of 555 matches
Mail list logo
