Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 797574 - dev-lisp/sbcl: rebuilds should not break consumers (such as sci-mathematics/maxima)
Summary: dev-lisp/sbcl: rebuilds should not break consumers (such as sci-mathematics/m...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Andrey Grozin
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2021-06-22 13:03 UTC by Gabriel Linder
Modified: 2023-08-06 11:15 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
sbcl-2.1.6.ebuild (sbcl-2.1.6.ebuild,8.92 KB, text/plain)
2021-07-17 19:00 UTC, Michael Orlitzky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Linder 2021-06-22 13:03:28 UTC
Rebuilding sbcl change core timestamp, and maxima will not start until it is rebuilt with the new core. So a rebuild of sbcl should trigger a rebuild of maxima, after sbcl of course.

Correct output with sbcl and maxima in sync :
$ maxima
Maxima 5.45.1 https://maxima.sourceforge.io
using Lisp SBCL 2.1.5
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) _

Output when sbcl and maxima are not in sync :
$ maxima
fatal error encountered in SBCL pid 32064 tid 32064:
core was built for runtime "localhost-portage-2021-06-02-12-38-22" but this is "localhost-portage-2021-06-22-14-46-31"

Reproducible: Always

Steps to Reproduce:
1. emerge maxima with sbcl use flag, ensure it start
2. rebuild sbcl
3. maxima won't start
4. rebuid maxima
5. maxima works again
Comment 1 Michael Orlitzky gentoo-dev 2021-07-16 00:27:32 UTC
There is no way to force a rebuild of maxima whenever SBCL is rebuilt. Perhaps instead we should hack the SBCL "build id" so that it is consistent between rebuilds of SBCL. The offending code is in SBCL's make-config.sh, which currently does

echo '"'`hostname`-`id -un`-`date +%Y-%m-%d-%H-%M-%S`'"' > output/build-id.inc

