"build-system compiler failures are not cached as expected by Cuirass"

  • Open
  • quality assurance status badge
Details
6 participants
  • Efraim Flashner
  • Guillaume Le Vaillant
  • Leo Famulari
  • Ludovic Courtès
  • Christopher Baines
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 12 Jan 2021 22:04
SBCL / Common Lisp packages fail to build on aarch64
(address . bug-guix@gnu.org)
X/4OzGVFmWjm37kM@jasmine.lan
I noticed that many Common Lisp or SBCL-related packages are failing to
build on the aarc64 platform on our build farm, due the failure to build
SBCL:


------
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 2.1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
Initial page table:
Gen Boxed Code Raw LgBox LgCode LgRaw Pin Alloc Waste Trig WP GCs Mem-age
6 397 250 0 0 0 0 0 42335440 66352 2000000 647 0 0.0000
Total bytes allocated = 42335440
Dynamic-space-size bytes = 3221225472
COLD-INIT... (Length(TLFs)= 9736)
Disassembler: 72 printers, 0 prefilters, 4 labelers
CORRUPTION WARNING in SBCL pid 1774 tid 1774:
Memory fault at 0xfffffffffffffffa (pc=0x1002199f70)
The integrity of this image is possibly compromised.
Exiting.
Error opening /dev/tty: No such device or address
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
real 0m6.120s
user 0m5.958s
sys 0m0.137s
command "sh" "make.sh" "clisp" "--prefix=/gnu/store/j1ciw4dc8iskd5fdcw0s1ba08kkg7vx6-sbcl-2.1.0" "--dynamic-space-size=3072" "--with-sb-core-compression" "--with-sb-xref-for-internals" failed with status 1
------

It appears that SBCL can support this platform. However, until we make
it work, I plan to remove aarch64 from the "supported-systems" of sbcl,
to avoid attempting these builds.
G
G
Guillaume Le Vaillant wrote on 13 Jan 2021 22:03
(name . Leo Famulari)(address . leo@famulari.name)(address . 45826@debbugs.gnu.org)
87eeioczws.fsf@yamatai
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (40 lines)
> I noticed that many Common Lisp or SBCL-related packages are failing to
> build on the aarc64 platform on our build farm, due the failure to build
> SBCL:
>
> From the log of <https://ci.guix.gnu.org/build/180326/details>:
>
> ------
> //entering make-target-2.sh
> //doing warm init - compilation phase
> This is SBCL 2.1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> Initial page table:
> Gen Boxed Code Raw LgBox LgCode LgRaw Pin Alloc Waste Trig WP GCs Mem-age
> 6 397 250 0 0 0 0 0 42335440 66352 2000000 647 0 0.0000
> Total bytes allocated = 42335440
> Dynamic-space-size bytes = 3221225472
> COLD-INIT... (Length(TLFs)= 9736)
> Disassembler: 72 printers, 0 prefilters, 4 labelers
> CORRUPTION WARNING in SBCL pid 1774 tid 1774:
> Memory fault at 0xfffffffffffffffa (pc=0x1002199f70)
> The integrity of this image is possibly compromised.
> Exiting.
> Error opening /dev/tty: No such device or address
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb>
> real 0m6.120s
> user 0m5.958s
> sys 0m0.137s
> command "sh" "make.sh" "clisp" "--prefix=/gnu/store/j1ciw4dc8iskd5fdcw0s1ba08kkg7vx6-sbcl-2.1.0" "--dynamic-space-size=3072" "--with-sb-core-compression" "--with-sb-xref-for-internals" failed with status 1
> ------
>
> It appears that SBCL can support this platform. However, until we make
> it work, I plan to remove aarch64 from the "supported-systems" of sbcl,
> to avoid attempting these builds.

