x27; so we can re-use it for the next
transition.
Regards
Graham
tc.
Please let me know what you think.
Regards
Graham
[1] https://release.debian.org/transitions/html/gnat-14-v2.html
[2] https://release.debian.org/transitions/html/gnat-14-v3.html
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
On 23 Apr 2025, at 12:08, Graham Leggett wrote:
>> Test 7 (licenserecon): Information only
>>
>> philwyett@ks-tarkin:~/Development/builder/debian/redwax-tool-0.9.9$ lrc
>> en: Versions: licenserecon '4.2' licensecheck '3.3.9-1'
>>
&
ception
> m4/libtool.m4
> Apache-2.0 | FSFULLR m4/lt~obsolete.m4
> Apache-2.0 | FSFULLR m4/ltoptions.m4
> Apache-2.0 | FSFULLR m4/ltsugar.m4
> Apache-2.0 | FSFULLR m4/ltversion.m4
Is this ok as it is or is there something I need to fix?
All the autoconf generated stuff can be tricky to work with, has confused me a
little.
> Summary
> ===
>
> Looking promising. Above are a number of things you may wish to look at.
Thanks for this, it is much appreciated.
Regards,
Graham
--
On 26 Mar 2025, at 11:08, Graham Leggett wrote:
>> checking for libunbound >= 1.16... no
>> configure: error: Package requirements (libunbound >= 1.16) were not met:
>>
>> Package 'libevent', required by 'libunbound', not found
>>
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
ahead and upload gprbuild build directly to unstable.
I'll follow up with the binNMUs.
Regards
Graham
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 di
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
what I hope is the relevant part of the log below.
Regards
Graham
[1] https://buildd.debian.org/status/logs.php?pkg=patchelf&arch=mips64el
writing ./many-syms-main
# Run the patched tool and libraries
./many-syms-main: symbol lookup error: ./many-syms-main: undefined
symbol: f225_speci
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
/esys/
Regards
Graham
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-particl
-rcppparallel.
Regards
Graham
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
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
erity change in
> #1100373 (gprbuild) did confuse the tracker?
I don't think the tracker knows about bug severities.
Regards
Graham
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
On 25 Mar 2025, at 12:21, Graham Leggett wrote:
> checking for libunbound >= 1.16... no
> configure: error: Package requirements (libunbound >= 1.16) were not met:
>
> Package 'libevent', required by 'libunbound', not found
>
> This looks like a bu
On 25 Mar 2025, at 13:01, Graham Leggett wrote:
> This causes packages that depend on libunbound to fail as follows:
>
> checking pkg-config is at least version 0.9.0... yes
> checking for openssl >= 1.0.2... yes
> checking for openssl/pem.h... yes
> checking for nss >
On 17 Feb 2025, at 11:13, Graham Leggett wrote:
> When linking to the unbound library in code that depends on unbound, three
> packages are reported missing.
>
> checking for libunbound >= 1.16... no
> configure: error: Package requirements (libunbound >= 1.16) were
On 25 Mar 2025, at 12:03, Phil Wyett wrote:
>> E: failed to find /var/cache/pbuilder/base.tgz, have you done > create>
>> to create your base tarball yet?
>>
>> I'm assuming there are some setup steps that I am missing.
>>
>> Regards,
>>
On 25 Mar 2025, at 11:20, Graham Leggett wrote:
>> For information about the tests run, see:
>>
>> https://wiki.debian.org/PhilWyett/DebianMentoring
>
> Thanks for looking at this - I've just followed the above instructions, and
> need to confirm a step.
&
On 25 Mar 2025, at 11:29, Graham Leggett wrote:
> Looks like the key bit is "No such file or directory: 'schroot'", is there a
> prepare step before the above I need to do?
Also after the dget step, I get the following for pbuilder:
minfrin@debian12:~/test$
e --pristine-tar
g...@salsa.debian.org:/.git" to a dsc file. Keen to do the exact
steps you did.
Regards,
Graham
--
log below.
Regards
Graham
[1] https://ci.debian.net/packages/c/cctbx/testing/amd64/
266s autopkgtest [06:45:11]: test dxtbx: [---
267s Testing dxtbx with python3.13:
271s Fatal Python error: Segmentation fault
271s
271s Current thread 0x7fc2049cf100 (most recent call first):
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.
point.
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=alire
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
s on dh-elpa, britney cannot seem handle this entangled migration.
> Can dh-elpa/2.1.7 be hinted to migrate? Or the testing versions of
> el-mock-el, helpful-el, and yasnippet need to be removed for
> dh-elpa/2.1.7 to migrate?
I've added a hint for dh-elpa/2.1.7.
Regards
Graham
I believe that this was fixed in scrypt 1.3.3, which has already been
packaged and is currently in Debian testing and unstable.
al release:
redwax-tool (0.9.9-1) UNRELEASED; urgency=low
.
* Initial release. Closes: #1055168
Regards,
--
Graham Leggett
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
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
the information (license, description,
etc.) per the 'Request For Package' (RFP) [1] example?
Regards
Graham
[1] https://www.debian.org/devel/wnpp/#howto-rfp
Package: libunbound-dev
Version: 1.17.1-2+deb12u2
Severity: important
File: libunbound
X-Debbugs-Cc: minf...@sharp.fm
Dear Maintainer,
When linking to the unbound library in code that depends on unbound, three
packages are reported missing.
checking for libunbound >= 1.16... no
configure: error
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.
these architectures.
Regards
Graham
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
to the one below.
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=scalapack
--- a/debian/rules
+++ b/debian/rules
@@ -50,6 +50,7 @@
dh $@ --buildsystem=cmake
export PRTE_MCA_plm_ssh_agent=/bin/false#workaround
to start MPI-applications in chro
dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
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.
dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2
dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2
a
missing dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy
e tarsnap_*.debian.tar.gz
would not overwrite anything in the .orig source tarball.
Cheers,
- Graham
or SuSE)
[*] https://www.tarsnap.com/download.html
Cheers,
- Graham Percival, Tarsnap employee
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
in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2] https
call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2]
https
dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2
bug, there was a Lintian tag [2] for this issue,
but I do not see now where
this is reported.
Regards
Graham
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094826
[2] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
dh_numpy3 call in debian/rules.
There was a Lintain tag [1] for this issue, but I do not see now where
this is reported. You can also find further information in the
documentation [2] of the numpy package.
Regards
Graham
[1] https://lintian.debian.org/tags/missing-dependency-on-numpy-abi.html
[2
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.debia
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]
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.debia
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.debia
s can be solved for future transitions if opm-simulators
had an explicit Build-Depends on libopm-common-dev, so Ben would place
opm-simulators in a higher dependency level than opm-common, ensuring
that opm-common is rebuilt before opm-simulators.
Regards
Graham
[1] https://release.debian.org/t
I think this is due to the openturns FTBFS (see #1091444).
this dependency and closing this bug.
The latest test still fails, while it can be seen in the log below
that fpc 3.2.2+dfsg-35 was used.
Regards
Graham
135s Free Pascal Compiler version 3.2.2+dfsg-35 [2025/01/05] for x86_64
135s Copyright (c) 1993-2021 by Florian Klaempfl and others
135s Target
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
log below.
Regards
Graham
[1] https://ci.debian.net/packages/c/castle-game-engine/testing/amd64/
112s Free Pascal Compiler version 3.2.2+dfsg-34 [2024/07/13] for x86_64
112s Copyright (c) 1993-2021 by Florian Klaempfl and others
112s Target OS: Linux for x86-64
112s Compiling castle_tester_stan
virtual package provided by
imagemagick-7-common,
Regards
Graham
[1] https://tests.reproducible-builds.org/debian/rb-pkg/digikam.html
.
Regards
Graham
[1] https://buildd.debian.org/status/logs.php?pkg=mfem&arch=arm64
[2] https://tests.reproducible-builds.org/debian/history/arm64/mfem.html
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
ribe' in a
recent commit [2].
Regards
Graham
[1] https://autopkgtest.ubuntu.com/packages/esys-particle/plucky/amd64
[2]
https://salsa.debian.org/science-team/esys-particle/-/commit/532ba2a390ba2050ebf06dac7249528d2ae89974
1482s There are not enough slots available in the system to satisfy th
pe is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/r/r-cran-seurat/testing/riscv64/
[2] https://ci.debian.net/packages/r/r-cran-seurat/testing/s390x/
185s ══ Failed tests
185s ── Fa
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
owed blasr/5.3.5+dfsg-7 to migrate to testing.
Regards
Graham
[1] https://ci.debian.net/packages/p/pbsuite/testing/amd64/
74s 2024-12-26 05:20:04,185 [INFO] Running /usr/bin/Honey spots
--reference lambda_modified.fasta mappingFinal.bam
74s Traceback (most recent call last):
74s File "
aidan ready yet.
I've added a removal hint for kaidan/0.9.1-4. I will wait until it
has succeeded before closing this bug.
Regards
Graham
s done automatically.
Regards
Graham
override_dh_auto_test:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
echo "Running MPI smoketest, don't report failure here to
gtg-trace, but to the mpi implementation"
mpicc debian/test-mpi.c $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o
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.
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
transition.
Regards
Graham
[1] https://buildd.debian.org/status/logs.php?pkg=elkcode&arch=arm64
[2] https://tests.reproducible-builds.org/debian/history/arm64/elkcode.html
(I'm the author of that test.)
Interesting! Now that I think about it, that test makes the assumption
that the CPU availability will be roughly equal. Namely, it:
1) creates a file which should take 10 seconds to decrypt
2) attempt to decrypt that file in only 1 second.
If the system was very
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
?
I suspect your previous build happened during the openmpi transition.
Regards
Graham
should be
able to confirm whether this patch is sufficient in experimental
before doing a team upload to unstable.
Regards
Graham
[1] https://ci.debian.net/packages/p/python-questplus/
Description: Allow more rounding errors in the tests with scipy 1.14
Bug-Debian: https://bugs.debian.org/1079788
nd_i386-2024-12-17T09:04:47Z.build
>
> Can you please double-check once again?
Indeed, on reproducible builds it seems valgrind now builds
successfully in unstable, but still fails in trixie.
I'm guessing something fixed between mpich 4.2.0-14 in trixie and
4.2.1-4 in unstable.
Regards
Graham
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
below.
This regression current prevents python-voip-utils 0.2.1-1 from
migrating to testing.
Regards
Graham
[1] https://ci.debian.net/packages/p/python-voip-utils/testing/s390x/
24s === FAILURES
==
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
1 - 100 of 1973 matches
Mail list logo
