The current stable gives a nasty blocker on bison: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-devel/bison:0 (sys-devel/bison-1.875d::gentoo, ebuild scheduled for merge) pulled in by <sys-devel/bison-2.4 required by (dev-lang/tinycobol-0.64::gentoo, ebuild scheduled for merge) (sys-devel/bison-2.4.3::gentoo, installed) pulled in by >=sys-devel/bison-2.4.3 required by (www-client/chromium-15.0.874.21::x-portage, ebuild scheduled for merge) (and 2 more with the same problem) If it's OK to stabilize, please add STABLEREQ keyword and CC arches.
Maintainer timeout (short because stable is sort of broken), CC-ing arches.
(In reply to comment #1) > Maintainer timeout (short because stable is sort of broken), CC-ing arches. Sorry, didn't read the text of this bug yet - just saw a stabilization request with normal priority in the list and didn't get to having a closer look. Thanks for handling this.
Is =dev-db/vbisam-2.0 also ready to go? Tinycobol depends on it...
(In reply to comment #3) > Is =dev-db/vbisam-2.0 also ready to go? Tinycobol depends on it... I think so, it'd be a first-time stabilization. If it compiles fine, it's perfect (unless maintainer says otherwise).
(In reply to comment #4) > (In reply to comment #3) > > Is =dev-db/vbisam-2.0 also ready to go? Tinycobol depends on it... > > I think so, it'd be a first-time stabilization. If it compiles fine, it's > perfect (unless maintainer says otherwise). He doesn't.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Is =dev-db/vbisam-2.0 also ready to go? Tinycobol depends on it... > > > > I think so, it'd be a first-time stabilization. If it compiles fine, it's > > perfect (unless maintainer says otherwise). > > He doesn't. Ok :-) Both stable on x86 now. Thanks!
ppc done; closing as last arch