I tried to bootstrap sbcl using ecl instead of clisp, using
"guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't
have any arm64 hardware, but it failed with the same memory fault.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCX/9gNA8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j92kwEAnEnm+2JgYtk3E4vAtgbxUH/LiK37rjPaCmDf
fAs4lEgA+gKSYpQahe2Ih/t2mVKH3UX1TasYXhmdhl4aBbNSqIuH
=JK4S
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 14 Jan 2021 00:25
(name . Guillaume Le Vaillant)(address . glv@posteo.net)(address . 45826@debbugs.gnu.org)
X/+BVdUmj97xsEW4@jasmine.lan
On Wed, Jan 13, 2021 at 10:03:47PM +0100, Guillaume Le Vaillant wrote:
Toggle quote (4 lines)
> I tried to bootstrap sbcl using ecl instead of clisp, using
> "guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't
> have any arm64 hardware, but it failed with the same memory fault.

Thanks! On #guix, Efraim reported that the builds were succeeding on his
aarch64 hardware. So, I'm not sure what's going on :/
G
G
Guillaume Le Vaillant wrote on 16 Jan 2021 10:42
(name . Leo Famulari)(address . leo@famulari.name)(address . 45826@debbugs.gnu.org)
877dod1al9.fsf@yamatai
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (8 lines)
> On Wed, Jan 13, 2021 at 10:03:47PM +0100, Guillaume Le Vaillant wrote:
>> I tried to bootstrap sbcl using ecl instead of clisp, using
>> "guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't
>> have any arm64 hardware, but it failed with the same memory fault.
>
> Thanks! On #guix, Efraim reported that the builds were succeeding on his
> aarch64 hardware. So, I'm not sure what's going on :/

When taking a look at the logs of failing builds of sbcl-* packages on
aarch64-linux (for example at [1] for master or at [2] for staging),
I saw that the build jobs try to build sbcl (which is currently failing)
for every package.

I would have expected the builds for sbcl-* packages to be marked as
"failed because missing dependency" given that the main dependency of
the asdf-build-system/sbcl failed to build. Instead the build farm is
trying to rebuild sbcl over and over, which wastes quite some time and
resources.

It looks like the dependencies of the build system are not considered as
dependencies for the packages that use this build system.
Am I missing something?

-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYAK1Ig8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j9h4AD+MBEdQORhMvPrvaJZVVljTjiw19ooig9SRpJU
R71vvvYA/2fPqVnhZtiGpghQZzNCEYlON93rUj4f4rKtlexnjt+g
=9u/D
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 16 Jan 2021 19:57
(no subject)
(address . control@debbugs.gnu.org)
YAM3A2TGLFReD1Ys@jasmine.lan
retitle 45826 "build-system compiler failures are not cached as expected by Cuirass"
L
L
Leo Famulari wrote on 16 Jan 2021 19:58
Re: bug#45826: SBCL / Common Lisp packages fail to build on aarch64
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
YAM3X0TOTT3VfakZ@jasmine.lan
On Sat, Jan 16, 2021 at 10:42:58AM +0100, Guillaume Le Vaillant wrote:
Toggle quote (15 lines)
> When taking a look at the logs of failing builds of sbcl-* packages on
> aarch64-linux (for example at [1] for master or at [2] for staging),
> I saw that the build jobs try to build sbcl (which is currently failing)
> for every package.
>
> I would have expected the builds for sbcl-* packages to be marked as
> "failed because missing dependency" given that the main dependency of
> the asdf-build-system/sbcl failed to build. Instead the build farm is
> trying to rebuild sbcl over and over, which wastes quite some time and
> resources.
>
> It looks like the dependencies of the build system are not considered as
> dependencies for the packages that use this build system.
> Am I missing something?

That's a good observation. I hadn't thought of it.

I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
these builds until we can fix the bug for real. Mathieu: this might
explain why the build farm is spending all its effort on aarch64.

By the way, SBCL can be built for aarch64 according to Efraim:


