Source: python-language-server
Followup-For: Bug #999524
Upstream lost write access to the python-language-server repo
https://github.com/palantir/python-language-server/issues/935
so have forked the project to python-lsp-server at
https://github.com/python-lsp/python-lsp-server
As part of the
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
* Package name: python-meshzoo
Version : 0.9.0
Upstream Author : Nico Schlömer
* URL : https://github.com/nschloe/meshzoo
* License
On 2021-11-20 10:31, Drew Parsons wrote:
I see 3 workarounds
1) create a symlink from dkms.key to mok.priv and dkms.der to mok.der.
2) Create a separate dkms.key. Not so convenient to have 2 keys
though (though I could just stop using mok.der)
3) Comment out sign_tool in /etc/dkms
On 2021-11-20 10:03, Drew Parsons wrote:
...
sign-file itself is working, and working with my MOK keys.
When dkms runs, it evidently triggers sign-file, invoking
/root/dkms.key
...
So I see 2 questions here:
1) what is making the dkms scripts invoke sign-file ?
2) what is making them
On 2021-11-20 09:48, Drew Parsons wrote:
...
I guess that reference to bss_file.c must be a clue, if not the
reference to the missing /root/dkms.key >
The 470.74/5.14.0-2 make.log in the error message shows no errors
itself, but the last line is
"Signing /var/lib/dkms/nvidia-curren
On 2021-10-17 11:57, Andreas Beckmann wrote:
Control: severity -1 normal
On 15/10/2021 19.42, Drew Parsons wrote:
I guess that reference to bss_file.c must be a clue, if not the
reference to the missing /root/dkms.key >
The 470.74/5.14.0-2 make.log in the error message shows no errors
its
Package: ftp.debian.org
Severity: normal
In order to keep the source package namespace more contained, I renamed
the latest source packages from the fenics suite, to carry a fenics
prefix:
basix (0.0.1~git20210122.4f10ef2-2) -> fenics-basix(0.3.0-10)
ffcx
Package: sasview
Version: 5.0.4-1
Severity: normal
The Help menu points to Documentation and Tutorial.
But the link is set to file:///usr/bin/doc/index.html, while the
documentation is located at /usr/share/doc/sasview/html/index.html
Likewise Tutorial points to
Source: numba
Version: 0.52.0-5
Severity: normal
llvmlite 0.37 is now packaged and migrated to testing. That clears
the way for packaging numba 0.54.
numba 0.54 has some patches that will hopefully improve reliability on
non-amd64 arches.
Source: numpy
Followup-For: Bug #994316
Reminder here to consider revising the install files once -dbg is
removed.
At the moment all submodules are listed explicitly (on separate lines) in
debian/python3-numpy.install
This means that if numpy adds new functionality (a new submodule), it
will be
On 2021-11-05 06:10, Sandro Tosi wrote:
On Wed, Nov 3, 2021 at 7:16 PM Drew Parsons
wrote:
...
Just add
usr/lib/python3*/*-packages/numpy/typing/
to debian/python3-numpy.install.
i've uploaded this to experimental
Thanks Sandro, works well. I've uploaded npx to NEW now.
The bigger
On 2021-11-04 22:35, Drew Parsons wrote:
On 2021-11-04 21:41, Sebastian Ramacher wrote:
On 2021-11-03 22:33:01 +0100, Drew Parsons wrote:
...
Is it best to revert back to strict Policy 8.1 compliance, which will
slow
down hypre patch release updates?
Yes. Having to wait for binNEW to being
On 2021-11-04 21:41, Sebastian Ramacher wrote:
On 2021-11-03 22:33:01 +0100, Drew Parsons wrote:
...
The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to
solve is
that hypre is ABI-ignorant
(https://github.com/hypre-space/hypre/issues/56),
so each point patch release would have
Source: h5py
Followup-For: Bug #994617
Hi Mattia, historically hdf5 has not been entirely ABI-stable, see
https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312
https://forum.hdfgroup.org/t/another-abi-breakage/5503
The test was added in
On 2021-11-02 17:40, Sandro Tosi wrote:
sorry but that's not how RC severity works, that's for policy
violations, which in this case there are none.
I understand you may want to see this fixed sooner rather than later,
so maybe you can submit an MR against the numpy salsa repo to fix
this?
On 2021-11-03 20:57, Sebastian Ramacher wrote:
Source: hypre
Severity: serious
...
The real blocker is hypre, specifically:
hypre (2.18.1-1) experimental; urgency=medium
.
* Team upload.
* New upstream release.
* Standards-Version: 4.4.1
* Provide library binary package as
On 2021-10-31 20:57, Anton Gladky wrote:
sundials_5.8.0 is in unstable already.
Thanks Anton.
Is deal.ii the core blocker at this point? Looks like it has other
issues, Bug#996277, not related to the numerical library transition.
It's scheduled for removal next week.
Drew
Source: numpy
Followup-For: Bug #998109
Control: severity -1 serious
Control: affects -1 src:pygmsh src:python-meshplex
This bug is blocking other python packages which require numpy 1.20,
(and use numpy.typing) so raising severity to serious.
Source: llvmlite
Version: 0.35.0-3
Followup-For: Bug #974778
Control: affects -1 src:numba
Now that bullseye is released, please proceed fixing this bug now,
i.e. please package llvmlite 0.37.
It's required in order to package numba 0.54, which is needed to fix
problems on armel.
This doesn't seem to be a bug in the package. It just declares "vet" as
a cli.Command in build.go.
The error must be elsewhere in the go infrastructure, possibly in the dh
go addon (dh-golang) which generates "go test" for dh_auto_test.
This doesn't seem to be a bug in the package. It just declares "vet" as
a cli.Command in build.go.
The error must be elsewhere in the go infrastructure, possibly in the dh
go addon (dh-golang) which generates "go test" for dh_auto_test.
Package: python3-numpy
Version: 1:1.21.2-2
Severity: important
python3-numpy is missing numpy.typing
I gather numpy.typing was added in numpy 1.20. Some packages have
already started using it, e.g. npx.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy:
On 2021-10-30 11:04, Sebastian Ramacher wrote:
On 2021-10-30 00:50:49 +0200, Drew Parsons wrote:
I've got dolfinx passing (or skipping) its own tests on 32-bit.
There's a problem with 32-bit MPI though. i386 and armhf are failing
to run
pytest over python unit tests in MPI
...
Might
Source: mpi4py
Version: 3.1.1-8
Severity: serious
Justification: debci
Control: forwarded -1 https://github.com/mpi4py/mpi4py/issues/105
mpi4py tests are failing on i386 debci.
e.g.
https://ci.debian.net/data/autopkgtest/unstable/i386/m/mpi4py/16315322/log.gz
The failing tests are file IO tests
On 2021-10-22 14:35, Sebastian Ramacher wrote:
On 2021-10-12 13:09:02, Drew Parsons wrote:
...
I'd like to proceed with a transition of the numerical library stack.
...
(along with other fenics components). There is currently some problem
with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386
On 2021-10-29 23:03, Sebastian Ramacher wrote:
On 2021-10-29 23:59:46 +0300, Adrian Bunk wrote:
On Fri, Oct 29, 2021 at 10:54:21PM +0200, Sebastian Ramacher wrote:
...
>
> Thanks for the heads up. I've added removal hints for basix, ffcx,
> dolfinx, fenics, and fenicsx-performance-tests.
>...
On 2021-10-27 14:03, Adrian Bunk wrote:
On Wed, Oct 27, 2021 at 11:41:39AM +0200, Drew Parsons wrote:
...
Since these are runtime tests (compiled fresh for the test), I like
the idea
of keeping -march=native, since it will emulate what users will
experience
when they use xtensor in their own
On 2021-10-27 10:24, Adrian Bunk wrote:
On Sat, Oct 09, 2021 at 06:17:54PM +0200, Drew Parsons wrote:
Source: xtensor
Followup-For: Bug #995867
Control: retitle -1 mipsel FTBFS (relocation truncated to fit:
R_MIPS_CALL16)
The problem with undefined `__umodsi3' `__udivsi3' is not easily
schrieb Drew Parsons
:
The sundials 5.8.0 test build in experimental looks successful.
Probably not worth waiting for the mipsel build, it's been slow to
build, especially for experimental.
The sundials 5.8.0 test build in experimental looks successful.
Probably not worth waiting for the mipsel build, it's been slow to
build, especially for experimental.
Drew
On 2021-10-22 17:40, Anton Gladky wrote:
Great, thanks! Will do it very shortly.
Anton
Sebastian Ramacher schrieb
Hi mipsel porters,
I need help resolving Bug#995867 [1]. xtensor implacably FTBFS.
I thought it might have been related to memory constraints, since
xtensor is a header-only library. But the problem is still present after
reducing the test file to only one "optional" tests (unless that's
Source: sundials
Version: 5.7.0+dfsg-1
Severity: normal
Unless I misunderstood the package naming system for sundials, looks
like there was an ABI bump in sublibraries when sundials upgraded from
v4 to v5.
It can be seen in 5.7.0+dfsg-1, so it's not a side-effect of the the new
5.8.0 build
Source: hypre
Followup-For: Bug #996895
The changelog for 2.22.1-1exp1 gives a clue,
"provide 64-bit only on arches where libblas64-dev, liblapack64-dev
are available"
Looks like debian/tests didn't receive the memo...
Source: hypre
Followup-For: Bug #996895
Weird. How could they have gone missing? Will have to track them done.
Drew
On 2021-10-16 00:01, Drew Parsons wrote:
On 2021-10-15 21:02, Sebastian Ramacher wrote:
I'd like to proceed with a transition of the numerical library stack.
This involves
...
Thanks Sebastian. I'll start from superlu (and xtensor already
underway).
Waiting for the trilinos rebuild
Package: libxtensor-blas-dev
Version: 0.19.1-5
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xtensor-blas/issues/211
The xlapack.solveCholesky test in
xtensor-blas/test/test_lapack.cpp
Line 150 in 0aee299
TEST(xlapack, solveCholesky) {
uses an expected x value
On 2021-10-07 18:04, Drew Parsons wrote:
Package: wnpp
...
* Package name: python-npx
Version : 0.0.20
* URL : https://github.com/nschloe/npx
https://salsa.debian.org/python-team/packages/python-npx
waiting for numpy 1.20
On 2021-10-15 21:02, Sebastian Ramacher wrote:
Control: tags -1 confirmed
On 2021-10-12 13:09:02 +0200, Drew Parsons wrote:
I'd like to proceed with a transition of the numerical library stack.
This involves
...
Please go ahead
Cheers
Ben file:
title = "numerical library
On 2021-10-15 19:23, Andreas Beckmann wrote:
On 14/10/2021 12.15, Drew Parsons wrote:
Package: nvidia-kernel-dkms
Version: 470.74-1
Severity: serious
Justification: fails to configure
Upgrade to the new nvidia-driver 470.74-1 (nvidia-kernel-dkms) fails
at the configuration step with this error
Package: python-is-python3
Version: 3.9.2-2
Severity: normal
Some third-party providers provide deb packages, which is nice of
them, but they often refer to Python as python, even when their
programs support python3. It's messy of course, but that's why
the python-is-python3 package exists.
On 2021-10-13 13:42, Nico Schlömer wrote:
Or PR upstream. I can merge and release any time.
Thanks Nico. I'll check which tolerances it needs and file a PR.
The error in test_rectangle might need your attention,
"At index 0 diff: 279 != 276". I guess it's not just tolerances.
Drew
Not entirely unexpected. Upstream reorganized tests and tolerances, so
I wanted to check if we had a full pass or not.
Looks like we'll have to reinstate test_relax_tolerance.patch
On 2021-10-13 12:03, Adrian Bunk wrote:
Source: pygalmesh
Version: 0.10.5-1
Severity: serious
On 2021-10-13 02:35, Drew Parsons wrote:
..
Debugging a bit further (with MPI_IN_PLACE removed), I can identify
that the bug is in dolfinx not openmpi (unless there are two bugs
here).
Comparing detailed debug output from 2 threads, I find one thread
skips the facet loop
On 2021-10-12 22:24, Drew Parsons wrote:
On 2021-10-12 17:46, Jeff Squyres (jsquyres) wrote:
...
Ok, so this is an MPI_Alltoall issue. Does it use MPI_IN_PLACE?
...
I'll apply PR1738 to the debian dolfinx build and see how it turns
out.
Looks like removing MPI_IN_PLACE is not enough
On 2021-10-12 18:22, Drew Parsons wrote:
On 2021-10-12 17:46, Jeff Squyres (jsquyres) wrote:
I'm sorry, I just noticed that you replied 6 days ago, but I
apparently wasn't notified by the Debian bug tracker. :-(
Sorry about that. I'm never quite sure when the bug tracker does or
does not add
ctually breaks behaviour on 32-bit arches.
I'll apply PR1738 to the debian dolfinx build and see how it turns out.
Drew
On Wed, 06 Oct 2021 20:15:38 +0200 Drew Parsons
wrote:
Source: openmpi
Followup-For: Bug #995599
Not so simple to make a minimal test case I think.
all_to_all is defin
Package: dh-make
Version: 2.202102
Severity: normal
The dh-make template for python packages sets up debian/rules with a
special case for docs built using sphinx:
# And uncomment the following lines
#override_dh_auto_build: export http_proxy=127.0.0.1:9
#override_dh_auto_build: export
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky
I'd like to proceed with a transition of the numerical library stack.
This involves
superlu 5.2.2+dfsg1 -> 5.3.0+dfsg1
Source: xtensor
Followup-For: Bug #985699
0.23.10-10 skips the test_xnpy tests on s390x, hppa, powerpc, ppc64,
sparc64.
That just ignores the problem, enabling the package to build and get
tested by other packages on these arches. It doesn't fix the problem.
Source: xtensor
Followup-For: Bug #995867
Control: retitle -1 mipsel FTBFS (relocation truncated to fit: R_MIPS_CALL16)
The problem with undefined `__umodsi3' `__udivsi3' is not easily
reproduced.
But the mipsel build failure is consistent.
The more common symptom is "relocation truncated"
Source: sphinx-tabs
Version: 3.2.0-1
Severity: normal
sphinx-tabs 3.2.0-1 is passing tests in unstable, but failing
transition tests in testing.
The failure is trivial, test_other_with_assets.html is
expecting to have
1
but in testing it gets
1
It looks as if new sphinx 4.2 is generating
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org,
debian-scie...@lists.debian.org
* Package name: python-npx
Version : 0.0.20
Upstream Author : Nico Schlömer
* URL : https://github.com
On 18 Jun 2021, Osamu Aoki wrote:
PEP-518 package may be without setup.py and may still be based on
setuptools. For
that kind of package, work around using flit plugin doesn't work.
...
I think what we need is future oriented solution, here. We should
create another plugin
for "build" which
Source: xtensor
Severity: normal
Tags: ftbfs
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2440
xtensor fails to build on mipsel architecture.
Previously the problem with 0.22.0 was virtual memory exhausted, see
Source: openmpi
Followup-For: Bug #995599
Not so simple to make a minimal test case I think.
all_to_all is defined in cpp/dolfinx/common/MPI.h in dolfinx source,
and calls MPI_Alltoall from openmpi.
It's designed to use with graph::AdjacencyList from
graph/AdjacencyList.h, and is called from
Diego wrote:
I intend to package this software, preferably under the umbrella of the
Debian Python Team (on the basis of being useful to a general Python
audience)- if the Debian Science Team has a stronger interest or
preference, please let me know, I'm fine with that approach as well.
That
On 2021-10-03 12:15, Gilles Filippini wrote:
Drew Parsons a écrit le 02/10/2021 à 22:17 :
...
Since h5pcc and h5cc invoke -lcurl, libhdf5-openmpi-dev, libhdf5-dev
(and
probably libhdf5-mpich-dev also) should declare Depends: libcurl-dev
...
I guess this is a consequence of enabling access
Source: mathjax
Followup-For: Bug #989649
It's not always so simple as adding the conf.py patch.
For the example of fenics-dolfinx 0.3.0-3 (in experimental), the
lintian privacy-breach-generic warning complains about
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js
But there is
On 2021-10-03 12:15, Gilles Filippini wrote:
Drew Parsons a écrit le 02/10/2021 à 22:17 :
Why h5cc needs -lcurl is a separate question! What is it trying to
download?
I guess this is a consequence of enabling access to HDF5 on S3. See
#972537.
Ah yes, that makes sense. S3 support
On 2021-10-03 00:51, Drew Parsons wrote:
Manually debugging isolates the point in the dolfinx code at
mesh/graphbuild.cpp l.144
graph::AdjacencyList recvd_buffer
= dolfinx::MPI::all_to_all(comm, send_buffer);
https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/blob
Manually debugging isolates the point in the dolfinx code at
mesh/graphbuild.cpp l.144
graph::AdjacencyList recvd_buffer
= dolfinx::MPI::all_to_all(comm, send_buffer);
https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/blob/experimental/cpp/dolfinx/mesh/graphbuild.cpp#L144
I
Package: libopenmpi3
Version: 4.1.2~rc1-4
Severity: important
Control: affects -1 src:fenics-dolfinx
fenics-dolfinx FTBFS on 32-bit arches, i386, armel, armhf, see
https://buildd.debian.org/status/package.php?p=fenics-dolfinx=experimental
Package: libhdf5-openmpi-dev
Version: 1.10.7+repack-2
Severity: serious
Justification: FTBFS
Control: affects -1 src:fenics-dolfinx
The hdf5 compiler wrappers declare -lcurl as a linked library
e.g.
$ h5cc -showconfig | grep curl
Extra libraries: -lcrypto -lcurl -lpthread -lsz
Source: numba
Followup-For: Bug #994294
Control: forwarded 994294 https://github.com/numba/numba/issues/7452
We've got numba 0.52, while 0.54 was released last week. Is it possible
to package up numba 0.54 for further testing?
Source: numba
Followup-For: Bug #994294
numba test options give a better more detail
experimental_armel-dchroot$ python3 -m numba.runtests --log
DEBUG:numba.core.byteflow:bytecode dump:
> 0NOP(arg=None, lineno=38)
2LOAD_FAST(arg=0, lineno=38)
4
Source: numba
Followup-For: Bug #994294
Upstream Issue #3052 is related, although claims llvm problems were
fixed already. Perhaps the bug here is a different LLVM Error.
https://github.com/numba/numba/issues/3052
Seems to have worked, thanks Diane. dask has made it to testing now.
Drew
Can anyone say why this Bug#980692 is still holding up the dask
migration?
The bug is fully marked fixed and closed now, it shouldn't be in the way
any more.
Drew
Source: openmpi
Followup-For: Bug #995150
Installing libopenmpi3-dbgsym gives a little more detail in the
backtrace
(gdb) bt
#0 0x in ?? ()
#1 0x7fffad13ea84 in MPIOI_File_iwrite_all (fh=,
offset=offset@entry=0, file_ptr_type=file_ptr_type@entry=101, buf=, count=13,
Source: openmpi
Followup-For: Bug #995150
gdb on amd64 run locally confirms the segfault, running test_io.py
alone. Refines the problem to MPIOI_File_iwrite_all in
mca_io_romio321.so
$ gdb python3
(gdb) run -m pytest test_io.py
Starting program: /usr/bin/python3 -m pytest test_io.py
[Thread
Source: openmpi
Version: 4.1.2~rc1-2
Severity: serious
Justification: FTBFS
The new version of openmpi seems to be segfaulting in
mca_io_romio321.so
The segfault is found in nearly all arches in mpi4py tests,
https://buildd.debian.org/status/package.php?p=mpi4py
(it causes mpi4py to FTBFS)
The
Source: ipywidgets
Followup-For: Bug #896460
There are also 2nd order dependencies affected by this bug.
Docs for scipy 1.7 use pydata-sphinx-theme, which depends on jupyter-sphinx.
So the scipy upgrade is blocked.
Source: xtensor
Followup-For: Bug #994248
And hurd-i386,
https://buildd.debian.org/status/fetch.php?pkg=xtensor=hurd-i386=0.23.10-6=1631643405=0
Source: hydroffice.bag
Followup-For: Bug #993003
Upstream reports (moving the upstream bug to
https://github.com/hydroffice/hyo2_bag/issues/1 )
that hyo.bag is deprecated, superseded by hyo2.bag, which has a
separate repository at
https://github.com/hydroffice/hyo2_bag
Current latest release is
On 2021-09-17 15:27, Giacomo Mulas wrote:
On Fri, 17 Sep 2021, Drew Parsons wrote:
Grazie per il tuo lavoro, Giacomo.
Excellent Italian! :D
I accepted a position at University of Cagliari this year :) gradually
learning the language...
I will give it a spin for sure. Not right now, I
Source: petsc
Followup-For: Bug #990290
X-Debbugs-Cc: Giacomo Mulas
Grazie per il tuo lavoro, Giacomo.
Would you be able to provide a patch for your changes, i.e. a diff
file? The simplest way might be to clone the git repo
(https://salsa.debian.org/science-team/petsc) and use `git diff`.
Package: python3-numba
Version: 0.52.0-4
Severity: normal
Control: affects -1 src:fenics-basix
numba tests are failing on debci for armel:
[*] Testing with python3.9:
/usr/lib/python3/dist-packages/numba/tests/npyufunc/test_gufunc.py:2:
DeprecationWarning: numpy.core.umath_tests is an internal
On 2021-09-14 09:22, Drew Parsons wrote:
Note that I do run the tests locally. autopkgtest is passing fine on
my own system, including the py39-mpi-oldpt test. It's not attempting
to rebuild mpi4py wheels.
In regards to my local successful build, it could be relevant that I'm
testing
Applies also to x32,
https://buildd.debian.org/status/fetch.php?pkg=xtensor=x32=0.23.10-5=1631538409=0
Source: xtensor
Version: 0.23.10-5
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2434
A build of xtensor 0.23.10 is failing on i386 (i686) when xsimd support is
activated (xsimd 7.5.0).
An excerpt from the build log is,
Source: xtensor
Version: 0.23.10-5
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2433
xtensor 0.23.10 FTBFS on arm64 with errors like:
[ 4%] Building CXX object
test/CMakeFiles/test_xtensor_lib.dir/test_xadaptor_semantic.cpp.o
cd
On 2021-09-14 03:28, Sandro Tosi wrote:
Yeah, there's something right weird going on here. I can't reproduce
locally.
this package doesnt run tests at buildtime:
https://salsa.debian.org/python-team/packages/pytest-mpi/-/blob/master/debian/rules#L22-23
introduced with commit
Source: xsimd
Version: 7.5.0-1
Severity: normal
The i386 arch corresponds to 686, i.e. Pentium 6 (P6) released in 1995,
https://en.wikipedia.org/wiki/P6_(microarchitecture)
xsimd provides acceleration through extensions SSE2 and higher.
SSE2 was introduced with the Pentium 4 in 2000 (SSE came
Source: golang-github-mattn-go-gtk
Followup-For: Bug #967445
I don't see any movement upstream to port go-gtk to gtk-3 (or gtk-4).
Probably go-gtk should be considered strictly as a GTK-2 client.
I packaged golang-github-mattn-go-gtk since it was required by
golang-github-anacrolix-dms, but dms
Source: dask
Followup-For: Bug #980692
There's no actual close tag for the BTS Control server, so it didn't
close the bug from the control line. I think we need to use the
980692-d...@bugs.debian.org address to close the bug if the tag was
missing in the changelog.
Drew
Source: pytest-mpi
Followup-For: Bug #993691
Yeah, there's something right weird going on here. I can't reproduce
locally.
The error itself is an error. It shouldn't be trying to build a wheel
for mpi4py in the first place. That implies it's downloading mpi4py
source and rebuilding, the error
On 2021-09-04 23:45, Diane Trout wrote:
Hmm...
So dask doesn't think jinja is required for base functionality. It's a
dependency for an extended extras.
OK, thanks for checking it.
...
At dask's end jinja should probably be a suggests or recommends, but
since you can use dask without
Package: python3-dask
Version: 2021.08.1+dfsg-1
Severity: serious
Justification: debci
Control: affects -1 src:python-xarray
dask imports from jinja2 in
/usr/lib/python3/dist-packages/dask/widgets/widgets.py, but
Depends: python3-jinja2 has not been declared.
dask's own tests are apparently not
On 2021-08-30 08:56, Graham Inggs wrote:
On Mon, 30 Aug 2021 at 00:22, Drew Parsons wrote:
Graham, when I run autopkgtest, it skips the dummy test, which is what
we want, but it does so with the message
SKIP unknown restriction hint-testsuite-triggers
"unknown restri
On 2021-08-30 00:05, Drew Parsons wrote:
On 2021-08-29 20:27, Graham Inggs wrote:
Even better would be to add the following section to
debian/tests/control:
# Dummy test so that changes to other packages trigger our
autopkgtests
# on ci.debian.net
Test-Command: /bin/true
Depends: libpmix
On 2021-08-29 20:27, Graham Inggs wrote:
Even better would be to add the following section to
debian/tests/control:
# Dummy test so that changes to other packages trigger our autopkgtests
# on ci.debian.net
Test-Command: /bin/true
Depends: libpmix-dev,
libucx-dev [amd64 arm64 ppc64el],
Source: mpi4py
Followup-For: Bug #993214
There have been some strange mpi failures. pytest-mpy also started
failing tests for no good reason.
spawning has been unreliable in OpenMPI for a long time, cf.
https://github.com/jsquyres/ompi/pull/4#issuecomment-806897758
mpi4py upstream informs me
Source: yt
Version: 3.6.1-1
Severity: serious
Justification: breaks
yt tests fail with h5py 3, due to removal of the values property.
if "dataset_units" in h5f:
for unit_name in h5f["/dataset_units"]:
current_unit = h5f["/dataset_units/%s" % unit_name]
>
Source: hydroffice.bag
Version: 0.2.15-3
Severity: serious
Justification: breaks
Control: forwarded -1 https://github.com/hydroffice/hyo_bag/issues/3
hydroffice.bag fails debci tests with h5py 3
h5py changed the way the file mode is set when accessing .h5 files.
The mode now needs to be given
Source: python-xarray
Version: 0.19.0-2
Followup-For: Bug #983758
The problem is exacerbated in 0.19.0-2 by this error during test
collection
/usr/lib/python3/dist-packages/xarray/tests/test_tutorial.py:9: in
class TestLoadDataset:
Source: hdf5
Followup-For: Bug #972537
Control: affects -1 src:h5py
h5py is now ready for ROS3 support.
Source: lmfit-py
Followup-For: Bug #992674
Control: reassign 992674 src:lmfit-py 1.0.1-6
This bug is fixed upstream at
https://github.com/lmfit/lmfit-py/commit/9cb4056bb661a1ed6fedfbbca2b124aba3dbc290
Source: dask
Followup-For: Bug #992672
Control: reassign 992672 src:dash 2021.01.0+dfsg-1
This bug is addressed in https://github.com/dask/dask/pull/7841
A version upgrade should fix it.
Package: debian-policy
Version: 4.6.0.0
Severity: normal
The upgrading-checklist at
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz
was not upgraded correctly for 4.6.0.0.
It references Version 4.5.2 instead.
Package: python3-scipy
Version: 1.7.0-1
Severity: normal
Control: block -1 by 991143
Build scipy with pythran support by dropping SCIPY_USE_PYTHRAN=0 from
debian/rules as soon as possible, in order to enhance scipy runtime
performance.
501 - 600 of 2377 matches
Mail list logo
