Summary: | sys-apps/portage-2.1.10.3 : Blocked Packages with Bicatali Overlay | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Steven Trogdon <strogdon> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | frp.bissey, jlec |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Steven Trogdon
2011-07-18 20:46:54 UTC
It has nothing to do with portage os the overlay. The packages are quite different. Here your solution
unemerge everything which has to do with blas/lapck aand comes from the tree from your system. E.g. sci-libs/blas-reference, app-admin/eselect-blas etc
add following to your /etc/portage/package.mask
>sci-libs/blas-reference-10
and then go ahead again.
This did work. I must say I had considered removing everything (blas-reference, cblas-reference, lapack-reference and gsl) as suggested but didn't think the Blocking information pointed in this direction. And I would never have thought of adding
>sci-libs/blas-reference-10
to package.mask since the overlay profile has all the portage blas-reference masked. Updating world wouldn't go without it. Isn't this a Bug or something? In fact, if I comment out the above in package.mask after a world update then the Blocking error returns on subsequent attempts to update world.
(In reply to comment #2) > This did work. I must say I had considered removing everything (blas-reference, > cblas-reference, lapack-reference and gsl) as suggested but didn't think the > Blocking information pointed in this direction. And I would never have thought > of adding > > >sci-libs/blas-reference-10 > > to package.mask since the overlay profile has all the portage blas-reference > masked. Updating world wouldn't go without it. Isn't this a Bug or something? > In fact, if I comment out the above in package.mask after a world update then > the Blocking error returns on subsequent attempts to update world. Masking somehting in the overlay should work for a normal emerge. I cannot tell ou why this isn't working for the bicatali overlay. An interesting question would be whether or not it affects only bicatali's overlay. It should work out of the box and not need to add the block in the local package.mask (I don't think removing stuff was necessary before the masking - that's only if you were migrating to the overlay). Steve, are R-2.12+ properly masked because of the sage-on-gentoo overlay? (In reply to comment #4) > An interesting question would be whether or not it affects only bicatali's > overlay. It should work out of the box and not need to add the block in the > local package.mask (I don't think removing stuff was necessary before the > masking - that's only if you were migrating to the overlay). > > Steve, are R-2.12+ properly masked because of the sage-on-gentoo overlay? I believe you are correct about removing stuff before the masking. Yes, all R-2.12+ stuff is masked here because of sage-on-gentoo. I keep forgetting that commenting doesn't add me to CC, and this hasn't been assigned to science so I don't receive it as part of the alias either. So portage 2.2.0_alpha46 here: eix m4ri [I] sci-libs/m4ri Available versions: (~)20090512!m[1] (~)20100221!m[1] (~)20100701!m[2] (~)20100701!m[3] (~)20100817!m[2] (~)20100817!m[3] [M](~)20110613!m[2] [M](~)20110613!m[3] [M]**99999999!m[2] [M]**99999999!m[3] {debug openmp sse2 static-libs} Installed versions: 20100817!m[3](09:50:41 07/23/11)(sse2 -debug -openmp -static-libs) Homepage: http://m4ri.sagemath.org/ Description: Method of four russian for inversion (M4RI)) [1] "science" /var/lib/layman/science [2] "sage-on-gentoo" /var/lib/layman/sage-on-gentoo [3] "sage" /home/francois/Work/Overlays/Gentoo-sage Notice that m4ri-20110613+ is package masked from the sage-on-gentoo overlay and eix reports it correctly. However: emerge -puDv world These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild U ~] sci-libs/m4ri-20110613 [20100817] USE="sse2 -debug -openmp -static-libs" 0 kB [1] [ebuild U ] dev-libs/libevent-2.0.12 [2.0.10] USE="-static-libs -test" 804 kB [0] [ebuild U ~] app-admin/eselect-1.2.16-r1 [1.2.15-r1] USE="-bash-completion -doc" 166 kB [2] Total: 3 packages (3 upgrades), Size of downloads: 969 kB Portage tree and overlays: [0] /usr/portage [1] /home/francois/Work/Overlays/Gentoo-sage [2] /var/lib/layman/bicatali So portage wants to update something that's package masked in the sage-on-gentoo overlay. I made sure there wasn't anything interfering in package unmask too. Adding a line in /etc/portage/package.mask worked. Curiously R is indeed masked properly, as if the problem only applies to overlay ebuilds. portage-2.1.10.3 here. I don't have m4ri in my local overlay and there is no issue. However, if I copy the sage-on-gentoo sci-libs/m4ri folder to my local overlay and update eix then the issue appears: eix m4ri [I] sci-libs/m4ri Available versions: (~)20090512!m[1] (~)20100221!m[1] (~)20100701!m[2] (~)20100701!m[3] (~)20100817!m[2] (~)20100817!m[3] [M](~)20110613!m[2] [M](~)20110613!m[3] [M]**99999999!m[2] [M]**99999999!m[3] {debug openmp sse2 static-libs} Installed versions: 20100817!m[2](07:13:52 PM 07/22/2011)(openmp sse2 -debug -static-libs) Homepage: http://m4ri.sagemath.org/ Description: Method of four russian for inversion (M4RI) [1] "science" /var/lib/layman/science [2] "sage-on-gentoo" /var/lib/layman/sage-on-gentoo [3] "local-overlay" /usr/local/portage emerge -puDv world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] sci-libs/m4ri-20110613 [20100817] USE="openmp sse2 -debug -static-libs" 441 kB [1=>2] Total: 1 package (1 upgrade), Size of downloads: 441 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/sage-on-gentoo [2] /usr/local/portage Removing m4ri-20110613.ebuild from my local overlay fixed the problem. Therefore, even though eix reported m4ri-20110613 from my local overlay as being package masked, it really wasn't! There does appear to be some ambiguity in how package masked stuff is being handled. |