So, the original point of this bug is obviated, and I'm re-titling it to
address your observation, Guillaume.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmADN1wACgkQJkb6MLrK
fwiBdhAA1HZOR3ryrc87Ahm5CIcrA+K09GZan7qAppEFCt+pKEyXpXMmpR8nblKb
W8+mpcQBh3cT6bjIYesiBxH5YSm7MPSJeKMr/i9vX738lIoBrJUl2TcaI8qLAJ0r
2sgFaSw5pNnt62AAQ1rljlBF4+ZeHyIEQaq5euwkM4x5MNEXcCT/Y2J5wyB9TL9L
jmDY1cKoHZOi4WZclUkvRzv3Pjy68/0LlEglUWr4OaYjvltzwSYRAFezevn0VqFE
ocTfuXxAmtFqpFbEdm/5HSgiTVWK1t810svY/LGXfkdc0DGX030VoUpONdIcg57S
ZE+G0CXZVnnLLZI0KbqIPXtO1lMaEVI8cNFlj6SWdwnNYm/Gk4KHTR3jFdj8GHF8
SLARCxsqQJMsjMk1+8ItfXpKjmOPVOATzkXPH9Rb459FGItOLAHoOPAfwVSdWAdk
YNgNTSZpzRFYmBij4uTjkKzKlHycy/41FK1/CRw+yAroN1LMP/Xxn3fe5FA/ji7O
ixbpwfqmTh9+NKyL8AVOtOfZxJVrQmEtJsH2kaHXX2F2dE9pE8WQG2ZDWYz9WQAt
Xh8y9ZKBpvpEUSlDSHe/YuZ896ZmGlxFbWWD7wf5ltW8hEHzkHt23INkrowZP1cJ
Xt/PEUNdcLaxggeo5WT3cVp1d2JXR2/yH2cutILkCYK4FWplYiA=
=Hgrh
-----END PGP SIGNATURE-----


M
M
Mathieu Othacehe wrote on 17 Jan 2021 10:29
(name . Leo Famulari)(address . leo@famulari.name)
87mtx7hpwy.fsf@gnu.org
Hello Leo & Guillaume,

Toggle quote (6 lines)
> That's a good observation. I hadn't thought of it.
>
> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
> these builds until we can fix the bug for real. Mathieu: this might
> explain why the build farm is spending all its effort on aarch64.

If we want to disable SBCL builds temporarily we can do something
similar to what I did to disable Rust builds on non-x86_64 architectures
here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.

Regarding the rebuilding that is a limitation of the new Cuirass remote
building mechanism I am aware of and I need to solve. As build failures
are only cached of the machine performing the build and the builds are
now distributed to all the machines across the build farm, we need to
find a way to centralize the builds failure cache.

It would also be nice to optionally publish the build failures cache so
that the user doesn't try to build a package that is known to be failing
on the build farm. Chris, have you encountered this issue with the Build
Coordinator?

Thanks,

Mathieu
C
C
Christopher Baines wrote on 17 Jan 2021 12:35
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87mtx794oa.fsf@cbaines.net
Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (23 lines)
> Hello Leo & Guillaume,
>
>> That's a good observation. I hadn't thought of it.
>>
>> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
>> these builds until we can fix the bug for real. Mathieu: this might
>> explain why the build farm is spending all its effort on aarch64.
>
> If we want to disable SBCL builds temporarily we can do something
> similar to what I did to disable Rust builds on non-x86_64 architectures
> here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.
>
> Regarding the rebuilding that is a limitation of the new Cuirass remote
> building mechanism I am aware of and I need to solve. As build failures
> are only cached of the machine performing the build and the builds are
> now distributed to all the machines across the build farm, we need to
> find a way to centralize the builds failure cache.
>
> It would also be nice to optionally publish the build failures cache so
> that the user doesn't try to build a package that is known to be failing
> on the build farm. Chris, have you encountered this issue with the Build
> Coordinator?