We could put something like ${PV} in there instead, and then have maxima rebuild whenever the subslot (0/${PV}) of SBCL changes.
Comment 2 Andrey Grozin gentoo-dev 2021-07-16 11:11:00 UTC
Everything was fine in 5.44.0-r9, see the line
DEP="dev-lisp/${LISP}:="
When the ebuild was completely re-written (5.44.0-r10), this := got missing. For all lisps, not just for sbcl. It should be restored for all lisps in LISP_DEPEND
Comment 3 Michael Orlitzky gentoo-dev 2021-07-16 12:55:53 UTC
(In reply to Andrey Grozin from comment #2)
> Everything was fine in 5.44.0-r9, see the line
> DEP="dev-lisp/${LISP}:="
> When the ebuild was completely re-written (5.44.0-r10), this := got missing.
> For all lisps, not just for sbcl. It should be restored for all lisps in
> LISP_DEPEND

That's part of it, but := won't trigger a rebuild of maxima if the same version of SBCL is re-emerged.

Also, cmucl, gcl, and clozurecl don't have subslots to make := meaningful, but maybe that's a shortcoming of those packages...
Comment 4 Andrey Grozin gentoo-dev 2021-07-16 14:22:55 UTC
(In reply to Michael Orlitzky from comment #3)
> Also, cmucl, gcl, and clozurecl don't have subslots to make := meaningful,
> but maybe that's a shortcoming of those packages...
At least for sbcl, clisp, ecls := is absolutely mandatory. When a user ungrades one of them, maxima must be recommpiled.
Comment 5 Larry the Git Cow gentoo-dev 2021-07-17 18:58:26 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad7de14616de70335cee40cf253d690f6c27a178

commit ad7de14616de70335cee40cf253d690f6c27a178
Author:     Michael Orlitzky <mjo@gentoo.org>
AuthorDate: 2021-07-17 17:35:32 +0000
Commit:     Michael Orlitzky <mjo@gentoo.org>
CommitDate: 2021-07-17 18:56:02 +0000

    sci-mathematics/maxima: add slot:= operators for lisp dependencies.
    
    Maxima needs to be rebuilt when its lisp engine changes. Of the lisps
    supported by maxima, dev-lisp/sbcl, dev-lisp/ecls, and dev-lisp/clisp
    make use of subslots. This new revision adds := to the corresponding
    dependencies. This partially addresses bug 797574 by forcing rebuilds
    of maxima when sbcl is upgraded.
    
    Bug: https://bugs.gentoo.org/797574
    Package-Manager: Portage-3.0.20, Repoman-3.0.2
    Signed-off-by: Michael Orlitzky <mjo@gentoo.org>

 .../maxima/{maxima-5.45.1-r1.ebuild => maxima-5.45.1-r2.ebuild}     | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
Comment 6 Michael Orlitzky gentoo-dev 2021-07-17 19:00:44 UTC
Created attachment 724579 [details]
sbcl-2.1.6.ebuild

I've added the slot operators in maxima, and have attached an example ebuild for sbcl-2.1.6 that sets the "build id" to $PV.
Comment 7 Michael Orlitzky gentoo-dev 2022-09-10 17:45:39 UTC
Updating the summary as this is waiting on a change in dev-lisp/sbcl (comment #6) and is not really a maxima issue.
Comment 8 Steven Trogdon 2023-08-02 19:45:54 UTC
Another situation where this issue appeared:

https://github.com/cschwan/sage-on-gentoo/issues/750
Comment 9 Michael Orlitzky gentoo-dev 2023-08-02 20:20:10 UTC
Andrey is now maintaining SBCL.

All that remains to fix this is to ensure that the SBCL "build id" is $PV. The attached ebuild does this but is outdated. IIRC this is the relevant bit:

  # ...because we use our own build id. SBCL will refuse to run a
  # program (e.g. maxima) that was compiled against an SBCL with a
  # different build id. However, the build id that upstream generates
  # changes every time you re-build SBCL, even if nothing else has
  # changed. Thus rebuilding SBCL (likely a no-op) can disable your
  # copy of maxima. To avoid that, we use a build id that changes
  # only when our subslot changes, a trigger upon  which we can
  # force rebuilds of our consumers. Was bug 797574.
  mkdir output || die
  echo "\"${PV}\"" > output/build-id.inc || die
Comment 10 Michael Orlitzky gentoo-dev 2023-08-02 20:21:32 UTC
Oh, you also need this BEFORE the line in my previous comment:

# Don't echo random junk into output/build-id.inc...
  sed -e '/echo .* > output\/build-id\.inc/d' \
      -i make-config.sh || die
Comment 11 Steven Trogdon 2023-08-03 00:50:25 UTC
From the given sbcl-2.1.6 ebuild the following is also needed after comment #9

	# Also, don't run clean.sh during the build. First of all: why?
	# Second, because it clobbers the build-id.inc that we just created.
	sed -e '/sh clean\.sh/d' -i make-config.sh || die

else build-id.inc is deleted.
Comment 12 Larry the Git Cow gentoo-dev 2023-08-06 11:15:27 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=014d8209fe9d4e06bfeac40debc3dd762d59ae1c

commit 014d8209fe9d4e06bfeac40debc3dd762d59ae1c
Author:     Andrey Grozin <grozin@gentoo.org>
AuthorDate: 2023-08-06 11:15:02 +0000
Commit:     Andrey Grozin <grozin@gentoo.org>
CommitDate: 2023-08-06 11:15:02 +0000

    dev-lisp/sbcl: bump to 2.3.7
    
    Closes: https://bugs.gentoo.org/797574
    Signed-off-by: Andrey Grozin <grozin@gentoo.org>

 dev-lisp/sbcl/Manifest                   |   2 +
 dev-lisp/sbcl/files/build-id-2.3.6.patch |  12 ++
 dev-lisp/sbcl/sbcl-2.3.7.ebuild          | 271 +++++++++++++++++++++++++++++++
 3 files changed, 285 insertions(+)