Re: branch master updated: gnu: sbcl: Update to 2.1.4.

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Leo Famulari]

On Sat, May 01, 2021 at 07:53:26AM -0400, guix-commits@gnu.org wrote:
> commit c04dfb39f62f764b1c3988d9b0fcedc8221afa67
> Author: Pierre Neidhardt <mail@ambrevar.xyz>
> AuthorDate: Sat May 1 13:53:09 2021 +0200
> 
>     gnu: sbcl: Update to 2.1.4.
>     
>     * gnu/packages/lisp.scm (sbcl): Update to 2.1.4.

Hi Pierre,

I noticed this evaluation had a lot of queued builds:

https://ci.guix.gnu.org/eval/29613

It's based on the SBCL update:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c04dfb39f62f764b1c3988d9b0fcedc8221afa67

`guix refresh -l sbcl` shows "Building the following 221 packages would
ensure 988 dependent packages are rebuilt [...]"

Remember, the rebuild limit for the master branch is 300 rebuilds,
according to item 8 of the manual section Submitting Patches:

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

Sometimes it's fine to go over the limit a little bit, especially for 
packages that are cheap to build, but SBCL packages are pretty
expensive.

If we do want to be able to update SBCL on the master branch, please
coordinate it in advance. The aarch64 builders, which are mostly
emulated on x86_64 machines, cannot build SBCL [0], and we need to
cancel those derivations manually, or they'll spend weeks repeatedly
failing to build it. Maybe we should just disable SBCL on aarch64 until
the build farm can build it reliably?

The build farm seems to have mostly built the derivations now (aside
from aarch64), so there's no action required at this point.

Leo

[0] <https://bugs.gnu.org/45826>

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

Hi Leo,

Indeed, as far as I can remember we've always updated SBCL directly on
master, because it's one of those exceptions.

> `guix refresh -l sbcl` shows "Building the following 221 packages would
> ensure 988 dependent packages are rebuilt [...]"

Note that most of these packages are "cl-*" packages, which effectively
just copy the source code of SBCL packages.  They don't compile anything.

> Remember, the rebuild limit for the master branch is 300 rebuilds,
> according to item 8 of the manual section Submitting Patches:
>
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
>
> Sometimes it's fine to go over the limit a little bit, especially for 
> packages that are cheap to build, but SBCL packages are pretty
> expensive.

In my experience it is indeed one of theses cases where it's fine to go
over the limit, because beside the check phase of very few packages
(sbcl-lparallel and sbcl-ironclad come to mind), most SBCL packages
build in an instant.

The whole set of Lisp packages builds in a few minutes on my machine.

What do you think?  Do you think it would still be wiser to update on
staging instead?

What do you mean with "coordinate it in advance"?  Is there a better way
to handle the process?

> The aarch64 builders, which are mostly emulated on x86_64 machines,
> cannot build SBCL [0], and we need to cancel those derivations
> manually, or they'll spend weeks repeatedly failing to build it. Maybe
> we should just disable SBCL on aarch64 until the build farm can build
> it reliably?

Sure thing, but I'm not an aarch64 user so maybe someone else would like
to comment about this.
Thoughts, anyone?

Otherwise I can remove aarch64 from the list of supported systems in the
SBCL package.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On Sun, May 02, 2021 at 11:57:10AM +0200, Pierre Neidhardt wrote:
> Indeed, as far as I can remember we've always updated SBCL directly on
> master, because it's one of those exceptions.

Alright, I didn't know that. Let's keep the status quo in that case.
Maybe we should mention this kind of exception to the guidelines in the
manual. I want to revisit those guidelines after the upcoming release.

> What do you mean with "coordinate it in advance"?  Is there a better way
> to handle the process?

For example, we could make an sbcl-updates branch and build that in its
own Cuirass job. It makes it a little easier to schedule and manage the
computing resources used for a task. But if these packages are actually
cheap to build, then it's probably not necessary.

> Otherwise I can remove aarch64 from the list of supported systems in the
> SBCL package.

We try to avoid limiting the utility of packages just to work around
problems with the build farm (SBCL does build on real aarch64 hardware),
so it would be ideal if we could avoid this. I don't really know a good
way to deal with this particular problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 87 bytes --]

OK, thanks for the update!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]