Hi Everyone
I would have hoped that r-cran-rstan's autopkgtests would have caught
this, but looking at the output of a recent test in trixie [1] below,
it seems the autopkgtest is missing a dependency on at least gcc, and
despite the large WARNING, the test is not considered a FAIL.
Regards
Graha
Source: dia
Version: 0.98+git20250126-2
Control: affects -1 + src:ns3 src:xnee
User: debian-xml-sgml-p...@lists.alioth.debian.org
Usertags: libxml2.14
Hi Maintainer
It seems that dia's upstream tests are not run during the build [1],
and dia has no autopkgtests.
dh_auto_test -a
cd obj-x86_64-
It looks like this was fixed upstream in a slightly different way.
https://github.com/MariaDB/server/commit/b02ad4a6f8ea09c5cdf0a44a9ee57a60f2989f48
Source: python-zeep
Version: 4.3.1-2
User: debian-xml-sgml-p...@lists.alioth.debian.org
Usertags: libxml2.14
Hi Maintainer
python-zeep has Build-Depends on libxmlsec1t64 and
libxmlsec1t64-openssl which are not used during the build.
The severity of this bug will become serious when libml2, libx
Control: severity -1 serious
Control: tags -1 + patch
Control: retitle -1 finalcif: autopkgtest regression in testing
Hi Maintainer
Sometime around 2025-03-08, finalcif's autopkgtests regressed in
testing [1]. The relevant part of the log was included when this bug
report was filed.
Regards
Gra
Hi Charles
On Tue, 13 May 2025 at 01:42, Charles Plessy wrote:
> Can you unblock r-cran-bigmemory? It absence from Trixie causes
> autopkgtest failures, with a possible cascade effect of more removal /
> failure / removal cycles.
Unblocked.
Please use the documented procedure 'Applying for an
Source: abseil
Version: 20240722.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-01-10, abseil's autopkgtest regressed in testing
on 32-bit architectures [1][2][3]. I've copied what I hope is the
relevant part of the log below.
Rega
Control: tags -1 moreinfo
Hi Sébastien
On Fri, 9 May 2025 at 16:18, Sébastien Noel wrote:
> [ Reason ]
> This package needed a workaround due to a bug in fuse3/3.17.1
> (released in sid on march 13). I uploaded a fix in osspd 20 days ago.
>
> The bug was finally tackled upstream and fixed in fus
Control: tags -1 moreinfo
Hi Thomas
On Tue, 6 May 2025 at 13:57, Thomas Goirand wrote:
> Please let me know what the release team thinks of this,
1:29.0.0-4 was accepted by ftpmaster but needs a source-only upload
because of the arch:all binaries. Please do this upload, attach the
debdiff agai
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
1 - 100 of 1690 matches
Mail list logo
