bug#56353: sbcl-2.2.6 build fail

[bokr@bokr.com]

Hi,

On +2022-07-02 20:26:40 +0100, Christopher Baines wrote:
> 
> Guillaume Le Vaillant <glv@posteo.net> writes:
> 
> > [[PGP Signed Part:Undecided]]
> > Christopher Baines <mail@cbaines.net> skribis:
> >
> >> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
> >>
> >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
> >>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
> >>>
> >>>
> >>> This log file is always a good idea to include.
> >>
> >> I think this is the equivalent non-grafted derivation:
> >>
> >>   https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
> >>
> >> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> >> get it to build successfully once though on my laptop.
> >>
> >> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> >> successfully, or if there's particular conditions for it to build?
> >>
> >> Thanks,
> >>
> >> Chris
> >
> > According to the logs, the 'build-doc' phase fails to compile the
> > documentation for SIMD related functions. There's a patch disabling this
> > part of the doc unless we compile on x86_64, but maybe not all x86_64
> > CPUs have the required instructions...
> >
> > Would it be possible to get the result of "lscpu" on some machines where
> > it fails?
> 
> Sure, here is the lscpu output from the bayfront and harbourfront
> machines.
> 
[...]

I wonder what running this at the time builds failed would have shown:

--8<---------------cut here---------------start------------->8---
#/usr/bin/bash
# ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
top -n 1 | \
sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
    -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
    -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
--8<---------------cut here---------------end--------------->8---
(no guarantees on my hack to get rid of the highlighting escapes
and utf8->ascii quote subst :)
(top seems to assume even -n 1 output is always going to interactive dest)

Anyway, wondering: Could memory and CPU loading at the time
have triggered the build failure?
--
Regards,
Bengt Richter