Not really. The first thing to note is that I'm running the Guix Build
Coordinator currently without the guix-daemon --cache-failures option,
in fact it's probably unwise to do so, as it would mean that rather than
some builds taking place, the guix-daemon could just return a cached
failure. I should probably mention this in the README.

The way this situation is dealt with in the Guix Build Coordinator is
simplified by the agents not attempting builds where the derivation
inputs aren't present. If an agent is unable to ensure all the inputs
are present, it just reports this to the coordinator.

The behaviour is configurable, but the default missing inputs hook will
submit a new build for a missing input, but only if one doesn't already
exist. Because of this, you don't get the behaviour where some missing
prerequisite that fails to built is built over and over again, every
time you try and build a derivation that uses it.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmAEIRVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfF9BAAs7g5bizndbOWK0euRKaN9i0G8Z4FMF63
uegYSNy2/opaqSmlIlH6rW/FTvWR258rjuPoVLiN+OWygkfRlJHzClVpu2mi5pHD
3wXA5AI3Dk8eMqTpgkaN7cZsqqlTooi5YP0JY/wTb9Gs86tzOYIrxikhYyqr5r+B
m2kW1uq2elXjvbAU/OC8otS4opBypz9bUgZa4R3/cgPHvC/kwQuF/e/8kutsrN3e
yaNwDvvrXBkxK/umR2RGCFGYIeCMCKigYdTE7JX6d/zdbOWQ/5AoxVCJe46djqOo
61HNNgWVw698k2bqnmpWNFVgOsamjzbpfZgPYw+MDt8EiTLbT2cRST//tFjUEvnd
Wj8/bcWD9HTFKSi//h+37R5izXClXsM0K2fLR0KW64aT5ai0LxeJlS85gs0TSaD7
rO+rBpHU2y/yBDigCObi4GjBoxSTih/BeWd5LPU6Rv5RBqcwILxyZS60EcUxknPS
Ij0zR/grLM6p+b/1M39Lvq8/+Ad87a2Rppj2K1odaqpvXzu5kv/ZWHCkKVvg3gfE
Ptfqi0aW5BBLF66RjaKjrDahGg6fFQDYGHkjqT1a18x+DSefPzhRjXTWtBywpRMQ
8ZCX4zkTTxSCHnxinUx/1Fc6Hy7EH5idwEN7e8UKbBvy7hVjHw5aZYtbmcNxZRFc
l5gZ4Cui1qo=
=ZWAI
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 17 Jan 2021 20:11
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
YASLz1/e/r74Oh7g@jasmine.lan
On Sun, Jan 17, 2021 at 10:29:49AM +0100, Mathieu Othacehe wrote:
Toggle quote (4 lines)
> If we want to disable SBCL builds temporarily we can do something
> similar to what I did to disable Rust builds on non-x86_64 architectures
> here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.

