Summary: | dev-lisp/sbcl-1.3.0 stable request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | nvinson234 |
Component: | Stabilization | Assignee: | Panagiotis Christopoulos (RETIRED) <pchrist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs, common-lisp, grozin, nvinson234, proxy-maint |
Priority: | Normal | Keywords: | STABLEREQ |
Version: | unspecified | Flags: | stable-bot:
sanity-check+
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: |
=dev-lisp/sbcl-1.3.11 amd64 ppc sparc x86
=dev-lisp/uiop-3.1.5 sparc
=dev-lisp/sbcl-1.3.11 sparc
|
Runtime testing required: | Yes |
Bug Depends on: | 577744 | ||
Bug Blocks: |
Description
nvinson234
2016-02-07 21:39:15 UTC
Reassigning to maintainers. What would be the reason to stabilise 1.3.0 instead of the newer 1.3.1? 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. (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. (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. 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. I see. I guess arch teams can go ahead with stabilising sbcl-1.3.0 then. 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. (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. Is the problem with fricas still an issue? Please see also https://bugs.launchpad.net/sbcl/+bug/1532253 (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! 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. sbcl-1.3.0 is still not stable. Please CC arches when ready. (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. 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 Good runtime testing: emerge sci-mathematics/maxima with USE=sbcl. If it (any version) emerges successfully, sbcl is fine. *** Bug 582964 has been marked as a duplicate of this bug. *** An automated check of this bug failed - the following atoms are unknown: x86: spark: amd64: ppc: Please verify the atom list. An automated check of this bug succeeded - the previous repoman errors are now resolved. amd64 stable x86 stable ppc stable 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']
sparc stable. Closing. |