Hi Nicolas
On Sat, 26 Apr 2025 at 15:04, Nicolas Boulenguez wrote:
> The package list generated by v3 looks correct.
> I agree that older libraries, if any, should also be reported.
Thanks for confirming! I've committed the change to the gnat-14
tracker, and moved it to 'old' so we can re-use i
Hi Nicolas
I have prepared two variations of the gnat-14 tracker.
The first [1], has
is_bad = !.depends ~ /libgnat-14/;
instead of
is_bad = .depends ~ /libgnat/ & !.depends ~ /libgnat-14/;
but this has even more packages in the 'unknown' state (there are
matches for both is_good and is_bad).
Control: reopen -1
The autopkgtest still times out in the salsa pipeline [1].
It is not clear to me whether #1101992 is now fixed, or whether a new
bug needs to be filed for the failing import.
I've copied what I hope is the relevant part of a pipeline job [2] below.
[1] https://salsa.debian.o
Hi Michael
On Sat, 12 Apr 2025 at 12:04, Graham Inggs wrote:
> I'd prefer MIchael to go ahead with 2024.05.001-2 to unstable, but I'm
> also happy to upload 2022.11.001-4 which I was working on previously.
I'll assume you are not working on uploading 2024.05.001-2 to uns
Control: severity -1 important
The autopkgtest of python-sparse 0.16.0a9-1 seems to be passing on
arm64 now, and numba is not yet built on s390x.
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:numba
numba is only supported on amd64 and arm64 upstream.
Please remove the binary packages on the other architectures.
Control: reopen -1
> Hi, this bug isnt reploducible for me.
I was able to reproduce it in trixie now by doing:
apt install glue-sprite
> And the piuparts status is ok
The string 'SyntaxWarning' can still be found in the latest piuparts
log [1], from 2024-12-23 16:58:10 GMT.
[1] https://piup
Hi Nicolas
On Sat, 29 Mar 2025 at 16:18, Nicolas Boulenguez wrote:
> Should I upload gprbuild despite the freeze, or wait for first dot
> release? In the first case, should I wait after this bug is closed
> and open a distinct one? do an intermediate upload to experimental?
Please go ahead and
Control: severity -1 important
0.61.0+dfsg-1 and 0.61.2+dfsg-1 built successfully on arm64.
numba's binaries should probably be removed on mips64el.
Hi Santiago and Michael
On Fri, 11 Apr 2025 at 00:03, Santiago Vila wrote:
> If it's a matter of uploading the current version in experimental
> to unstable, I'd prefer Graham to do it, since he is the one who
> authored the experimental versions.
No, that was Michael. I did look at uploading 2
Control: severity -1 important
This test passed on retry. I am downgrading the severity for now to
allow cp2k to migrate testing. The severity can be raised again if
the test proves to be flaky.
2025.1-1 2025-04-11 07:11:52 UTC
cp2k/2025.1-1
src:cp2k from unstable
2h 56m 43s pass
Source: patchelf
User: debian-m...@lists.debian.org
Usertags: mips64el
X-Debbugs-Cc: debian-m...@lists.debian.org
X-Debbugs-Cc: Sergio Durigan Junior
Version: 0.18.0-1.2
Severity: serious
Tags: ftbfs
Hi Maintainer
The recent upload of patchelf 0.18.0-1.2 FTBFS on mips64el [1]. I've
copied what
Helpful people on # debian-python pointed to this part of the log:
make[1]: Leaving directory '/build/reproducible-path/esys-particle-2.3.5+dfsg2'
dh_installchangelogs -a
dh_installman -a
dh_python3 -a
E: dh_python3 dh_python3:198: no package to act on (python3-foo or one
with ${python3:D
Source: bbmap
Version: 39.18+dfsg-1
Severity: serious
Hi Maintainer
bbmap has a dependency on openjdk-17-jre-headless, which will not be
part of trixie, see #1102113
Regards
Graham
Control: tags -1 + patch
The patches below should fix the autopkgtests, however they are
untested since running into #1101992.
--- a/debian/rules
+++ b//debian/rules
@@ -14,8 +14,11 @@
%:
dh $@ --with python3
-export OMPI_MCA_plm_rsh_agent=/bin/false#workaround
to start MP
Source: esys-particle
Version: 2.3.5+dfsg2-8
Severity: serious
Tags: ftbfs
Hi Maintainer
When built with Python 3.13 only, esys-particle builds successfully,
but then the resulting package does not seem to be functioning
correctly and the autopkgtests time out (see #946206).
Comparing the binary
Source: esys-particle
Version: 2.3.5+dfsg2-7
Hi Maintainer
The commit "Disable autopkgtests on 32 bit archs" [1], also disables
autopkgtests on s390x, which is not a 32-bit architecture.
Regards
Graham
[1]
https://salsa.debian.org/science-team/esys-particle/-/commit/33020280d9694c14f94523c0a0
Control: reopen -1
Hi Bastian
While adjusting the version of the onetbb would avoid the FTBFS in
r-cran-rcppparallel right now, if onetbb ever gets an update in
stable, a backport, a +really upload, or an epoch, then
r-cran-rcppparallel will FTBFS again.
This really needs to be fixed in r-cran-r
Source: r-cran-rcppparallel
Version: 4:8.5.0-1
Severity: serious
Tags: ftbfs
Hi Maintainer
r-cran-rcppparallel FTBFS when rebuilt for onetbb 2022.1.0-1~exp1.
Note the non-numeric part of the version string.
I've copied what I hope is the relevant part of the log [1] below.
Regards
Graham
[1]
Source: mariadb
Version: 1:11.8.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-03-30, mariadb's autopkgtest
regressed in testing [1]. I've copied what I hope is the relevant
part of the log below.
Regards
Graham
[1] https://ci.de
Hi Nicolas
On Fri, 28 Mar 2025 at 18:06, Nicolas Boulenguez wrote:
> As far as I understand, the only remaining blocker is #1100461 (ghdl).
That seems to be uploaded already, 5.0.1+dfsg-1 is currently binNEW.
> I wonder why gprbuild libgnatcoll libgnatcoll-bindings libgnatcoll-db
> are orange i
I think I see the problem.
The test run on 2025-01-29 03:55:04 UTC [1] against numpy/1:2.2.2+ds-2
should have failed, and prevented numpy from migrating to testing, but
debian/tests/control has all tests marked 'skip-not-installable'
(please don't do that), so the test result was considered 'neutr
Source: cctbx
Version: 2024.10+ds2+~3.22.1+ds1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime between 2025-01-25 and 2025-02-01, cctbx's autopkgtest
regressed in testing [1]. I've copied what I hope is the relevant
part of the log below.
Regards
It seems the BTS considers that 4.3.0-2 will re-introduce this bug to
testing because the changelog entry for 4.2.1-4 above was dropped from
debian/changelog.
Hi Nicolas
The binNMU of alire was scheduled, but FTBFS on armel and armhf [1].
I assumed this is the same issue reported in #1096181, so I marked the
bug affecting alire and tagged it ftbfs.
For the record, the armel and armhf builds were retried recently with
gcc-14 14.2.0-18 in unstable, but
Hi Nicolas
I've scheduled binNMUs of music123 and topal.
There was a team upload of phcpack instead.
I have not yet scheduled the binNMU of alire. As per the tracker, it
has a build-dependency on libgnatcoll, which has not yet been uploaded
to unstable.
Regards
Graham
Control: reopen -1
This only seems to be fixed in the changelog of rl-accel/0.9.0-6
Control: tags -1 confirmed
Control: retitle -1 transition: gnat
Control: affects -1 = src:gnat
Hi Nicolas
On Thu, 6 Mar 2025 at 19:35, Nicolas Boulenguez wrote:
> All seems ready then.
Great! Please go ahead.
Regards
Graham
Source: python3.12
Version: 3.12.9-1
Severity: serious
python3.12 is superseded by python3.13
ages be marked bad
until they have been rebuilt?
> Ideally, I would copy/paste/adapt v2 by Graham Inggs from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065309#20
> but the link is now broken.
I believe that is how gnat-14.ben was created.
Fortunately, the ben files are mainta
Hi
On Mon, 3 Mar 2025 at 23:39, Xiyue Deng wrote:
> dh-elpa/2.1.7 is blocked from migration due to autopkgtest failures of
> some of the reverse dependencies in testing: el-mock-el, helpful-el,
> yasnippet. Those packages have fixes uploaded to sid, but because they
> depends on dh-elpa, britney
Emilio wrote:
> This is blocking the numpy transition.
I triggered the autopkgtests of sympy/1.13.3-1 in testing with numpy
from unstable, and they passed on armel [1] and ppc64el [2].
I don't think the numpy transition is blocked by this, only sympy
itself by its test failures introduced by the
Source: gubbins
Version: 3.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-01-29, gubbins' autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://ci.debian.n
Source: lintian
Version: 2.121.1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-02-06, lintian's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://ci.debia
Control: reassign -1 wnpp
Control: retitle -1 RFP: emwm -- enhanced motif window manager
Hi Marco
I missed this bug report filed against the mwm binary package.
I'm attempting to reassign it to 'Work-Needing and Prospective Packages' (WNPP).
Would you please would provide the information (licen
Control: tags -1 confirmed
Hi Julian
Please go ahead.
Regards
Graham
Control: severity -1 important
I have filed bug #1096029 requesting removal of cp2k's binaries on
these architectures, lowering severity.
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:cp2k
User: ftp.debian@packages.debian.org
Usertags: remove
Dear FTP Masters
Please remove cp2k's binaries on 32-bit architectures. It no longer
builds there since the MPI default switch from openmpi to mpich on
these architec
It seems someone already tagged all the bugs [1], thanks!
[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org&tag=numpy2
Source: freefem++
Version: 4.14+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-12-26, freefem++'s autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://
Source: scalapack
Version: 2.2.2-1
Tags: patch
Hi Maintainer
I've noticed that test results are ignored during the s390x build,
with the following output:
Tests are hardwired to 4 processes. Only 2 processes were used for the
build, so test failures will be ignored.
I've checked the logs [1], a
Source: python-hdmedians
Version: 0.14.2-5.1
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing d
On Mon, 3 Feb 2025 at 16:17, Andrey Rakhmatullin wrote:
> fpylll
> meep
> pycorrfit
> pyscanfcs
> python-hdmedians
> tiddit
>
> Feel free to file bug reports about missing dh_numpy3 for these.
These all have RC bugs now, thanks.
Source: tiddit
Version: 3.6.1+dfsg-1
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_numpy3
Source: pycorrfit
Version: 1.1.7+nopack-1
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_n
Source: pyscanfcs
Version: 0.3.6+ds-4
Severity: serious
Tags: trixie sid
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
With "fast-histogram: missing dependency on numpy abi" [1] fixed,
fast-histogram now appears on the tracker [2], in green.
Thanks Ole!
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094909
[2] https://release.debian.org/transitions/html/numpy2.html
Source: meep
Version: 1.25.0-4
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_numpy3 call
Source: fpylll
Version: 0.6.3-1
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_numpy3 call
Source: fast-histogram
Version: 0.14-2
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_nump
Control: block -1 by 1094826
Hi Timo
It seems not all affected packages are appearing on the tracker.
>From discussions in # debian-python it was found that at least
astropy-healpix misses a dependency on python3-numpy-abiN, due to
itself missing call to dh_numpy3 [1].
As mentioned in that bug,
Source: astropy-healpix
Version: 1.0.3-1
Severity: serious
Hi Maintainer
This package includes a Python extension module, which uses Numpy via
its binary interface. Such packages must depend on
python3-numpy-abiN.
If the package is using debhelper, this problem is usually due to a
missing dh_nu
Control: reopen -1
Hi
This bug was closed in cmake, however the autopkgtests of lfortran [1]
are still failing in testing.
Regards
Graham
[1] https://ci.debian.net/packages/l/lfortran/testing/arm64/
Source: python-einops
Version: 0.8.0-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/
Source: python-pyvista
Version: 0.44.1-10
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.n
Source: parallax
Version: 1.0.6-4
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packa
Source: patroni
Version: 3.3.5-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packag
Hi Markus
* Markus Blatt [250109 16:24]:
> the binary rebuild for version 2024.10+ds-3+b3 on January 7 failed on all
> architectures, see [1]
> and particularly [2] for amd64. The rebuilds were probably done for the
> python3.13 as default
> transition [3].
Looking at the transition tracker [1
I think this is due to the openturns FTBFS (see #1091444).
Hi Abou
On Tue, 7 Jan 2025 at 19:48, Abou Al Montacir wrote:
> The issue here is that the test machine is running FPC 3.2.2+dfsg-34 while
> the new CGE 7.0~alpha.3+dfsg1-4 requires FPC 3.2.2+dfsg-35 (which is a but by
> itself).
>
> I'll upload a new version enforcing this dependency and closin
Source: cluster3
Version: 1.59+ds-6
Severity: serious
Tags: ftbfs
Hi Maintainer
cluster3 is non-free and is not auto-buildable, so requires a manual
rebuild for the Python 3.13 transition. Please upload a build with
Python 3.13 as default, including binaries.
Regards
Graham
Source: castle-game-engine
Version: 7.0~alpha.3+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-12-17, castle-game-engine's autopkgtest regressed
in testing [1]. I've copied what I hope is the relevant part of the
log below.
Reg
Source: digikam
Version: 4:8.5.0-1
Severity: serious
Tags: ftbfs
Hi Maintainer
As can be seen in reproducible builds [1], digikam currently FTBFS in unstable.
I believe this is due to the following in debian/control:
Build-Conflicts: imagemagick-6-common
While imagemagick-6-common is now a vir
Control: severity -1 important
Control: tags -1 + unreproducible
Hi Emmanuele
mfem builds for arm64 succeeded recently on the builds [1] and on
reproducible builds [2].
Would you please check whether it still fails for you?
I suspect your previous build happened during the openmpi transition.
Control: tags -1 confirmed
Hi Matthias
On Thu, 2 Jan 2025 at 10:09, Matthias Klose wrote:
> Tracker issue for the already created transition.
Please go ahead.
Regards
Graham
On Mon, 6 Jan 2025 at 07:12, Aurélien COUDERC wrote:
> could you please remove kmymoney from testing to unblock the kdiagram
> transition ?
Removal hint for kmymoney/5.1.3-1 added.
This issue seems to be fixed upstream now:
https://github.com/bcgsc/btllib/issues/80
Source: esys-particle
Version: 2.3.5+dfsg2-8
Hi Maintainer
Since the upload of 2.3.5+dfsg2-8, esys-particle has been failing its
own autopkgtests in Ubuntu [1]. I've copied what I hope is the
relevant part of the log below.
I believe this is related to the dropping of '--oversubscribe' in a
rec
Source: r-cran-seurat
Version: 5.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 5.1.0-1, r-cran-seurat has been failing its own
autopkgtests on riscv64 [1] and s390x [2] where it succeeded
previously.
I've copied what I hope is the
Control: affects -1 + src:r-cran-lwgeom
It seems at least r-cran-lwgeom needs updating to 0.2-14 for
compatibility with the new r-cran-sf [1].
version 0.2-14
st_perimeter() is deprecated in favor of st_perimeter_lwgeom(), as sf
takes over with sf::st_perimeter().
[1] https://cran.r-project.org
Source: pbsuite
Version: 15.8.24+dfsg-8
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-12-26, pbsuite's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
This regression allowed blasr/
Hi Aurélien
On Mon, 30 Dec 2024 at 07:45, Aurélien COUDERC wrote:
> could you please remove kaidan from testing ?
> It depends on the Qt5 version of kquickimageeditor and is preventing the
> Qt6 version to migrate to testing.
>
> Upstream doesn’t have a Qt6 compatible version of kaidan ready yet.
Source: gtg-trace
Version: 0.2-3-3
Tags: patch
Hi Maintainer
gtg-trace does not honour the 'nocheck' build option, and 'make -C
test check' is always executed.
Please modify debian/rules with something similar to the patch below,
or bump debhelper-compat (= 13), where this is done automatically.
Source: swig
Version: 4.2.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-02-28, swig's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://ci.debian.net/
Control: reopen -1
This is not yet solved. The autopkgtests are still failing in testing [1].
[1] https://ci.debian.net/packages/r/r-cran-sf/testing/amd64/
104s Some packages could not be installed. This may mean that you have
104s requested an impossible situation or if you are using the uns
Control: severity -1 important
Control: tags -1 + unreproducible
Hi Emmanuele
elkcode builds for arm64 succeeded recently on the builds [1] and on
reproducible builds [2].
Would you please check whether it still fails for you?
I suspect your previous build happened during the openmpi transition
Source: oxigraph
Version: 0.4.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-08-12, oxigraph's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://ci.deb
Control: severity -1 important
Control: tags -1 + unreproducible
Hi Emanuele
I am unable to reproduce this failure on a porterbox. I also tried on
reproducible builds, but the build failed due to a test timeout, which
I think is unrelated.
Would you please check whether it still fails for you?
Author: Graham Inggs
Last-Update: 2024-12-19
--- a/questplus/tests/test_qp.py
+++ b/questplus/tests/test_qp.py
@@ -435,11 +435,11 @@
next_stim_1 = qp.next_stim['physical_magnitude_stim_1']
next_stim_2 = qp.next_stim['physical_magnitude_stim_2']
-if
Hi Emanuele
On Tue, 17 Dec 2024 at 08:25, Emanuele Rocca wrote:
> It seems that valgrind is currently building fine on both armhf and i386
> with mpi-defaults 1.17:
>
> https://people.debian.org/~ema/valgrind_armhf-2024-12-17T09:07:39Z.build
> https://people.debian.org/~ema/valgrind_i386-2024-12-
Please note that this also needs to be fixed in debian/tests/control
for the autopkgtest [1]. See below.
[1] https://ci.debian.net/packages/l/lilypond/testing/amd64/
39s The following packages have unmet dependencies:
39s satisfy:command-line : Depends: imagemagick-6.q16 but it is not installa
Control: tags -1 + patch
The attached patch was applied in Ubuntu.
From: Anshul Singh
Date: Wed, 11 Dec 2024 14:05:50 +0530
Subject: Patch to stop generating nan values in tests to work with latest attrs
Origin: upstream, https://github.com/python-attrs/cattrs/commit/96ed9a1c972814c379f9ea8faa34
Source: python-voip-utils
Version: 0.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 0.2.1-1, python-voip-utils fails its own
autopkgtest [1] on s390x (big-endian). I've copied what I hope is the
relevant part of the log below.
Thi
On Thu, 12 Dec 2024 at 13:55, Andrey Rakhmatullin wrote:
> Looks like the package only builds for the default Python version, I
> rebuilt it as is (as it wasn't binNMUed) and it still doesn't contain 3.13
> binaries. It uses cmake to build a single set of .so.
If tomopy cannot build for all suppo
Source: dulwich
Version: 0.21.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-12-11, dulwich's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
This regression allowed dulwich/0.22
Source: pylint
Version: 3.3.1-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/package
Control: severity -1 serious
Control: tags -1 + ftbfs
imagemagick-6.q16 is no longer in testing, so therion FTBFS there.
Control: severity -1 serious
Control: tags -1 + ftbfs
imagemagick-6.q16 is no longer in testing, so lilypond FTBFS there.
Control: severity -1 serious
Control: tags -1 + ftbfs
imagemagick-6.q16 is no longer in testing, so castle-game-engine FTBFS there.
Source: mpich
Version: 4.2.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
The upload of mpich 4.2.1-2 is failing its own autopkgtests [1]. I've
copied what I hope are the relevant parts of the log below.
This regression prevents mpich 4.2.1-2 from migr
Source: python-rosettasciio
Version: 0.6-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertag: python3.13
Hi Maintainer
python-rosettasciio Build-Depends on python3-all-dev, but doesn't
build for all supported python3 versions.
I've copied below a portion of a recent amd64 build log
Hi Andrius
On Mon, 9 Dec 2024 at 08:54, Andrius Merkys wrote:
> dials autopkgtest apparently does not pull in the dependency on
> python3-gemmi. I think python3-dials should have 'Depends: python3-gemmi'.
Upstream's changelog mentions "gemmi-less objects can be used by other
gemmi-less software"
Source: dials
Version: 3.17.0+dfsg3-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2024-09-30, dial's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] https://ci.deb
Source: mpich
Version: 4.2.1-2
Severity: important
Hi Maintainer
The recent upload to unstable re-used a version number that was
previously used in experimental.
I'm surprised dak allowed this, and I'm not sure what problems it
might cause in Debian, but it did cause the wrong version to be sync
Source: celery
Version: 5.4.0-2.1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packa
Source: xraylib
Version: 4.0.0+dfsg1-5
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/
Source: ubelt
Version: 1.3.6-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages
Source: tomopy
Version: 1.15.0+ds1-8
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/pa
Source: spyder
Version: 5.5.1+ds-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/pack
Source: supervisor
Version: 4.2.5-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.13
Hi Maintainer
The autopkgtests of this package fail with Python 3.13 [1]. I've
copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/pac
1 - 100 of 1681 matches
Mail list logo
