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: 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: 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: 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: 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: 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: 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: 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
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
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
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 #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
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
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
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
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
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
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
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
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
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: 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
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
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
@/<>/
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
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
___
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: 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: 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
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: 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
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: 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
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: 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: 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
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: 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: 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: 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: 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
__
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
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
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
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
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 #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: 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
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
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
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
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
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
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: 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: 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.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
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: 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
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: 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
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: 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: sundials
Version: 5.8.0+dfsg-1
Severity: serious
Justification: FTBFS
Control: affects -1 libhypre-dev libpetsc-real3.18-dev
Testing the build of sundials against Hypre 2.6 and PETSc 3.18, both
available now in experimental, nvector/parhyp fails with the error
message:
[ 55%] Linking C ex
Source: sundials
Followup-For: Bug #1023457
Control: forwarded -1 https://gitlab.com/petsc/petsc/-/issues/1277
PETSc upstream confirms the bug is indeed in sundials,
see https://gitlab.com/petsc/petsc/-/issues/1277
"This should be fixed in latest sundials (6.4.0/6.4.1)
For 5.8.0 - the fix would
Package: python3-h5py
Followup-For: Bug #1023820
This would seem to be a bug in hdf5, not h5py. The shlibs
configuration for libhdf5-serial-dev does not seem to be adding the
version for libhdf5-103-1 (see python3-h5py-serial), while
libhdf5-openmpi-dev does add the version for libhdf5-openmpi-10
severity 1023788 important
thanks
The problem is hidden in 5.4.2+dfsg1-2 by simply skipping tests on
s390x.
This will enable getfem 5.4 to migrate to testing, so downgrading
severity. But leaving the bug open since the problematic behaviour still
needs to be fixed.
Drew
--
debian-science-
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
Source: xsimd
Version: 8.1.0-7
Severity: normal
Upstream has now released xsimd 10.0.0.
Pythran developers report that xsimd 10 fixes some problems managing
functions for both scalar and vector calculations.
Could a package of the new version be made?
I recommend uploading to experimental first
Package: libxtensor-dev
Version: 0.24.3-1
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2625
xtensor currently requires xsimd 8.
But xsimd 10 is already released.
This bug tracks updating xtensor to xsimd 10.
--
debian-science-maintainers mailing list
de
Source: python-dmsh
Followup-For: Bug #1027230
I can't reproduce this error. debci tests are passing fine on all
architectures.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-m
Package: vtk9
Version: 9.1.0+really9.1.0+dfsg2-4+b3
Severity: normal
Control: affects -1 src:vedo
vtk9 has a IO/GeoJSON module, but it's not built by default.
Is it possible to add it to the build?
The reason is that vedo provides geojson support via vtk's python
module vtkmodules.vtkIOGeoJSON.
Source: xsimd
Version: 10.0.0-1
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xsimd/issues/889
The build of xsimd 10.0.0-1 fails on armhf due to test failure:
test_xsimd: ./include/xsimd/types/xsimd_batch.hpp:567: void xsimd::batch::store_aligned(U*) const [with U = unsi
Source: xsimd
Followup-For: Bug #1029568
The source of the armhf test error is actually the -mfpu=neon added
explicitly in debian/rules to DEB_CXXFLAGS_MAINT_APPEND on armhf.
Remove this flag, then armhf tests pass.
As far as other arches go, in general they should pass tests now (running
scalar
Package: python-bumps
Version: 0.9.0-2
Severity: normal
scipy 1.10 is now available in experimental.
bumps fails debci tests using it.
We are considering uploading scipy 1.10 to unstable in order to
included it in the forthcoming stable release. If we proceed with
that, then this bug will become
Package: python-pweave
Version: 0.25-4
Severity: normal
scipy 1.10 is now available in experimental.
python-pweave fails debci tests using it.
We are considering uploading scipy 1.10 to unstable in order to
included it in the forthcoming stable release. If we proceed with
that, then this bug wil
Package: scikit-learn
Version: 1.1.2+dfsg-92
Severity: normal
scipy 1.10 is now available in experimental.
scikit-learn fails debci tests using it.
We are considering uploading scipy 1.10 to unstable in order to
included it in the forthcoming stable release. If we proceed with
that, then this bu
On 2023-01-27 10:25, Andreas Tille wrote:
https://qa.debian.org/excuses.php?experimental=1&package=scikit-learn
scikit-learn looks like it should manageable.
I've uploaded scipy 1.10 to unstable now.
Drew
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists
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
TestDisc
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
passing
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 runnin
Source: pygmsh
Followup-For: Bug #1011699
I can't reproduce this build failure.
The reproducibility builds at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pygmsh.html
have consistently been successful, apart from one failure around the
same time in May on arm64.
freeimage
Source: silx
Version: 1.0.0+dfsg-4
Severity: normal
silx debci tests have started failing in testing on amd64 running
against scipy 1.8.1-4 from unstable.
Not clear what the problem is since the test previously passed against
scipy/1.8.1-3. Maybe it's a coincidence, triggered by something else
th
Source: fenics-dolfinx
Followup-For: Bug #1012923
Judging by
https://github.com/doxygen/doxygen/commit/5198966c8d5fec89116d025c74934ac03ea511fa
likely needs
#include
added to cpp/dolfinx/la/PETScOperator.cpp
There are some code rearrangements in dolfinx 0.4, let's check again
with that versio
Control: reopen 1010595
Control: forwarded 1010595
https://github.com/xtensor-stack/xsimd/issues/756
Control: block 1013568 by 1010595 1012437
A number of upgrades including scipy got interrupted by the upgrade of
xsimd to v8. We're working through the transition now. scipy needs a
working p
I don't know myself which xsimd test is which in order to implement the
scalar test division discussed in upstream Issue#756. For sure upstream
will know.
While we're resolving that, one simple thing we could do temporarily for
the packaging is to restrict the CI tests to only run on the known
Control: fixed 1014094 8.1.0-5
Fixed already in xsimd 8.1.0-5
--
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: statsmodels
Version: 0.13.2+dfsg-2
Severity: normal
scipy 1.8.1 has been recently uploaded to unstable.
statsmodel is giving a test error on s390x:
TestDynamicFactor_ar2_errors.test_mle _
self =
def test_mle(self):
with warnings.ca
Small correction: statsmodels did pass tests with scipy/1.8.1-4 (18 June
2022), so the test_mle failure can probably be attributed to use of
pythran with scipy 1.8.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-
Source: statsmodels
Version: 0.13.2+dfsg-2
Severity: serious
Justification: FTBFS
Control: forwarded -1 https://github.com/statsmodels/statsmodels/issues/8341
mipsel is failing to build statsmodels 0.13.2+dfsg-2.
Problem seems to be another shift in tolerance requirements triggered
by scipy using
Source: python-h5netcdf
Version: 1.0.1-1
Severity: serious
Tags: patch
Justification: debci
Control: forwarded -1 https://github.com/h5netcdf/h5netcdf/issues/179
h5netcdf tests fail with h5py 3.7.0, which was recently uploaded to
unstable.
The problem is fixed upstream, the fix is available in th
Source: fenics-dolfinx
Followup-For: Bug #1017284
The cmake error logs can be too effusive, they tend to obscure the
error. In this case the real problem seems to be that it never found
scotch, even though it found it. A mystery indeed. Schrödinger's
SCOTCH.
--
debian-science-maintainers mailin
Source: qutip
Version: 4.7.0-3
Severity: normal
Control: forwarded -1 https://github.com/qutip/qutip/issues/1875
It should be possible to build using pyproject.toml (PEP517),
Build-Depends: pybuild-plugin-pyproject
The problem is that that method does not understand the --with-openmp
flag added t
Source: fenics-dolfinx
Followup-For: Bug #1017053
I see. I attributed the fault to the pmix problem too quickly.
>From the error logs it seems to be coming from xtl.
I've just uploaded dolfinx 0.5.0. It might help since it has removed
explicit xtl use.
--
debian-science-maintainers mailing lis
Source: fenics-dolfinx
Followup-For: Bug #1017053
For what it's worth the same error warning from tensor/xtl also shows
up in xtensor's own tests on amd64.
Not clear why it gives dolfinx a problem only on mips64el. I'd expect
the problem to be the same on all arches.
Any any case, I think the wo
reassign 1019050 dh-fortran-mod
retitle 1019050 postrm template: failed to remove
'/usr/lib/*/fortran/gfortran': No such file or directory
thanks
This bug does not belong to libsuperlu-dist-dev. The postrm code
addressing removal of /usr/lib/*/fortran/gfortran comes from the
template provide
Source: scikit-learn
Version: 1.1.2+dfsg-5
Severity: normal
scikit-learn fails debci tests when running with scipy 1.8.
The failing test is test_mlp_regressor_dtypes_casting in test_mlp.py
It's not a "large" failure, just that the tolerance rtol=0.0001 is not
met by a small amount. rtol=0.0002 w
Source: libflame
Version: 5.2.0-3
Severity: normal
libflame 5.2.0-3 in testing is failing numpy tests on amd64 against
scipy 1.8.1-14 fom unstable, affecting the scipy 1.8 upgrade.
The pattern of the failure is strange. Tests passed with scipy
1.8.1-13 only days before. Tests in unstable are pa
Source: libflame
Followup-For: Bug #1019478
Today the test has passes in debci.
Looks like the test or the package is flakey.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-mai
Source: h5py
Version: 3.7.0-2
Followup-For: Bug #1020054
Reproducible, e.g.
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/h5py_3.7.0-2.rbuild.log.gz
I suspect the bug is not in h5py but rather in libhdf5-openmpi-dev,
possibly in the flags used by h5pcc.
The last hdf5 version
1 - 100 of 554 matches
Mail list logo
