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
On 2023-01-27 10:25, Andreas Tille wrote:
https://qa.debian.org/excuses.php?experimental=1=scikit-learn
scikit-learn looks like it should manageable.
I've uploaded scipy 1.10 to unstable now.
Drew
--
debian-science-maintainers mailing list
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
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
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
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
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 =
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: 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
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
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
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
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
--
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
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
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
Source: h5py
Followup-For: Bug #1020054
The problem is partially related to the
-L/usr/lib/x86_64-linux-gnu -lhdf5
in the failing compilation line.
Since debian provides serial and mpi builds of hdf5, there is no
/usr/lib/x86_64-linux-gnu/libhdf5.so (there is libhdf5_serial.so and
1 - 100 of 491 matches
Mail list logo
