Bug#1086128: src:sbcl: fails to migrate to testing for too long

[Paul Gevers]

Source: sbcl
Version: 2:2.4.7-2
Severity: serious
Control: close -1 2:2.4.9+git20241010.1.465757f12-1
Tags: sid trixie
User: ***@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 30 days as having a Release Critical bug in
testing [1]. Your package src:sbcl has been trying to migrate for 31
days [2], hence this bug report. The current output of the migration
software for this package is copied to the bottom of this report and
should list the reason why the package is blocked.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or its
(reverse-)dependencies. We expect maintainers to fix issues that hamper
the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

This bug submission immediately closes the bug with the version in
unstable, so if that version or a later version migrates, this bug will
no longer affect testing. This bug is also tagged to only affect sid and
trixie, so it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

This bug report has been automatically generated and has only been sent
manually. If you have any comments with regards to the content or the
process, please reach out to me.

Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html
[2] https://qa.debian.org/excuses.php?package=sbcl

Current text from [2]:
Migration status for sbcl (2:2.4.7-2 to
2:2.4.9+git20241010.1.465757f12-1): BLOCKED: Rejected/violates migration
policy/introduces a regression
Issues preventing migration:
∙ ∙ autopkgtest for cl-ironclad/0.61-4: amd64: Pass, arm64: Pass, i386:
Pass, ppc64el: Regression or new test ♻ (reference ♻)
∙ ∙ autopkgtest for cl-postmodern/20211113.git9d4332f-5: amd64: No
tests, superficial or marked flaky ♻ (reference ♻), arm64: No tests,
superficial or marked flaky ♻ (reference ♻), i386: No tests, superficial
or marked flaky ♻ (reference ♻), ppc64el: Regression or new test ♻
(reference ♻)
∙ ∙ autopkgtest for sbcl/2:2.4.9+git20241010.1.465757f12-1: amd64: Pass,
arm64: Pass, i386: Pass, ppc64el: Failed (not a regression)
Additional info:
∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/s/sbcl.html
∙ ∙ Ignoring non-reproducibility on amd64 (not a regression) - info ♻ ∙
∙ Ignoring non-reproducibility on arm64 (not a regression) - info ♻ ∙ ∙
Ignoring non-reproducibility on i386 (not a regression) - info ♻ ∙ ∙ 17
days old (needed 5 days)

[Sean Whitton]

Hello Doug,

I've been able to follow up on this now and gather a little more
information. Given that it's been a month, let me recap the problem
case:

- ppc64el KVM virtual machine on ppc64el hardware (now confirmed)
- cl-ironclad 0.61
- all other package versions are from Debian "trixie", our pre-release
- cl-ironclad test wrapper script has
#+sbcl
(setf (extern-alien "pre_verify_gen_0" int) 1
(extern-alien "verify_gens" char) 0
(extern-alien "gencgc_verbose" int) 1)
#+sbcl (gc)
- sbcl 2.4.7 -- ironclad test suite passes, piles of extra GC output
- sbcl 2.4.10 -- test suite exits with only output:

fatal error encountered in SBCL pid 815 tid 815:
no size function for object at 0x100009bf80 (widetag 0x33)

(in particular, no GC debugging output)

Can you confirm that gencgc_verbose does anything at all, irrespective
of ironclad being tested or not?

I've now tested this by building sbcl 2.4.10 on ppc64el hardware, with

diff --git a/tests/run-tests.sh b/tests/run-tests.sh
index d28c143f6..edef82eb1 100755
--- a/tests/run-tests.sh
+++ b/tests/run-tests.sh
@@ -51,7 +51,8 @@ tenfour () {
set +u
run_sbcl \
--eval '(with-compilation-unit () (load "run-tests.lisp"))' \
- --eval '(run-tests::run-all)' $*
+ --eval '(setf (extern-alien "pre_verify_gen_0" int) 1 (extern-alien "verify_gens" char) 0 (extern-alien "gencgc_verbose" int) 1)' --eval '(gc)' \
+ $*
tenfour $?

It gives this output:

Verify before GC [threads] [RO] [static] [permgen] [dynamic] passed
Verify after GC(0,1) [threads] [RO] [static] [permgen] [dynamic] passed
Next gc when 84718115 bytes have been consed

So I believe that gencgc_verbose does indeed do something.

Thank you.

[Paul Gevers]

Hi ppc64el porters, Sean,

@porters, can you please have a look at the ppc64el autopkgtest
regressions caused by sbcl [1]?

I don't think I can do anything about this bug. Upstream aren't able to
reproduce it. I don't think it makes sense to block sbcl's migration on
this. I think that either we should ignore the cl-ironclad test failure
on ppc64el or remove sbcl on that architecture, if you think that would
be warranted.

cl-ironclad *and* cl-postmodern. And the error is identical:
no size function for object at 0x100009bf80 (widetag 0x33)

Please let me know if you would be okay with overriding the test
failure.

I assuming you didn't contact the ppc64el porters yet (apologies if you
did). Shall we give them a chance to investigate?

Paul

[1] https://qa.debian.org/excuses.php?package=sbcl

[Paul Gevers]

Dear ppc64el porters: ping.

Dear Sean,

Post by Sean Whitton

I don't think I can do anything about this bug.  Upstream aren't able to
reproduce it.  I don't think it makes sense to block sbcl's migration on
this.  I think that either we should ignore the cl-ironclad test failure
on ppc64el or remove sbcl on that architecture, if you think that would
be warranted.

no size function for object at 0x100009bf80 (widetag 0x33)

How severe do you think this error is? Does it indicate that sbcl is
useless on ppc64el or is this a niche use case?

Removal of sbcl on ppc64el seems to be going to be non-trivial as it's a
key package via cl-cffi which is needed for brltty which is very
important for our accessibility support (pulled in via d-i if I'm not
mistaken).

Paul

[Sean Whitton]

Hello,

Post by Paul Gevers
How severe do you think this error is? Does it indicate that sbcl is
useless on ppc64el or is this a niche use case?

I would doubt that it means that sbcl is useless on ppc64el because of
how upstream can't reproduce the problem.

Post by Paul Gevers
Removal of sbcl on ppc64el seems to be going to be non-trivial as it's a key
package via cl-cffi which is needed for brltty which is very important for our
accessibility support (pulled in via d-i if I'm not mistaken).

An alternative would just be to downgrade sbcl with a +really version.