sci-libs/{sundials-3.2.1,cantera-2.4.0-r2} seem may be stabilized for amd64 Reproducible: Always
An automated check of this bug failed - repoman reported dependency errors (55 lines truncated): > dependency.bad sci-libs/sundials/sundials-3.2.1.ebuild: DEPEND: amd64(default/linux/amd64/17.0) ['sci-libs/hypre:=', 'sci-libs/klu:=', 'sci-libs/superlu_mt:='] > dependency.bad sci-libs/sundials/sundials-3.2.1.ebuild: RDEPEND: amd64(default/linux/amd64/17.0) ['sci-libs/hypre:=', 'sci-libs/klu:=', 'sci-libs/superlu_mt:='] > dependency.bad sci-libs/sundials/sundials-3.2.1.ebuild: DEPEND: amd64(default/linux/amd64/17.0/desktop) ['sci-libs/hypre:=', 'sci-libs/klu:=', 'sci-libs/superlu_mt:=']
An automated check of this bug failed - repoman reported dependency errors (55 lines truncated): > dependency.bad sci-libs/klu/klu-1.2.1.ebuild: DEPEND: amd64(default/linux/amd64/17.0) ['>=sci-libs/btf-1.2'] > dependency.bad sci-libs/klu/klu-1.2.1.ebuild: RDEPEND: amd64(default/linux/amd64/17.0) ['>=sci-libs/btf-1.2'] > dependency.bad sci-libs/klu/klu-1.2.1.ebuild: DEPEND: amd64(default/linux/amd64/17.0/desktop) ['>=sci-libs/btf-1.2']
An automated check of this bug succeeded - the previous repoman errors are now resolved.
Ack from @sci
Also CC'ing x86
amd64 stable
An automated check of this bug failed - the following atom is unknown: sci-libs/cantera-2.4.0-r2 Please verify the atom list.
An automated check of this bug failed - the following atom is unknown: sci-libs/cantera-2.4.0-r3 Please verify the atom list.
Sanity check failed: > sci-libs/klu-1.3.9 > depend x86 stable profile default/linux/x86/17.0 (11 total) > >=sci-libs/amd-2.4 > >=sci-libs/colamd-2.9 > rdepend x86 stable profile default/linux/x86/17.0 (11 total) > >=sci-libs/amd-2.4 > >=sci-libs/colamd-2.9
sci-libs/cantera-2.4.0-r5 contains fix for Python 3.7 and 3.8 site-packages installation paths. Currently in Gentoo the site packages are located under /lib for amd64 arch now for Python 3.7 and 3.8 instead of /lib64 like for python2.7 and python3.6. Please stabilize for amd64.
All sanity-check issues have been resolved
Dropping obsolete items from the list that were already done as part of bug 716960. Why not try stabilise sci-libs/sundials-4.1.0 instead, does it fix bug 715556?
Sanity check failed: > sci-libs/sundials-3.2.1 > depend x86 stable profile default/linux/x86/17.0 (11 total) > sci-libs/hypre:= > rdepend x86 stable profile default/linux/x86/17.0 (11 total) > sci-libs/hypre:=
(In reply to Andreas Sturmlechner from comment #13) > Dropping obsolete items from the list that were already done as part of bug > 716960. > > Why not try stabilise sci-libs/sundials-4.1.0 instead, does it fix bug > 715556? There are only two packages in portage tree that depend on sci-libssundials: sci-libs/dealii - optionally depends on <sci-libs/sundials-4:=; sci-libs/cantera As cantera ebuild under review is compatible with sci-libs/sundials-5.2.0 then it's maybe better to stabilize against it instead of sundials-4.1.0. But I don't know if it build on x86. I remember only that long time ago I successfully build sundials-3.x (<3.2) in x86 chroot. Anyway the issue for x86 sundials-3.2 is desirable to resolve too because it's dependence of other package.
None of those mentioned ebuilds currently even have a stable non-amd64 version, so there is no pressure put on you continuing the stabilisation of sundials-3.2.1. (In reply to Sergey Torokhov from comment #16) > Anyway the issue for x86 sundials-3.2 is desirable to resolve too because > it's dependence of other package. It is more likely that sci-libs/dealii is going to lose that option if upstream do not lift that restriction.
ping!
(In reply to Sergey Torokhov from comment #18) > ping! There's a blocker bug so a lot of us will not look at it until it is resolved. Also, as asturm observed, it is not clear why we are bothering for x86.
(In reply to Sam James from comment #19) > (In reply to Sergey Torokhov from comment #18) > > ping! > > There's a blocker bug so a lot of us will not look at it until it is > resolved. Also, as asturm observed, it is not clear why we are bothering for > x86. Block is for x86 but not for amd64. The sci-libs/cantera-2.4.0-r5 fix Python 3.7 and 3.8 site-packages installation paths, i.e. use new directory destination. Therefore I waiting for stabilization of cantera-2.4.0-r5 to drop cantera-2.4.0-r4. Maybe it wasn't good idea of mine to re-use already existing bug where previous revision was stabilized for amd64. Should I then at least remove x86 from stable request?
I'll unCC x86@ as there is nothing for it here.
Sanity check failed: > sci-libs/cantera-2.4.0-r4 > bdepend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6 > depend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6 > rdepend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6 > sci-libs/cantera-2.4.0-r5 > bdepend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6 > depend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6 > rdepend amd64 exp profile prefix/linux/amd64 (2 total) > dev-lang/python:3.6
amd64 stable. Closing.