Package: tracker.debian.org
Followup-For: Bug #944737
Related to this request, it would be helpful if experimental excuses
were linked on package tracker pages.
qa.debian.org provides such links
e.g. https://qa.debian.org/developer.php?login=dpars...@debian.org
currently links to experimental exc
Source: astroml
Version: 1.0.2-4
Severity: normal
astroml is failing debci tests with matplotlib 3.8 from experimental
95s === FAILURES
===
95s test_devectorize_axes
_
95s
Source: basemap
Version: 1.2.2+dfsg-5
Severity: normal
basemap is failing tests with matplotlib 3.8 from experimental.
I guess it's likely to be resolved in the more recent releases.
Source: gammapy
Version: 1.1-5
Severity: normal
gammapy is failing tests against matplotlib 3.8 from experimental
Possibly astropy is at fault rather than gammapy.
237s _ test_plot_at_energy
__
237s
237s self = , unit = Unit(dimensionles
Source: poliastro
Version: 0.17.0-2
Severity: normal
poliastro is failing tests with matplotlib 3.8 from experimental
e.g.
278s /usr/lib/python3/dist-packages/numpy/ma/core.py:2360: TypeError
278s __ test_axes_labels_and_title
__
278s
278s de
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: xrayutilities
Version: 1.7.4-1
Severity: normal
xrayutilities is failing tests with matplotlib 3.8 from experimental
470s _ TestExampleScripts.test_simpack_powdermodel
__
470s
470s self =
470s
470s def test(self):
470s with tempfile.Temporar
Package: opendrop
Version: 3.3.1-4
Severity: grave
Tags: patch upstream
Justification: renders package unusable
debian patch sundials_nvector_API6.patch enabled opendrop to build
against sundials 6.
Nevertheless it still fails when attempting to analysis interfacial
tension measurements:
[ARKOD
Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566
Running their binary executable directly:
$ ./bin/glnxa64/MATLABWindow
./bin/glnxa64/MATLABWindow: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform
libharfbuzz.so.0 declar
Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566
For the record, it started accepting keyboard input after I left the
directly and reentered to try again ;/ I now have a working version
of Matlab on my debian system (after removing their libfreetype.so.6)
I meant to add, a
errors by
+asserting use of Gtk 3.
+ * Standards-Version: 4.6.2
+
+ -- Drew Parsons Thu, 09 Mar 2023 02:24:59 +0100
+
opendrop (3.3.1-4) unstable; urgency=medium
* debian/patches/sundials_nvector_API6.patch updates sundials
diff -Nru opendrop-3.3.1/debian/control opendrop-3.3.1/debian
-mpich.README.Debian to document the need to use
+ARMCI_USE_WIN_ALLOCATE=0 when running nwchem with MPICH 4.0.2
+(binary nwchem.mpich, fixed in mpich 4.0.3).
+See upstream Issue#633.
+
+ -- Drew Parsons Sun, 19 Mar 2023 15:01:42 +0100
+
nwchem (7.0.2-3) unstable; urgency=medium
ci-mpi (0.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-m
Source: golang-github-anacrolix-missinggo
Followup-For: Bug #1021408
debci is not currently able to reproduce the error in a barrage of 10
repetitions, on both unstable and testing.
It's the nature of flakey tests to not reproduce well, but still I'd
expect the failure to show in at least 1 in 10
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-anacrolix-log
Version : 0.13.1
Upstream Author : Matt Joiner
* URL : https://github.com/anacrolix/log
* License
Package: libhdf5-openmpi-dev
Version: 1.10.8+repack-1
Severity: important
Control: block 1020054 by -1
h5pcc is showing an unexpected default configuration:
$ h5pcc --showconfig
gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi
/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf
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
On 2022-11-06 15:22, Gilles Filippini wrote:
Hi Drew,
...
h5pcc is showing an unexpected default configuration:
...
Note how it includes static linking to libhdf5_hl.a and libhdf5.a
This is the expected behavior as documented by upstream:
-shlib Compile with shared HDF5 libraries [d
Source: scipy
Followup-For: Bug #1020561
I appreciate the dilemma, but I think we won't be able to avoid it.
As you noticed, it's not scipy that needs c++, it's pythran. pythran
is recommended by scipy developers upstream. The purpose of pythran is
to accelerate scipy execution by runtime genera
Package: git-buildpackage
Version: 0.9.29
Severity: important
I'm trying to use gbp to update the source for the golang-gocloud
package from 0.20.0 to the latest 0.27.0.
The salsa url for it is https://salsa.debian.org/go-team/packages/golang-gocloud
while upstream is https://github.com/google/go-
Package: git-buildpackage
Followup-For: Bug #1023742
It looks like the problem arises from git itself not respecting the
image files.
When I manually extract the tarball into the upstream branch of a
clone of debian's golang-gocloud repo from salsa, and run "git add -A"
to add the new files in v0
On 2022-11-09 14:16, Guido Günther wrote:
Hi,
On Wed, Nov 09, 2022 at 01:47:13PM +0100, Drew Parsons wrote:
Package: git-buildpackage
Followup-For: Bug #1023742
It looks like the problem arises from git itself not respecting the
image files.
When I manually extract the tarball into the
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 local
Source: cython
Version: 0.29.32-2
Followup-For: Bug #1028157
Control: affects 1028157 src:scipy
The latest version of scipy, 1.11.1, needs Cython>=0.29.35
but also declares Cython<3.0.
Can Cython please be updated to the latest 0.29 version before
upgrading to 3.0.0 alpha?
Might be best to uploa
Source: astropy
Version: 5.2.1-1
Severity: normal
Control: forwarded -1 https://github.com/astropy/astropy/issues/13986
astropy fails test_models_fitting[LevMarLSQFitter-model31] on i386.
The problem appears to be triggered by scipy 1.10, and the problem is
discussed upstream at https://github.com
Source: xrayutilities
Version: 1.7.4-1
Severity: serious
Justification: debci
python3-xrayutilities has an inconsistent Dependency on h5py
It declares python3-h5py-serial [alpha, hppa, m68k, sparc64, x32], in
other words is not declared for most architectures.
But xrayutilities needs h5py in io/h
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-01 22:40, Stefano Rivera wrote:
Hi Drew (2023.01.31_18:48:32_-0400)
xrayutilities does have Build-Depends: python3-h5py. Evidentally
dh-python3 isn't able to determine the correct dependency for h5py
(likely it gets confused by python3-h5py-serial). Until that's fixed,
python3-xrayu
Control: reopen 1030220
h5py 3.7.0-4 is uploaded fixing the source of the problem, but
xrayutilities will need to be rebuilt to use the new pydist definitions.
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org,
debichem-de...@lists.alioth.debian.org
Control: affects -1 src:pymatgen
* Package name: python-mp-api
Version : 0.27.3
Upstream Contact: Jason Munro
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org,
debichem-de...@lists.alioth.debian.org
* Package name: python-emmet
Version : 0.36.4
Upstream Contact: Jason Munro
* URL : https
Package: python3-duecredit
Followup-For: Bug #1030408
Control: forwarded -1 https://github.com/duecredit/duecredit/pull/184
This bug is affecting unrelated packages, confirming the Severity:serious.
For instance the new mp_api module tries to read its version using
pkg_resources.get_distribution,
On 2023-02-04 18:02, Adrian Bunk wrote:
Usertags: binnmu
nmu pyfai_0.21.3+dfsg1-2 . ANY . unstable . -m "Rebuild to pick up
python3-h5py dependency (see #1030220)"
nmu unifrac_1.2-3 . ANY . unstable . -m "Rebuild to pick up
python3-h5py dependency (see #1030220)"
nmu xraylarch_0.9.58+ds1-5 . ANY
Package: python3-pymatgen
Version: 2022.11.7+dfsg1-2
Severity: normal
WavecarTest.test_get_parchg (io/vasp/tests/test_outputs.py) fails on
many arches. Oddly, it passes on armel and armhf (and, less
surpirisingly, amd64).
The ubiquity of the error suggests it's a specific code problem that
can b
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
On 2023-02-09 15:02, Andreas Tille wrote:
Control: tags -1 help
Am Thu, Feb 09, 2023 at 12:50:45AM +0100 schrieb Santiago Vila:
Package: src:umap-learn
Version: 0.4.5+dfsg-3
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in bookworm, your package failed to
bu
On 2023-02-09 20:37, Andreas Tille wrote:
Hi again,
Am Thu, Feb 09, 2023 at 05:52:13PM +0100 schrieb Andreas Tille:
> That said, the np.matrix discrepancy was only just fixed recently, in
> December, by
> https://github.com/lmcinnes/umap/pull/946
I've updated the packaging, added the PR, fixe
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
On 2022-09-08 10:19, Sebastian Ramacher wrote:
On 2022-09-04 10:02:53 +0200, Drew Parsons wrote:
All uploads are done now. Let the binNMUs rip.
The rebuilds have been done. The transition is now blocked on #1019287.
Bug#1019287 is now fixed, all new builds have now migrated to testing
On 2022-09-19 12:47, Sebastian Ramacher wrote:
On 2022-09-19 11:54:36 +0200, Drew Parsons wrote:
This transition can be considered done, if we're happy with the state
of
rheolef reported by
https://release.debian.org/transitions/html/auto-mumps.html
https://buildd.debian.org/s
On 2022-09-22 10:07, Sebastian Ramacher wrote:
On 2022-09-19 13:28:21 +0200, Drew Parsons wrote:
On 2022-09-19 12:47, Sebastian Ramacher wrote:
> On 2022-09-19 11:54:36 +0200, Drew Parsons wrote:
> > This transition can be considered done, if we're happy with the
> >
On 2022-09-22 10:07, Sebastian Ramacher wrote:
On 2022-09-19 13:28:21 +0200, Drew Parsons wrote:
On 2022-09-19 12:47, Sebastian Ramacher wrote:
> On 2022-09-19 11:54:36 +0200, Drew Parsons wrote:
> > This transition can be considered done, if we're happy with the
> >
ll
request.
https://salsa.debian.org/science-team/getfem/-/merge_requests/3
I can also add the transition to a newer mumps in the same branch if
you like.
Best regards
Konstantinos
On Thu, Sep 22, 2022 at 2:12 PM Drew Parsons
wrote:
On 2022-09-22 10:07, Sebastian Ramacher wrote:
On 2022-09-19 13:2
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
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
libhdf5_open
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Science List
* Package name: dolfinx-mpc
Version : 0.5.0.post0
Upstream Contact: Jørgen S. Dokken
* URL : https://github.com/jorgensd/dolfinx_mpc
* License
The hypre/petsc part of this transition is complete.
The sundials part is waiting for dyssol to be patched. Anton is
preparing this.
Drew
On 2022-11-29 23:34, Sebastian Ramacher wrote:
Control: tags -1 confirmed
Hi Drew
On 2022-11-29 12:16:55 +0100, Drew Parsons wrote:
Package
On 2022-12-31 17:59, Anton Gladky wrote:
Hi Sebastian,
thanks for noting it! #1027402 is fixed now in unstable (that was wrong
version
in Breaks+Replaces).
Am Sa., 31. Dez. 2022 um 14:20 Uhr schrieb Sebastian Ramacher
:
It's now in unstable. Please also fix #1027402.
Looks like deal.ii
Package: libruby3.0
Version: 3.0.4-8
Severity: normal
A new ruby-dbm package was recently created to resolve Bug#1027407
(dhelp Depends: ruby-dbm)
But libruby3.0 still declares Provides: ruby-dbm (= 1.1.0)
and so the new ruby-dbm 1.1.0-2 doesn't actually get installed by a
standard upgrade.
I gu
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: dh-python
Version: 5.20221230
Severity: normal
Our pyproject (PEP517) build system now seems to be operating
reliably. Using the old default system with setup.py, we now get
reminded that it is deprecated. In some cases the old default setup
method is even "harmful" in the sense of runn
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.
Source: mplcursors
Version: 0.5.2-1
Severity: serious
Justification: debci
mplcursors Build-Depends:libopenblas0
This is bad for several reasons.
Firstly, OpenBLAS is not available on all architectures. In particular
it's not available on armel (and mipsel), and therefore debci testing
on armel
Actually looking more closely at the source, mplcursors doesn't even use
BLAS at all.
In that case just remove the libopenblas0 dependency altogether (both
Build-Depends: and Depends: for the binary package).
Package: dh-python
Followup-For: Bug #1027864
Mind you, the build module for PEP517 builds seems not to give good
control of build and build-temp dirs. For example, the temp dir for
building python extensions gets placed in build rather than .pybuild,
which is not in the spirit of the pybuild too
Source: python-dmsh
Followup-For: Bug #1027230
I can't reproduce this error. debci tests are passing fine on all
architectures.
On 2022-11-06 15:22, Gilles Filippini wrote:
h5pcc is showing an unexpected default configuration:
$ h5pcc --showconfig
gcc -I/usr/include/hdf5/openmpi
-L/usr/lib/x86_64-linux-gnu/hdf5/openmpi
/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.a
/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-googleapis-enterprise-certificate-proxy
Version : 0.1.0
Upstream Author : Andy Zhao
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-google-go-pkcs11
Version : 0.2.0-1
Upstream Author : Google
* URL : https://github.com/google/go-pkcs11
* License : Apache-2.0
Programming Lang: Go
Description : Go
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
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-max-sum-base32768
Version : 0.0~git20191205.7937843-1
Upstream Author : Max Sum
* URL : https://github.com/Max-Sum/base32768
* License : Expat
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-artyom-mtab
Version : 1.0.0-1
Upstream Author : Artyom Pervukhin
* URL : https://github.com/artyom/mtab
* License : Expat
Programming Lang: Go
Description : Package to
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-buengese-sgzip
Version : 0.0~git20220517.9bca1b6-1
Upstream Author : Sebastian Bünger
* URL : https://github.com/buengese/sgzip
* License : Expat
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-colinmarc-hdfs
Version : 2.3.0-1
Upstream Author : Colin Marc
* URL : https://github.com/colinmarc/hdfs
* License : Expat
Programming Lang: Go
Description : A native go
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-jcmturner-gokrb5
Version : 8.4.3-1
Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/gokrb5
* License : Apache-2.0
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-hirochachacha-go-smb2
Version : 1.1.0-1
Upstream Author : xHiroshi Ioka
* URL : https://github.com/hirochachacha/go-smb2
* License : BSD-2-clause
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
Control: block 1024470 by -1
* Package name: golang-github-geoffgarside-ber
Version : 1.1.0-1
Upstream Author : Geoff Garside
* URL : https://github.com/geoffgarside/ber
* License : BSD-3-clause
On 2022-11-21 10:10, Alastair McKinstry wrote:
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry
X-Debbugs-Cc: debian-de...@lists.debian.org,
debian-scie...@lists.debian.org
* Package name: fiat
Version : 1.0.0
Upstream Author : ECMWF
* URL : https://gith
Source: scipy
Followup-For: Bug #1020561
We could consider creating a pythran-free build of the package,
providing an alternative via Conflicts/Replaces.
As you noted, it would require some effort to get the management of
the alternative build in place to run alongside the default build.
But it c
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-iguanesolutions-go-systemd
Version : 5.1.0-1
Upstream Author : Iguane Solutions
* URL : https://github.com/iguanesolutions/go-systemd
* License : Expat
Programming Lang: Go
On 2022-11-21 13:10, Alastair McKinstry wrote:
On 21/11/2022 11:28, Drew Parsons wrote:
On 2022-11-21 10:10, Alastair McKinstry wrote:
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry
X-Debbugs-Cc: debian-de...@lists.debian.org,
debian-scie...@lists.debian.org
* Package name
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-rclone-ftp
Version : 1.0.0-210902h-1
Upstream Author : Julien Laffaye
* URL : https://github.com/rclone/ftp
* License : ISC
Programming Lang: Go
Description : FTP
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: golang-github-dop251-scsu
Version : 0.0~git20220106.84ac880-1
Upstream Author : Dmitry Panov
* URL : https://github.com/dop251/scsu
* License : Expat
Programming Lang: Go
Description
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: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: Anton Gladky
We'd like to update the numerical library stack in time for the new
stable release.
Affected libraries are
hypre2.25.0 -> 2.26.0
petsc/slepc3.17
Looks like adios2 has a formidable number of dependencies through
libevpath.
We should push it through this year. Thanks for the preliminary work.
Drew
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org, Piotr Ożarowski
* Package name: accessible-pygments
Version : 0.0.2
Upstream Contact: Tania Allard
* URL : https://github.com/Quansight-Labs/accessible-pygments
* License : BSD
Pr
Package: cython3
Version: 0.29.32-2
Followup-For: Bug #686045
Control: severity -1 important
Control: affects -1 src:scipy
This bug is 10 years old!
It's still current, affecting the new build system meson. scipy has
recently started meson, so this debian problem has triggered the scipy
issue ht
On 2023-01-18 22:31, Rebecca N. Palmer wrote:
This "broken by numpy 1.24" bug looks to me like 17033, not 17630.
This has what looks like a trivially-backportable patch, though I
haven't actually tried that:
https://github.com/scipy/scipy/pull/17035
We can try applying that patch to scipy 1.8
Control: affects -1 src:scipy
scipy 1.10 has started using sphinx-design for its docs. The scipy doc
build is a bit crippled without this package.
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.
affects 960339 src:fenics-dolfinx
thanks
VTX support in dolfinx requires adios2
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
On 2023-01-25 16:25, Andreas Tille wrote:
Am Wed, Jan 25, 2023 at 04:23:58PM +0100 schrieb Andreas Tille:
I'm just building an according package locally and will hopefully
upload
soon.
... but Drew Parsons seems to have beaten me. ;-)
Thanks also to Drew
Andreas.
heh yeah, I was
Package: emcee
Version: 3.1.3-1
Severity: normal
scipy 1.10 is now available in experimental.
emcee 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 Seve
Package: emperor
Version: 1.0.3+ds-7
Severity: normal
scipy 1.10 is now available in experimental.
emperor 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: gammapy
Version: 1.0-2
Severity: normal
scipy 1.10 is now available in experimental.
emperor 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 Seve
Package: gudhi
Version: 3.6.0+dfsg-4
Severity: normal
scipy 1.10 is now available in experimental.
gudhi 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 S
Package: gwcs
Version: 0.18.3-1
Severity: normal
scipy 1.10 is now available in experimental.
gwcs 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 Severit
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-cooler
Version: 0.8.11-7
Severity: normal
scipy 1.10 is now available in experimental.
python-cooler 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 w
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: python-skbio
Version: 0.5.8-2
Severity: normal
scipy 1.10 is now available in experimental.
python-skbio 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
Package: q2-metadata
Version: 2022.8.0-1
Severity: normal
scipy 1.10 is now available in experimental.
q2-metadata 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: q2-quality-control
Version: 2022.11.1-2
Severity: normal
scipy 1.10 is now available in experimental.
q2-quality-control 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, th
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-26 13:35, Graham Inggs wrote:
Hi Drew, Andreas
...
scipy/1.8.1-22 and numpy/1:1.24.1-2 have just migrated to testing, so
please go ahead with uploading scipy 1.10 to unstable when you're
ready.
...
The experimental pseudo excuses for scipy 1.10.0-1exp6 [1] look good
to me, only 12
On 2023-01-26 14:32, Graham Inggs wrote:
I'll try to wait for scipy's own tests (armel, riscv64) before
uploading
to unstable.
riscv64 is not a release architecture (yet) and the hardware is still
a little slow, so it is not enabled for experimental pseudo excuses.
True. armel is the main
701 - 800 of 2488 matches
Mail list logo