------
Toggle diff (17 lines)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 35a96b5754..91b5d6b6ec 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -452,6 +452,7 @@ test = { path = \"../libtest\" }
(variable "LIBRARY_PATH")
(files '("lib" "lib64")))))
+ (supported-systems '("x86_64-linux"))
(synopsis "Compiler for the Rust programming language")
(description "Rust is a systems programming language that provides memory
safety and thread safety guarantees.")
------

Hm, this would also prevent users from building the packages on their
own machines. We need a way to make changes like this but limit them to
the build farm.
E
E
Efraim Flashner wrote on 17 Jan 2021 20:37
(name . Leo Famulari)(address . leo@famulari.name)
YASR5ygA5i3XtfBr@3900XT
On Sun, Jan 17, 2021 at 02:11:11PM -0500, Leo Famulari wrote:
Toggle quote (24 lines)
> On Sun, Jan 17, 2021 at 10:29:49AM +0100, Mathieu Othacehe wrote:
> > If we want to disable SBCL builds temporarily we can do something
> > similar to what I did to disable Rust builds on non-x86_64 architectures
> > here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.
>
> ------
> diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
> index 35a96b5754..91b5d6b6ec 100644
> --- a/gnu/packages/rust.scm
> +++ b/gnu/packages/rust.scm
> @@ -452,6 +452,7 @@ test = { path = \"../libtest\" }
> (variable "LIBRARY_PATH")
> (files '("lib" "lib64")))))
>
> + (supported-systems '("x86_64-linux"))
> (synopsis "Compiler for the Rust programming language")
> (description "Rust is a systems programming language that provides memory
> safety and thread safety guarantees.")
> ------
>
> Hm, this would also prevent users from building the packages on their
> own machines. We need a way to make changes like this but limit them to
> the build farm.

Would marking it unsubstitutable work? Or would we need build-local

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmAEkeQACgkQQarn3Mo9
g1Hcow//RGY7aaO+NApUdnpOV9hIC14X9coSVsEz0epWGn4xr8R1kBr0RSE5/wD/
7u9sPrGH16uMGonQ+6pak3u30Wh6UjJBp+roFDASyrIX4it6TvFPNuX1FHr5yutU
CoSPY/OuuQcZtp5/WkW8MmNLVgRYy3rhs566OBBK/Y5NYOcjlIkboQH6DXDi8Cqm
chPKMGgKyYdjwJqvfkzDsc+2XkIhlBr2J/O2Pj+bjsgKKrojaHPosC7M4OdttMJi
8CtwfKRuSuoTaAarSinJUgtMxtu3zayHpdN6Fd8k/a6TQ2/BNnvM4IkJe665Ryup
qM3BMfVHqOadb0TWCfJMVmFMps3Sd6lD7PxD20Lypflq/zYJbCScKI1+Wxut4yDl
IP/zIWsL/v7oI3rPBkJ8U2/7hVCA1hlb1pHhJkOatvO4Z4PnT7IluiisjaArM13+
wlsaYE+HDvOvgXCRo0OinYY1VQxElVW7Ve8N0rHT7yHGEtaXM7FFT1pNasGTkXlU
DBM8Ty3uAvulxjzFdr+bm+zM/QkUmYjMzPo9afHziXJ3mUvyNc1mfnl4Wny4gqDz
k3FpJwOHCQW60GqX+vDrr77+PtjP43QrIrQS/A+GEuE4EaE7v2MzJNTnt0tAEqhf
mBtC5kBLIJILyxnLVeNDl8P4Ew9iERCEsMewz5o37pW9gh67NjQ=
=FHUG
-----END PGP SIGNATURE-----


M
M
Mathieu Othacehe wrote on 18 Jan 2021 14:36
(name . Christopher Baines)(address . mail@cbaines.net)
87czy2pdso.fsf@gnu.org
Hey Chris,

Toggle quote (6 lines)
> The behaviour is configurable, but the default missing inputs hook will
> submit a new build for a missing input, but only if one doesn't already
> exist. Because of this, you don't get the behaviour where some missing
> prerequisite that fails to built is built over and over again, every
> time you try and build a derivation that uses it.

Oh, makes sense, thanks for explaining. I also had a look to Hydra in
that matter. They are breaking a "Build" into "BuildSteps" corresponding
more or less to the build dependencies, or "Inputs" in the
Coordinator. This way they make sure not to submit multiple times a same
build to the workers.

It means that it is also no longer needed to cache build failures I
guess. I think it would be really nice to port this mechanism to
Cuirass.

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 19 Jan 2021 14:13
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87pn21hxwp.fsf@gnu.org
Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (27 lines)
> On Sun, Jan 17, 2021 at 02:11:11PM -0500, Leo Famulari wrote:
>> On Sun, Jan 17, 2021 at 10:29:49AM +0100, Mathieu Othacehe wrote:
>> > If we want to disable SBCL builds temporarily we can do something
>> > similar to what I did to disable Rust builds on non-x86_64 architectures
>> > here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.
>>
>> ------
>> diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
>> index 35a96b5754..91b5d6b6ec 100644
>> --- a/gnu/packages/rust.scm
>> +++ b/gnu/packages/rust.scm
>> @@ -452,6 +452,7 @@ test = { path = \"../libtest\" }
>> (variable "LIBRARY_PATH")
>> (files '("lib" "lib64")))))
>>
>> + (supported-systems '("x86_64-linux"))
>> (synopsis "Compiler for the Rust programming language")
>> (description "Rust is a systems programming language that provides memory
>> safety and thread safety guarantees.")
>> ------
>>
>> Hm, this would also prevent users from building the packages on their
>> own machines. We need a way to make changes like this but limit them to
>> the build farm.
>
> Would marking it unsubstitutable work? Or would we need build-local

If you mark it as #:substitutable? #f, then CI won’t try to build it but
users can still build it.

Now, I think we should avoid papering over CI configuration issues (did
I get that right?) by changing package definitions.

HTH!

Ludo’.
L
L
Leo Famulari wrote on 19 Jan 2021 21:17
(name . Ludovic Courtès)(address . ludo@gnu.org)
YAc+QcyYOb7LBtQv@jasmine.lan
On Tue, Jan 19, 2021 at 02:13:58PM +0100, Ludovic Court�s wrote:
Toggle quote (3 lines)
> Now, I think we should avoid papering over CI configuration issues (did
> I get that right?) by changing package definitions.

Yes, that's idiomatic English, if that is what you were asking about.

And I agree, the package definitions shouldn't include workarounds for
CI problems.
L
L
Ludovic Courtès wrote on 1 Feb 2021 21:56
(name . Leo Famulari)(address . leo@famulari.name)
87y2g7ik2i.fsf@gnu.org
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (9 lines)
> On Tue, Jan 19, 2021 at 02:13:58PM +0100, Ludovic Courtès wrote:
>> Now, I think we should avoid papering over CI configuration issues (did
>> I get that right?) by changing package definitions.
>
> Yes, that's idiomatic English, if that is what you were asking about.
>
> And I agree, the package definitions shouldn't include workarounds for
> CI problems.

This time I wasn’t asking about English :-), but rather about whether
the patch Efraim provided was indeed to paper over our CI problems.

Ludo’.
L
L
Leo Famulari wrote on 1 Feb 2021 22:13
(name . Ludovic Courtès)(address . ludo@gnu.org)
YBhu+CURvpfX/tz5@jasmine.lan
On Mon, Feb 01, 2021 at 09:56:05PM +0100, Ludovic Courtès wrote:
Toggle quote (3 lines)
> This time I wasn’t asking about English :-), but rather about whether
> the patch Efraim provided was indeed to paper over our CI problems.

Well, that patch does indeed "paper over" the CI problems.

Christopher Baines has graciously given me access to his Overdrive 1000
(monokuma), so I am able to test building packages on bare-metal
aarch64.

I'm testing building sbcl-cambl on it now. That is the package that
spurred this bug report.

Unfortunately, the aarch64 emulation we are using on berlin does cause a
lot of failures that can't be reproduced on real hardware. We are using
QEMU, right? If so, there is a new major QEMU update available on
guix-patches, and maybe that would fix some problems:


As I mentioned in that patch submission, there are some minor issues
with the update, but maybe we should just go for it.
L
L
Leo Famulari wrote on 1 Feb 2021 23:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
YBh6uzRbqIXkpKsc@jasmine.lan
On Mon, Feb 01, 2021 at 04:13:28PM -0500, Leo Famulari wrote:
Toggle quote (3 lines)
> I'm testing building sbcl-cambl on it now. That is the package that
> spurred this bug report.

This build [0] succeeds on the overdrive.

So, we should prioritize getting the overdrives back into the build
farm, and we can also try the newer QEMU.

[0] /gnu/store/spjz8fh5kx6fh4qx69d4f21r9km77v59-sbcl-cambl-4.0.0-1.7016d1a.drv
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 45826@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 45826
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch