Source: cppimport
Followup-For: Bug #1071993
test_multiple_processes is now skipped in 22.08.02-3 and -4, but
that's just a workaround to avoid having to remove the package.
It shouldn't be considered a solution to the problem.
Source: cppimport
Version: 22.08.02-2
Severity: important
Control: forwarded -1 https://github.com/tbenthompson/cppimport/issues/90
cppimport has started failing debci tests on most (if not all)
architectures:
112s ___ test_multiple_processes
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
On 2024-05-25 18:31, Santiago Vila wrote:
El 25/5/24 a las 16:42, Drew Parsons escribió:
adios4dolfinx is building cleanly in reproducibility builds.
Perhaps the problem was a temporary glitch on your test system?
No, this is unlikely to be a temporary glitch:
...
My system has 2 CPUs
Control: retitle 1061243 needs update for xsimd 13
Now xsimd 13 is available.
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?
Source: satpy
Version: 0.48.0-2
Severity: normal
scipy 1.12 is triggering test failure on arm64
https://ci.debian.net/packages/s/satpy/unstable/arm64/46960923/
https://ci.debian.net/packages/s/satpy/unstable/arm64/
amd64 is passing without error.
The errors seem to come from _netCDF4.pyx
Does
On 2024-05-24 15:41, Georges Khaznadar wrote:
Hello Drew,
I could not reproduce with my machine the issue which you are
describing:
- I installed python3-scipy 1.12.0-1exp3 over 1.11.4-10
- I launched the test suite :
$ cd ~//pysatellites
~//pysatellites$ make
pyuic5 pysat.ui -o
Source: pysatellites
Version: 2.7-2
Severity: important
pysatellites is failing tests with segfault against scipy 1.12 (from
experimental) and python3.11.
157s = test session starts
==
157s platform linux -- Python 3.11.9, pytest-8.1.2,
Error is
38s Traceback (most recent call last):
38s File "/usr/lib/python3.11/multiprocessing/pool.py", line 125, in
worker
38s result = (True, func(*args, **kwds))
38s ^^^
38s File "/usr/lib/python3/dist-packages/scoary/methods.py", line
1267,
Source: uc-echo
Version: 1.12-18
Severity: normal
uc-echo uses a deprecated scipy API that fails with scipy 1.12
24s autopkgtest [20:33:32]: test runtest: [---
24s Test for sample data
25s Traceback (most recent call last):
25s File
Source: gammapy
Version: 1.1-4
Severity: normal
gammpy appears to be using a deprecated RootResults API that fails
with scipy 1.12
92s ERROR collecting test session
_
92s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
92s
Source: scoary
Version: 1.6.16-6
Severity: normal
scoary uses a deprecated scipy.stats API (binom_test) which causes it
to fail tests with scipy 1.12.
This bug will become serious when scipy 1.12 is uploaded to unstable
in the near future.
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
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
On 2024-05-15 09:20, Sebastian Ramacher wrote:
I think the best way to deal with it is to pretend it never happened
and move on with petsc 3.20, upgrading from petsc 3.19. We'd want to
doing this upgrade anyway.
Please go ahead.
All uploads have been made now (including dolfin). Just
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?
Package: paraview
Followup-For: Bug #842405
Control: tags 842405 moreinfo
HDF5 is a general data format, it has no natural viewing format.
When you load a file into paraview you need to specify which reader
you want to open it with. Which reader are you expecting to use with
your .h5 file?
Your
Package: paraview
Followup-For: Bug #820453
"Help -> ParaView Guide" now (5.11.2) provides a (functioning) url
link to https://docs.paraview.org/en/v5.11.2/
which opens normally in the web browser.
Not so helpful if you don't have internet access, but at least it's
not giving an error now.
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)
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
On 2024-05-15 10:00, Drew Parsons wrote:
On 2024-05-15 09:20, Sebastian Ramacher wrote:
While looking at the tracker, I noticed that petsc is still building
manual -dbg packages. IS there a reason that those have not been
converted to automatic -dbgsym packages?
No, it's not about symbols
On 2024-05-15 09:20, Sebastian Ramacher wrote:
Control: tags -1 confirmed
The petsc patch for the 64-bit time_t transition was deeply invasive.
It makes petsc (and slepc) essentially unmaintainable.
I think the best way to deal with it is to pretend it never happened
and move on with petsc
Source: hypre
Followup-For: Bug #1069321
It's passing in reproducibility rebuilds.
Perhaps it was a transitory glitch.
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.
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
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.
Source: scipy
Followup-For: Bug #1069377
Control: tags -1 ftbfs
This is an odd error. Looks as if the behaviour changed in respect to
which exception gets emitted.
There's a new release needing to get packaged. Likely it resolves the
issue.
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
Source: openmpi
Version: 4.1.6-12
Followup-For: Bug #1069106
Control: reopen 1069106
4.1.6-12 was intended to fix this bug, but it's still occuring
e.g.
https://ci.debian.net/packages/o/openmpi/unstable/i386/45630865/
https://ci.debian.net/packages/o/openmpi/unstable/armhf/45630866/
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?
Source: openmpi
Version: 4.1.6-9
Severity: serious
Justification: ftbfs
Control: affects -1 src:fenics-dolfinx src:petsc
openmpi 4.1.6-9 is failing its own tests on 32-bit systems,
presumeably after they were configuring to use a local copy of pmix
instead of libpmix-dev.
For instance on i386
Source: dolfinx-mpc
Followup-For: Bug #1062383
Control: severity 1062383 important
Control: tags 1062383 moreinfo
This patch was never applied. Do we not need it after all? Can we
close this bug now?
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?
Source: scikit-build-core
Followup-For: Bug #1068661
I think dh_python3 is not adding the dependency automatically since
it's listed in pyproject.toml under pyproject (optional dependency).
Hence it'd need to be added manually.
pathspec is listed there too so I figure it would probably want to
Package: python3-scikit-build-core
Version: 0.8.2-1
Severity: normal
scikit-build-core imports pyproject_metadata in
/usr/lib/python3/dist-packages/scikit_build_core/settings/metadata.py
but the python3-scikit-build-core does not declare the corresponding
Depends: python3-pyproject-metadata
So
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.
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
Package: libpmix2t64
Version: 5.0.2-2
Followup-For: Bug #1067784
Control: affects 1067784 nwchem nwchem-openmpi
Control: reopen 1067784
Looks like 5.0.2-2 annihilated the symlink fix made in 5.0.2-1.1
See nwchem tests,
https://ci.debian.net/packages/n/nwchem/unstable/amd64/44696719/
90s
Package: nanobind-dev
Version: 1.9.2-1
Followup-For: Bug #1067085
The path discrepancy comes from the cmake build, with CMakeLists.txt
defining installation path NB_INSTALL_DATADIR via
CMAKE_INSTALL_DATADIR (which is /usr/share).
The upstream installation instructions don't mention cmake (they
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.
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: pymatgen
Followup-For: Bug #1064749
Control: tags -1 ftbfs
I can't reproduce this error.
See also
https://buildd.debian.org/status/fetch.php?pkg=pymatgen=amd64=2024.1.27%2Bdfsg1-7=1708967242=0
Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: pymat...@packages.debian.org
Control: affects -1 + src:pymatgen
User: ftp.debian@packages.debian.org
Usertags: remove
A FTBFS problem with rust-python-pkginfo on mips64el (Bug#1066972) is
resulting in a long chain of packages
Source: rust-python-pkginfo
Version: 0.5.5-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
rust-python-pkginfo is failing to build on mips64el due to a missing
librust-rfc2047-decoder-0.2+default-dev
Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package.
Should the Build
Source: rdma-core
Version: 50.0-2
Severity: normal
rdma-core does not build on minor architectures, since pandoc is not
available.
pandoc is only needed for documentation (man pages). It might be
possible to only build docs for arch-indepdent builds, then using
Build-Depends-Indep: pandoc
In
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-26 07:40, Alastair McKinstry wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: mpi-defau...@packages.debian.org,
debian-scie...@lists.debian.org
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0
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
Package: gnome-core
Version: 1:44+1
Severity: normal
gnome-core is generally useful for maintaining a Gnome desktop
environment. gnome-software is not.
Some people find gnome-software useful, but it is certainly not core
for a Gnome environment when apt is used for package installation.
On the
Package: gnome-software
Version: 46~beta-1
Severity: important
gnome-software is causing packagekit to spam the syslog (and resources
generally). Even if I stop packagekit with
sudo systemctl stop packagekit
gnome-software causes it to immediately restart.
The only workaround is to mask it
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: python-hmmlearn
Version: 0.3.0-3
Severity: serious
Justification: debci
python-hmmlearn is failing variational_gaussian tests
(test_fit_mcgrory_titterington1d) with sklearn 1.4.
This comment upstream is relevant:
https://github.com/hmmlearn/hmmlearn/issues/539#issuecomment-1871436258
Source: imbalanced-learn
Version: 0.10.0-2
Severity: serious
Justification: debci
imbalanced-learn 0.10 fails tests with sklearn 1.4.
The problem is fixed upstrema with v0.12.
Package: clang
Version: 1:16.0-57
Followup-For: Bug #896017
This bug is live again.
Tests of xtensor-blas report:
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ - broken
CMake Error at
Source: masakari
Version: 16.0.0-2
Severity: serious
Justification: debci
Control: affects -1 src:sphinx src:python-skbio src:scipy
masakari has started failing tests:
229s FAIL:
masakari.tests.unit.objects.test_objects.TestObjectVersions.test_versions
229s
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.
Control: severity 1063527 serious
scipy 1.11 is now uploaded to unstable, so bumping this bug severity to
serious
On 2024-02-15 14:20, Andreas Beckmann wrote:
On 14/02/2024 00.37, Drew Parsons wrote:
It would be much easier to switch between versions in unstable and
experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
Source: nvidia-graphics-drivers
Version: 525.147.05-6
Severity: normal
>From time to time the version of nvidia-driver in experimental is far
ahead of the current version in unstable. It's often desirable to
install it to see if the new version fixes particular problems.
The problem is that
Source: hdf5
Followup-For: Bug #1063856
For further context, HDF upstream no longer supports hdf5 1.10, nor
hdf5 1.12 (i.e. no more releases will be made in these series)
see
https://github.com/HDFGroup/hdf5#release-schedule
https://github.com/h5py/h5py/issues/2312
Source: hdf5
Version: 1.10.10+repack-3
Severity: normal
X-Debbugs-Cc: debian-scie...@lists.debian.org
What our situation with our hdf5 package version?
We're currently using hdf5 1.10.10,
but 1.12.2 has been available in experimental for some time,
and upsteam has released 1.14.3.
Should we be
Source: custodian
Followup-For: Bug #1063752
X-Debbugs-Cc: Debichem Team
Control: reassign 1063752 lists.debian.org
Control: affects 1063752 src:custodian
Scott Kitterman reported that lists.alioth.debian.org is bouncing
emails from debian official addresses (ftpmas...@ftp-master.debian.org
in
Source: custodian
Followup-For: Bug #1063752
I am confused by this bug report.
The debichem Maintainer address used for custodian is the same as that
used for any other debichem package. No problems were reported for
the other packages.
Source: python-pynndescent
Version: 0.5.8-2
Severity: normal
Control: block 1061605 by -1
python-pynndescent is failing test_distances with scipy 1.11 from experimental
103s else:
103s > raise ValueError('Unknown Distance Metric: %s' % mstr)
103s E
Evidently fixed upstream with
https://github.com/scikit-bio/scikit-bio/pull/1887
see also https://github.com/scikit-bio/scikit-bio/pull/1930
(for python 3.12)
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: python-skbio
Version: 0.5.9-3
Severity: normal
Control: block 1061605 by -1
python-skbio is failing various tests with scipy 1.11 from experimental
150s FAILED
skbio/diversity/alpha/tests/test_base.py::BaseTests::test_fisher_alpha
150s FAILED
Package: dh-python
Version: 6.20231223
Severity: normal
pybuild operations can be controlled to some extent with environment
variables. which is often more tidy than using override_dh_auto_... in
debian/rules.
The control I want to apply is run the build only for the default python
(adios2, for
Source: einsteinpy
Version: 0.4.0-3
Severity: important
Control: block 1061605 by -1
einsteinpy is failing test_plotting with scipy 1.11 from experimental
143s if disp:
143s msg = ("Failed to converge after %d iterations, value is %s."
143s% (itr + 1, p))
Source: astroml
Version: 1.0.2-2
Severity: important
Control: block 1061605 by -1
astroml is failing test_iterative_PCA with scipy 1.11 from experimental
82s for i in range(n_samples):
82s VWV = np.dot(VT[:n_ev], (notM[i] * VT[:n_ev]).T)
82s >
Source: mdtraj
Followup-For: Bug #1060971
X-Debbugs-Cc: 1060971-d...@bugs.debian.org
Control: fixed 1060971 1.9.9-1
Fixed with cython3-legacy at the same time the bug was filed.
Hi Maytham, golang-github-googleapis-enterprise-certificate-proxy is
now built on the main architectures.
https://buildd.debian.org/status/package.php?p=golang-github-googleapis-enterprise-certificate-proxy
It's still not building on the auxiliary architectures.
Can you see a way of extending
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org,
francesco.balla...@unicatt.it
* Package name: ngspetsc
Version : git HEAD
Upstream Contact: Umberto Zerbinati
* URL : https
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
Source: scipy
Followup-For: Bug #1061605
Note that debci tests are passing on all arches (where built) for
scipy 11.
I'm inclined to accept this as a solution.
i.e. update the list of builds tests to skip for scipy 11
rather than reorganise debian/tests skips for scipy 10.
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),
On 2024-02-05 18:44, Drew Parsons wrote:
building and testing. The scipy team have created pybuild, which uses
That should read "The scipy team have created dev.py" of course.
(debian created pybuild)
On 2024-02-03 21:07, c.bu...@posteo.jp wrote:
I checked upstream README.md.
I have no clue what this is.
Can someone explain please?
Am 03.02.2024 18:05 schrieb dpars...@debian.org:
Package: wnpp
* Package name: pydevtool
* URL : https://github.com/pydoit/pydevtool
Source: pymatgen
Followup-For: Bug #1053939
[apologies for the spam. testing mail server configuration now]
Source: pymatgen
Followup-For: Bug #1053939
Looks like the latest release should be fine with pandas 2.
Currently building in experimental.
block 1061609 by 1052028 1052619
affects 1061609 python3-emmet-core
thanks
The latest version of python-emmet-core (used by pymatgen) requires
pydantic2.
Source: scipy
Followup-For: Bug #1061605
Easy enough to relax tolerances or skip tests if we needed to.
test_maxiter_worsening was giving problems on other arches.
But strange the test only started failing when pythran was deactivated.
I've reactivated it in 1.10.1-8, we'll see if it restores
Package: python3-scipy
Followup-For: Bug #1020561
Confirmed that tests still pass (amd64) if python3-pythran is forcibly
not installed.
Making an audit of where pythran is actually used (in v.10),
at runtime that is:
scipy/interpolate
_rbfinterp_pythran.py
see also setup.py, meson.build
On 2024-01-27 18:28, Francesco Ballarin wrote:
OK Andreas, I'll push to master. Let me take the lead on that, and
I'll come back to you and Drew with progress and questions.
I think I have some ideas on how to get started on the basic package.
Thanks Francesco and Andreas. Will be
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: pydantic-settings
Version : 2.1.0
Upstream Contact: Samuel Colvin
* URL : https://github.com/pydantic/pydantic-settings
On 2024-01-27 09:30, Graham Inggs wrote:
Hi
It seems (at least in scipy/1.10.1-6), that python3-pythran was a
build-dependency for all architectures [1], yet, on armhf,
python3-scipy did not have a runtime dependency on python3-pythran
[2].
The build log of scipy/1.10.1-6 on armhf [3],
On 2024-01-23 14:39, Maytham Alsudany wrote:
Hi Drew,
On Tue, 2024-01-23 at 11:24 +0100, Drew Parsons wrote:
> > Hi Maytham, I can upload it. But note how pkcs11 is failing on 32 bit
> > arches. That needs to be sorted out. I had been waiting for that
> > before up
Source: golang-github-google-go-pkcs11
Version: 0.3.0+dfsg-1
Severity: serious
Justification: debci
Control: block 1024276 by -1
go-pkcs11 tests are failing on 32-bit architectures (armel, armhf, i386),
see https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/
This is preventing
On 2024-01-23 12:20, Andreas Tille wrote:
Hi,
I've seen your commits to DPT on salsa. Do you need any help to
create a debian/ dir which does not exist yet?
Kind regards
Andreas.
Hi Andreas, Francesco has prepared a debian dir in an MR on salsa.
Would be great if you could review the MR
On 2024-01-23 11:08, Maytham Alsudany wrote:
Hi Drew,
On Tue, 2024-01-23 at 09:12 +0100, Drew Parsons wrote:
On 2024-01-23 07:51, Maytham Alsudany wrote:
> Hi Drew,
>
> Now that golang-github-google-go-pkcs11 has been uploaded and accepted,
> is it
> possible for you to now
On 2024-01-23 07:51, Maytham Alsudany wrote:
Hi Drew,
Now that golang-github-google-go-pkcs11 has been uploaded and accepted,
is it
possible for you to now upload
golang-github-googleapis-enterprise-certificate-
proxy?
Hi Maytham, I can upload it. But note how pkcs11 is failing on 32 bit
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: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org,
debian-scie...@lists.debian.org, debichem-de...@lists.alioth.debian.org
* Package name: custodian
Version : 2024.1.9
Upstream Contact: Shyue Ping Ong
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
On 2024-01-19 18:52, Drew Parsons wrote:
Hi Andreas, could you push your upstream and pristine-tar branches?
Otherwise we can't use your 2023.12.18 branch.
I see what you mean. The tag is there, the orig tarball can be
regenerated with
gbp export-orig.
Source: pymatgen
Followup-For: Bug #1058040
No, other way around. The new monty is causing the problem.
Will need to patch or upgrade pymatgen.
1 - 100 of 2372 matches
Mail list logo
