Hi Ralf
> A team upload of gringo 5.8.0-1 which fixes FTBFS bug #1112978 is
> sitting in git (master branch). I will upload this to unstable by
> October 12 unless there are any objections.
Please consider adopting this package, or at least adding yourself to Uploaders.
It hasn't seen any activi
Source: tachyon
Version: 0.99~b6+dsx-15
Severity: serious
Hi Maintainer
tachyon 0.99~b6+dsx-15 includes a commit [1] which drops some changes
from the NMU 0.99~b6+dsx-12.1 [2].
Basically, 32-bit architectures have been added again, and loong64 has
been dropped.
Regards
Graham
[1]
https://sal
Hi Emilio
On Sun, 21 Sept 2025 at 17:08, Emilio Pozuelo Monfort wrote:
> If there is a bug, it would be in normaliz, not pynormaliz. I don't think
> reassigning to pynormaliz makes sense in this case. That's only hiding the
> possible ABI break.
Please feel free to re-assign as you see fit.
Reg
Control: severity -1 important
The build succeeded after some retries.
Maybe it was the different buildd? arm-conova-01 vs arm-ubc-*
Interesting that the release notes for pynormaliz [1] state:
The source code of v2.22 is identical to v2.21
I will re-assign this bug to pynormaliz and remove pynormaliz from
testing, in the hopes of unblocking normaliz, macaulay2 and polymake,
and finishing off the flint transition.
[1] https:
Hi Douglas
On Thu, 18 Sept 2025 at 16:15, Torrance, Douglas wrote:
>
> On Thu, 18 Sep 2025 09:00:28 +0200 Paul Gevers wrote:
> > Hi,
> >
> > On 9/17/25 13:42, Jeremy Bícha wrote:
> > >> Did normaliz break the ABI? Or why does pynormaliz's tests fail when
> > >> compiled
> > >> against old norma
Control: tags -1 + patch
The attached patches were applied in Ubuntu.
Description: hlink.c: fix function pointer cast in qsort()
Origin: upstream, https://github.com/backuppc/rsync-bpc/commit/6466b0b0c537d135cf10fecb598bfd6d40194e37
Bug-Debian: https://bugs.debian.org/1096354
Author: Dennis Eisele
Source: powerpc-utils
Version: 1.3.13-1
Severity: serious
Tags: sid forky patch
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-15
Hi Maintainer
powerpc-utils FTBFS when built with GCC 15. I've copied what I hope
is the relevant part of the log below.
This can be avoided by adding the fol
Hi Sebastian
> the autopkgtest of deal.ii fails on riscv64 (maybe due to the trilinos
> transition):
...
> See https://ci.debian.net/packages/d/deal.ii/testing/riscv64/64460939/
> for details.
The log to which you refer, shows that deal.ii from testing was
installed for the autopkgtest:
130s Get
Hi Simon
On Sun, 31 Aug 2025 at 15:07, Simon McVittie wrote:
> I've uploaded 3.4.8-2 invoking Xvfb with -noreset (a workaround for
> #981201) and it built successfully on s390x, ppc64el and mips64el on the
> first attempt, as well as on x86. It hasn't been tried on arm* or
> riscv64 yet, but hope
Source: pytzdata
Version: 2020.1+dfsg-10
Severity: serious
This package is unmaintained, out-of-date and alternatives exist.
Hi Santiago
The following error also appears in logs of successful builds:
Fontconfig error: No writable cache directories
I think the real failure is at:
parser error : Start tag expected, '<' not found
Which has been reported against dia #1107821 [1].
Regards
Graham
[1] https://bugs.debia
Hi Alexandre
On Fri, 5 Sept 2025 at 19:30, Alexandre Detiste
wrote:
> The actual reason is that the gzip'ing of the dia files
> got lost in the Gtk3 rewrite.
>
> I don't think it has anything to do with libxml
That might be a completely different issue.
In Ubuntu, we rebuilt dia 0.98+git2025012
Source: opm-common
Version: 2025.04+ds-1
Severity: serious
Tags: ftbfs patch
User: debian-...@lists.debian.org
Usertags: ieee-long-double
Hi Maintainer
We are working on https://wiki.debian.org/ToolChain/IEEELongDouble
The attached patches (one for opm-common and one for opm-simulators)
were app
Source: dune-common
Version: 2.10.0-4
Severity: serious
Tags: ftbfs patch
User: debian-...@lists.debian.org
Usertags: ieee-long-double
Hi Maintainer
We are working on https://wiki.debian.org/ToolChain/IEEELongDouble
The attached patch was applied in Ubuntu after some discussion with upstream.
R
Source: h5py
Version: 3.14.0-2
Severity: serious
Tags: ftbfs patch
User: debian-...@lists.debian.org
Usertags: ieee-long-double
Hi Maintainer
We are working on https://wiki.debian.org/ToolChain/IEEELongDouble
Please apply the attached patch, originally from Fedora, and applied
in Ubuntu. It dro
Source: numpy
Version: 1:2.2.4+ds-1
Severity: serious
Tags: ftbfs patch
User: debian-...@lists.debian.org
Usertags: ieee-long-double
Hi Maintainer
numpy currently FTBFS when rebuilt with IEEE Long Double on ppc64el [1].
The patch below was applied in Ubuntu.
Regards
Graham
[1]
https://buildd.
Source: boost1.88
Version: 1.88.0-1
Hi Maintainer
I noticed while filing #1113960 that debian/tests/control contains:
Tests: atomic
Depends: libboost-atomic1.83-dev, build-essential, cmake
Tests: chrono
Depends: libboost-chrono1.83-dev, libboost-system1.83-dev,
build-essential, cmake
...
and
Source: boost1.88
Version: 1.88.0-1
Tags: patch
Hi Maintainer
debian/tests/control contains the following:
Architecture: [!armhf]
The invalid syntax causes the marked tests to be skipped on all
architectures, so appears to work as intended.
I guess what you wanted is:
Architecture: !armhf
Rega
Source: boost1.83
Version: 1.83.0-4
Tags: patch
Hi Maintainer
debian/tests/control contains the following:
Architecture: [!armhf]
The invalid syntax causes the marked tests to be skipped on all
architectures, so appears to work as intended.
I guess what you wanted is:
Architecture: !armhf
Rega
Source: pd-midifile
Version: 0.4.2-1
Tags: patch
Hi Maintainer
debian/tests/control contains the following:
Architecture: [!s390x]
The invalid syntax causes the marked tests to be skipped on all
architectures, so appears to work as intended.
I guess what you wanted is:
Architecture: !s390x
Reg
Source: csound
Version: 1:6.18.1+dfsg-4
Tags: patch
Hi Maintainer
debian/tests/control contains the following:
Architecture: [!s390x]
The invalid syntax causes the marked tests to be skipped on all
architectures, so appears to work as intended.
I guess what you wanted is:
Architecture: !s390x
Source: autopkgtest
Version: 5.50
Architecture: [!armhf]
seen in boost1.83 and boost1.88
Architecture: [!s390x]
seen in csound and pd-midifile
The invalid syntax causes the marked tests to be skipped on all
architectures, so appears to work as intended.
Control: severity -1 important
Hi
I'm lowering the severity of this bug because I managed to work around
it by disabling mold for now. However, it would be nice to use mold,
as it speeds up the build by a factor of around three on amd64 [1],
ppc64el [2] and s390x [3].
Regards
Graham
[1] https
Hi Jeremy, Simon
Would it be possible to upload rhythmbox and skipping the failing tests please?
The FTBFS on s390x is blocking the libxml2 transition.
Regards
Graham
Source: django-auditlog
Version: 3.2.1-1
Hi Maintainer
In version 3.2.1-1, django-auditlog gained a build-dependency and an
autopkgtest dependency on python3-pytzdata. Are these necessary?
I've checked that django-auditlog still builds and autopkgtest pass
without them, but I could have missed s
Source: libxml2.9
Version: 2.12.7+dfsg+really2.9.14-2.2
Severity: serious
This bug should cause libxml2.9 to be auto-removed from testing once
"key" packages stop depending on it.
Package: release.debian.org
Severity: normal
Control: affects -1 + src:trilinos
User: release.debian@packages.debian.org
Usertags: transition
Dear Release Team
I'd like to request a transition slot for trilinos 16.1.0.
trilinos/16.1.0-1~exp2 has cleared NEW, and the auto-trilinos tracker
[1]
Source: mat2
Version: 0.13.5-1.2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-08-23, mat2'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.n
Source: python-django
Version: 3:4.2.23-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-08-23, python-django's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] h
Source: python-markdown
Version: 3.7-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime around 2025-08-22, python-markdown's autopkgtest regressed in
testing [1]. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
[1] ht
Source: guestfs-tools
Version: 1.52.3-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: debian-ri...@lists.debian.org
Hi Maintainer
Since the recent binNMU for libxml2, guestfs-tools FTBFS on riscv64
[1], where it built previously.
I think this is the only test failure:
FAIL test-virt-alignment-sca
Hi
On Tue, 26 Aug 2025 at 00:41, M. Zhou wrote:
> Anything works with me. I agree that the Julia Team no longer makes sense
> and it should fade out. The utf8proc is the only Julia dependency that is
> widely used by other packages so I stayed in the uploaders. I think we
> have already removed o
Source: fsspec
Version: 2025.3.2-1
Tags: patch
Hi Maintainer
As was done during the package build, please also ignore
test_github.py during the autopkgtest.
Regards
Graham
--- a/debian/tests/fsspec-tests
+++ b/debian/tests/fsspec-tests
@@ -15,5 +15,5 @@
for py in $pys; do
echo "=== $py =
On Mon, 25 Aug 2025 at 17:18, Matthias Geiger wrote:
> I see. Can you file a formal bug to orphan it then, so I can take over?
Of course, I can do that, but let's give Mo Zhou some time to respond.
Hi werdahias
On Mon, 25 Aug 2025 at 10:19, Matthias Geiger wrote:
> I see. I'd rather not adopt yet another package (especially if it's not
> formally orphaned), though I wouldn't mind being added as uploader. I
> would:
> - Move the repo under the debian/ namespace, adjust VCS-Urls
> - Keep Juli
Hi werdahias
You might want to consider adopting this package. The Debian Julia
Team is not really active since we no longer package Julia for Debian.
Regards
Graham
Just an update: libxml2-16, libxslt and libxmlsec1-1 have all
migrated. There are a couple of binNMUs still building, but now it's
just a matter of fixing or removing the remaining packages.
For the record, I ended up working from Matthias' .ben file (including
the .build-depends regex) as it app
Control: reopen -1
I think this bug was closed in error. Autopkgtest are now failing [1]
in testing.
[1] https://ci.debian.net/packages/r/r-cran-xml2/testing/amd64/
Hi Rene
Thanks for the update.
On Sat, 16 Aug 2025 at 09:08, Rene Engelhard wrote:
> Filed #265 for libapache2-mod-auth-mellon though since it does check for
> xmlsec1-openssl itself. Interestingly without
> causing a dependency on it.. sogo doesn't mention xmlsec or xmlsec1 at all so
> I
Hi Rene
On Tue, 8 Jul 2025 at 04:19, Rene Engelhard wrote:
> Ben file:
>
> is_affected = .build-depends ~ /\b(libmdds-dev|libixion-dev|liborcus-dev)\b/
> | .depends ~ /\b(libixion\-0\.20\-0|libixion\-0\.18\-0)\b/ | .depends ~
> /\b(liborcus\-0\.20\-0|liborcus\-0\.18\-0)\b/;
> is_good = .depends
Control: tags -1 moreinfo
Hi taffit
On Thu, 6 Mar 2025 at 11:30, David Prévot wrote:
> I know it’s late in the release process, but there are only about 30
> blockers left according to the experimental pseudo-excuse page. The
> release team help shouldn’t be needed anyway to handle this transiti
Control: tags -1 confirmed
Hi Aurélien
This is already underway. The auto-libquotient looks fine, and I
don't see any collisions with other transitions.
On Fri, 11 Apr 2025 at 06:33, Aurélien COUDERC wrote:
> I’ve uploaded it to experimental and it only has 2 rdeps:
> - neochat, rebuilds fine
Source: openscap
Version: 1.4.2+dfsg-1
Tags: ftbfs patch
User: debian-xml-sgml-p...@lists.alioth.debian.org
Usertags: libxml2.14
Hi Maintainer
openscap FTBFS when built with libxml2 2.14 and xmlsec1 1.3.7 from
experimental. I've copied what I hope is the relevant part of the log
below. A full b
Control: tags -1 confirmed
It looks like only openscad and lasso are affected by libxml2 / xmlsec1.
Let's go ahead and get this big one out of the way.
Hi
On Sat, 31 May 2025 at 09:51, Matthias Klose wrote:
> The auto tracker should be updated, or a new tracker be created:
>
> title = "libxml2";
> is_affected = .build-depends ~ /libxml2-dev/ | .depends ~ /(^|
> )(libxml2-16|libxml2)([ ,]|$)/;
> is_good = .depends ~ /\b(libxml2-16)\b/;
> is_bad =
Control: tags -1 + patch
Replacing -std=c++11 with -std=c++14 in the existing
debian/patches/config-linux.patch seems to be enough.
I've attached a new version of this patch, instead of a diff of a diff.
Index: pythran/pythran/pythran-linux.cfg
Control: retitle -1 unblock: python-eventlet/0.40.1-1
The autopkgtest regressions also occur in glance/2:30.0.0-3 and
mistral/20.0.0-2.
Control: retitle -1 python-eventlet/0.40.1-1
There are autopkgtest regressions in glance/2:30.0.0-1 and
mistral/20.0.0-1, but both of these packages have new versions which
have just migrated.
On Thu, 10 Jul 2025 at 16:09, Drew Parsons wrote:
> Santiago clarified that skipping tests on 1 or 2 cpu won't actually
> help. Tests still randomly timeout on more than 2 cpu.
>
> mdanalysis/2.9.0-12 deactivates all tests altogether, both build-time
> and run-time. Can this one be unblocked? d
I've opened a merge request in salsa [1], annotating the qemu-system
build-dependency .
[1] https://salsa.debian.org/grub-team/grub/-/merge_requests/82
Source: grub2
Version: 2.12-9
Severity: wishlist
Hi Maintainer
Please consider annotating build-dependencies only needed for tests
and only needed for documentation .
This reduces the size of the "key" package set, and facilitates
cross-building and bootstrapping.
This does not need to be done
Control: tag -1 + moreinfo
Hi Drew
On Wed, 9 Jul 2025 at 11:17, Drew Parsons wrote:
> This update does not fix the random timeouts, but rather marks them as
> flaky in debci to keep them from blocking the package.
Marking them 'flaky' is really bad for the infrastructure, as when the
tests fail
As promised, the debdiff is attached.
m-bb-p-i-1108996.debdiff
Description: Binary data
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mobile-broadband-provider-i...@packages.debian.org
Control: affects -1 + src:mobile-broadband-provider-info
Please unblock package mobile-broadband-provider-info
[ Reason ]
Th
Control: affects -1 - src:ocrmypdf
Control: retitle -1 unblock: python3.13/3.13.5-2 python3-defaults/3.13.5-1
For the record, ocrmypdf is not a "key" package and has passing
autokpgtests, so I gave it some aging days to allow it to migrate now.
ded
Author: Graham Inggs
Last-Update: 2025-07-02
--- a/tests/mobileproviderstest.cpp
+++ b/tests/mobileproviderstest.cpp
@@ -48,7 +48,7 @@
QTest::addColumn("providerNames");
QTest::newRow("Aldi 1") << "26277" << QStringList{"AldiTalk/MedionMo
Possibly related, the autopkgtest fails on June 30 [1].
I've copied what I hope is the relevant output below.
[1] https://ci.debian.net/packages/p/parsedatetime/testing/amd64/
27s === FAILURES
===
27s __ test.t
Source: plasma-nm
Version: 4:6.3.4-1
Severity: important
Forwarded: https://bugs.kde.org/show_bug.cgi?id=506217
Hi Maintainer
plasma-nm FTBFS with a test failure when built with
mobile-broadband-provider-info 20250613-1, currently in experimental.
I've copied what I hope is the relevant part of t
Source: rdflib
Version: 7.1.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
rdflib's autopkgtest is currently regressed in testing on all
architectures [1]. I've copied what I hope is the relevant part of
the log below.
Regards
Graham
[1] https://ci.d
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
1 - 100 of 1750 matches
Mail list logo
