Dear maintainer(s),

With a recent upload of sbcl the autopkgtest of buildapp fails in
testing when that autopkgtest is run with the binary packages of sbcl
from unstable. It passes when run with only packages from testing. In
tabular form:

                        pass            fail
sbcl                   from testing    2:2.5.8-1
buildapp               from testing    1.5.6-3
all others             from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of sbcl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/riscv64/b/buildapp/64938630/log.gz

233s Missing required foreign symbol 'fun_end_breakpoint_trap'
233s Missing required foreign symbol 'fun_end_breakpoint_end'
233s Missing required foreign symbol 'fun_end_breakpoint_guts'
235s ;; loading system "alexandria"
253s Missing required foreign symbol 'fun_end_breakpoint_trap'
253s Missing required foreign symbol 'fun_end_breakpoint_end'
253s Missing required foreign symbol 'fun_end_breakpoint_guts'
254s autopkgtest [13:02:35]: test load-system

Hello,

Riscv porters, would you be able to look at this problem with SBCL,
please?  #1117549.  Thanks.

Re: Paul Gevers

This is triggering an autorm warning for pgloader.

Rather than this being RC for all architectures, I would say the
proper "fix" would be to remove sbcl on riscv64 since that
architecture is new.

(Of course a proper fix would be preferable.)

Christoph

Hi,


sbcl is a key package, with my current understanding this shouldn't happen.


Or maybe we should try to figure out why the autoremoval tools threaten
to remove pgloader because of this. Adding Graham to CC as he is
investigating other autoremoval artifacts.

Paul

Re: Paul Gevers

The actual chain is pgloader -> buildapp -> sbcl. The AUTORM is from
buildapp.

My argument is that the actual problem is that sbcl is now available
on riscv64. If that architecture had not appeared, buildapp and
pgloader (and sbcl) would not be buggy.

Christoph

Hi riscv64 porters,

ping.


I don't like these arguments, although I understand them very much. I
was hoping that you'd see the commitment of being a porter to at least
have a look and report back, even if you can't fix it. sbcl is a
compiler, so at the root of a chain of things. In my humble opinion,
compilers that are part of testing on riscv64 should be higher up on
your list of packages to take care of.

Paul

Hi,

I do not know why I did not notice this and put this on my todo list,
Thanks for the reminder this again, I or we(riscv ports) will have a
look at this.

BR,
Bo

Re: Paul Gevers

I am not a riscv porter. I care about pgloader :)

Christoph

Hi Christoph,
I suspected as much, hence my previous message was TO: riscv64 porters
with you on CC.

Paul

control: forwarded -1 https://bugs.launchpad.net/sbcl/+bug/2130944
thanks,

Hi,

Ccing Sean explicitly to help confirm this.
[...]

It seems the issue was raised since sbcl 2.5.3? It was not fully
broken on riscv64 just annoying information verbosed.

```

rv@unmatched:~/build/buildapp/buildapp-1.5.6$ HOME=${AUTOPKGTEST_TMP}
buildapp --load-system alexandria --eval '(defun main (argv) (princ
(alexandria:factorial (parse-intege
r (second argv)))) (terpri))' --entry main --output factorial
Missing required foreign symbol 'fun_end_breakpoint_trap'
Missing required foreign symbol 'fun_end_breakpoint_end'
Missing required foreign symbol 'fun_end_breakpoint_guts'
Missing required foreign symbol 'fun_end_breakpoint_trap'
Missing required foreign symbol 'fun_end_breakpoint_end'
Missing required foreign symbol 'fun_end_breakpoint_guts'
;; loading system "alexandria"

./factorial 5
Missing required foreign symbol 'fun_end_breakpoint_trap'
Missing required foreign symbol 'fun_end_breakpoint_end'
Missing required foreign symbol 'fun_end_breakpoint_guts'
120
rv@unmatched:~/build/buildapp/buildapp-1.5.6$ sbcl --version
SBCL 2.5.8.debian

```
^ https://salsa.debian.org/common-lisp-team/buildapp/-/blob/master/debian/tests/load-system?ref_type=heads

I opened one issue for upstream and hope to get some help on how to
deal with this.
https://bugs.launchpad.net/sbcl/+bug/2130944

BR,
Bo

Hello,

Yes, the issue is only very recent.

Thanks for investigating what functionality is actually broken.
Given your results I would suggest we just disable the autopkgtest for
buildapp on riscv64, if a solution from upstream is not forthcoming.

Re: Sean Whitton

I just uploaded this workaround given the autoremoval was imminent.

Now I'm wondering what the correct severity of this bug should be,
serious and reassign to sbcl? Important?

Christoph

Hello,

Maybe important and assigned to both packages, given we don't know which
is really at fault.

Re: Sean Whitton

(It wasn't imminent, I was mixing this up with another package, but
whatever, the fix is ok.)

Makes sense.

Christoph

Hello,

Thanks for the upload :)

Would adding the following to debian/tests/control have been enough?

Restrictions:  allow-stderr

Re: Graham Inggs

Looks like, will fix. Thanks for spotting that!

Christoph

Re: To Graham Inggs

To my defense, I had done a test build of pgloader on riscv64, and
that failed with some "ERROR: please implement". That led me to
thinking that buildapp was also failing.

The test binary built by the autopkgtest works, but prints the same
warnings as the build:

 ./factorial 6
Missing required foreign symbol 'fun_end_breakpoint_trap'
Missing required foreign symbol 'fun_end_breakpoint_end'
Missing required foreign symbol 'fun_end_breakpoint_guts'
720

A new package with just "allow-stderr" and without the skip logic is
on the way.

Christoph