Bug 574134 – dev-lisp/sbcl-1.3.0 stable request

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description nvinson234 2016-02-07 21:39:15 UTC]

Please stabilize.  

Targets: amd64, x86, ppc, sparc

The last bug filed against this version that I could find was #563812 and was resolved on November 5, 2015.

[Comment 1 Ulrich Müller 2016-02-13 16:19:31 UTC]

Reassigning to maintainers.

What would be the reason to stabilise 1.3.0 instead of the newer 1.3.1?

[Comment 2 Stelian Ionescu 2016-02-13 16:22:27 UTC]

I think it's better to stabilize 1.3.1, because it adds several MIPS fixes and ARM64 threading support, so it's a better candidate for long-term stabilization.

[Comment 3 nvinson234 2016-02-13 17:25:52 UTC]

(In reply to Ulrich Müller from comment #1)
> Reassigning to maintainers.
> 
> What would be the reason to stabilize 1.3.0 instead of the newer 1.3.1?

While not related to stabilization, my plan is to cleanup sbcl by removing outdated versions.  According to 'equery d -a sbcl' all versions up to but not including 1.3.0 can be removed if 1.3.0 is stabilized.  That's why I picked 1.3.0 instead of 1.3.1.  The package that requires 1.3.0 or older is fricas.  I realize fricas is also marked unstable, but it's not uncommon for users who wish to only run stable systems to make one-off exceptions for packages like fricas when no alternative is available.

Therefore, to minimize breakage with such setups I requested 1.3.0 be stabilized.  Otherwise, I'd need to keep 1.1.18 in the tree to minimize breakage with such setups.

(In reply to Stelian Ionescu from comment #2)
> I think it's better to stabilize 1.3.1, because it adds several MIPS fixes
> and ARM64 threading support, so it's a better candidate for long-term
> stabilization.

I have no qualms with stabilizing 1.3.1 other than the reasons above.  Therefore if there is a strong preference to 1.3.1 being stabilized, I would ask that it be stabilized in addition to 1.3.0 as opposed to stabilizing instead of 1.3.0.

[Comment 4 Ulrich Müller 2016-02-13 17:54:32 UTC]

(In reply to nvinson234 from comment #3)
> While not related to stabilization, my plan is to cleanup sbcl by removing
> outdated versions.  According to 'equery d -a sbcl' all versions up to but
> not including 1.3.0 can be removed if 1.3.0 is stabilized.

Same if 1.3.1 is stabilised. In both cases, all versions except for 1.3.0 and 1.3.1 could be removed.

> That's why I picked 1.3.0 instead of 1.3.1.  The package that requires
> 1.3.0 or older is fricas.  I realize fricas is also marked unstable, but
> it's not uncommon for users who wish to only run stable systems to make
> one-off exceptions for packages like fricas when no alternative is
> available.

That's a valid argument but not a very strong one. fricas has no stable version so we won't break the dependency tree. And users making one-off exceptions are on their own in any case (and certainly they will know how to make another exception for the dependency).

> [...]
> I have no qualms with stabilizing 1.3.1 other than the reasons above. 
> Therefore if there is a strong preference to 1.3.1 being stabilized, I would
> ask that it be stabilized in addition to 1.3.0 as opposed to stabilizing
> instead of 1.3.0.

Stabilising two versions in the same slot at the same time would be very uncommon, and would mean double work for arch teams.

[Comment 5 Andrey Grozin 2016-02-13 18:57:59 UTC]

There is a huge regression with respect to memory usage in 1.3.1 under some circumstances. 1.3.0 easily compiles fricas in 1 gigabyte; 1.3.1 fails to compile it even in 24 gigabytes. This is while compiling a rather short function: it works for some time (the larger memory the longer) with load level 1, then the memory is exhausted. It seems that the memory usage simply grows linearly with time. Nobody knows exactly under what circumstances this regression is triggered. It may happen in other use cases, not only in compiling fricas. I thought to hard mask 1.3.1 because of this, but decided not to do this, but simply make fricas depend on <=sbcl-1.3.0. Strictly speaking, this does not prevent stabilization of 1.3.1 because fricas has no stable versions. But something in 1.3.1 is definitely very wrong.

[Comment 6 Ulrich Müller 2016-02-13 20:01:27 UTC]

I see. I guess arch teams can go ahead with stabilising sbcl-1.3.0 then.

[Comment 7 Agostino Sarubbo 2016-03-14 15:17:59 UTC]

This request cannot be completed because of the following repoman error(s):

   dev-lisp/sbcl/sbcl-1.3.0.ebuild: DEPEND: amd64(default/linux/amd64/13.0)
['>=dev-lisp/asdf-3.1:=']
 


Since the amd64 team is unable to continue this task, I'm removing the amd64 arch team from the CC field. Feel free to cc the amd64 arch team again when you provide the complete list of the missing dependencies.

[Comment 8 nvinson234 2016-06-26 05:32:14 UTC]

(In reply to Agostino Sarubbo from comment #7)
> This request cannot be completed because of the following repoman error(s):
> 
>    dev-lisp/sbcl/sbcl-1.3.0.ebuild: DEPEND: amd64(default/linux/amd64/13.0)
> ['>=dev-lisp/asdf-3.1:=']
>  
> 
> 
> Since the amd64 team is unable to continue this task, I'm removing the amd64
> arch team from the CC field. Feel free to cc the amd64 arch team again when
> you provide the complete list of the missing dependencies.

Re-added amd64 as I think the tree is ready for a second try.  Both asdf and uiop have been stabilized for amd64.

[Comment 9 Elias Pipping 2016-09-25 17:34:48 UTC]

Is the problem with fricas still an issue? Please see also https://bugs.launchpad.net/sbcl/+bug/1532253

[Comment 10 Andrey Grozin 2016-09-27 12:59:27 UTC]

(In reply to Elias Pipping from comment #9)
> Is the problem with fricas still an issue? Please see also
> https://bugs.launchpad.net/sbcl/+bug/1532253
fricas-1.3.0 can be successfully compiled with recent versions of sbcl. It still takes more memory then for sbcl-1.3.0, but not too much. I checked this for >=sbcl-1.3.6, and therefore put >=sbcl-1.3.6 to DEPEND in fricas-1.3.0. According to docs, >=sbcl-1.3.5 should be fine, though I haven't checked this myself. So, there seems to be no reasons not to stabilize some recent version of sbcl. Then we'll at last get rid of sbcl-1.1.*. Hurrah!

[Comment 11 nvinson234 2016-09-27 13:14:35 UTC]

For the record, I wrote this bug with stabilizing 1.3.0 in mind, and I have not checked any of the newer versions to see if they are ready for stabilization.  I am not sure why the version in this bug's title got changed, but I am put it back to 1.3.0 for now.  If anyone is confident that a version > 1.3.0 can be stabilized, please update the title to that version and add a comment stating you have reviewed that version.  Thanks.

[Comment 12 Aaron Bauman (RETIRED) 2016-12-27 10:11:12 UTC]

sbcl-1.3.0 is still not stable.  Please CC arches when ready.

[Comment 13 nvinson234 2016-12-28 02:37:15 UTC]

(In reply to Aaron Bauman from comment #12)
> sbcl-1.3.0 is still not stable.  Please CC arches when ready.

This makes no sense at all.  A request to stabilize a package is aborted because the package is not already stabilized...

Now, I'm sure that's not what you meant.  

We need to know what went wrong in order to fix the issue.  Please provide those details.

Sent from a mobile device.

[Comment 14 Agostino Sarubbo 2016-12-28 08:40:42 UTC]

Dear Maintainer (or who is mainly involved in this stable request),

This is an auto-generated message that will move the current component to the new component Stabilization.
To ensure that the stabilization will proceed correctly, please fill the fields "Atoms to stabilize" and "Runtime testing required" as described here:
https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa

[Comment 15 Andrey Grozin 2016-12-28 14:30:13 UTC]

Good runtime testing: emerge sci-mathematics/maxima with USE=sbcl. If it (any version) emerges successfully, sbcl is fine.

[Comment 16 Andrey Grozin 2016-12-28 14:33:02 UTC]

*** Bug 582964 has been marked as a duplicate of this bug. ***

[Comment 17 Michael Palimaka (kensington) 2016-12-28 16:31:44 UTC]

An automated check of this bug failed - the following atoms are unknown:

x86:
spark:
amd64:
ppc:

Please verify the atom list.

[Comment 18 Michael Palimaka (kensington) 2016-12-28 19:19:34 UTC]

An automated check of this bug succeeded - the previous repoman errors are now resolved.

[Comment 19 Agostino Sarubbo 2016-12-29 10:06:25 UTC]

amd64 stable

[Comment 20 Agostino Sarubbo 2016-12-29 10:47:07 UTC]

x86 stable

[Comment 21 Agostino Sarubbo 2017-01-01 12:48:11 UTC]

ppc stable

[Comment 22 Stabilization helper bot 2017-01-10 06:04:23 UTC]

An automated check of this bug failed - repoman reported dependency errors (15 lines truncated): 

> dependency.bad dev-lisp/sbcl/sbcl-1.3.11.ebuild: DEPEND: sparc(default/linux/sparc/13.0) ['>=dev-lisp/asdf-3.1:=']
> dependency.bad dev-lisp/sbcl/sbcl-1.3.11.ebuild: RDEPEND: sparc(default/linux/sparc/13.0) ['>=dev-lisp/asdf-3.1:=']
> dependency.bad dev-lisp/sbcl/sbcl-1.3.11.ebuild: DEPEND: sparc(default/linux/sparc/13.0/desktop) ['>=dev-lisp/asdf-3.1:=']
> dependency.bad dev-lisp/uiop/uiop-3.1.5.ebuild: RDEPEND: sparc(default/linux/sparc/13.0) ['~dev-lisp/asdf-3.1.5']
> dependency.bad dev-lisp/uiop/uiop-3.1.5.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/desktop) ['~dev-lisp/asdf-3.1.5']
> dependency.bad dev-lisp/uiop/uiop-3.1.5.ebuild: RDEPEND: sparc(default/linux/sparc/13.0/desktop/gnome) ['~dev-lisp/asdf-3.1.5']

[Comment 23 Agostino Sarubbo 2017-01-22 16:27:56 UTC]

sparc stable. Closing.