We need a more recent boost for schroot. Please pick the version for stabilization: !!! All ebuilds that could satisfy ">=dev-libs/boost-1.42.0" have been masked. !!! One of the following masked packages is required to complete your request: - dev-libs/boost-1.42.0-r2 (masked by: ~x86 keyword) - dev-libs/boost-1.42.0-r1 (masked by: ~x86 keyword) - dev-libs/boost-1.42.0 (masked by: ~x86 keyword)
Can we have arches added?
I propose to stabilize =dev-libs/boost-1.42.0-r2
dev-libs/boost is unmaintained since quite some time, as there is no dev willing to maintain it (imo it should be dropped to m-needed). If you're going to fix any resulting issues, go for -r2.
(In reply to comment #3) > dev-libs/boost is unmaintained since quite some time Okay, adding arches.
Please add #345265 as a dependency.
boost-build is a dependence of boost, and there is a bug for not respect LDFLAGS.
Emerging this version of dev-libs/boost with USE=test requires greater than 13G of disc space: is that right? If it is, maybe a check for disc space in the ebuild would be appropriate for USE=test?
Stable for HPPA.
Building and test (appart from the 12G disk use) works fine for me on x86. tested a few package depending on it too and it's ok.
Tested on SPARC, all tests passed. Took ages though :)
Stop, it was only boost-build that passed, for some reason boost didn't pass its tests. Rerunning the tests again
OK, boost passed all its tests on SPARC. Must have incorrectly run it first time around, I guess.
Note that successfully installing boost with FEATURES="test" does not mean that it passes all test. In fact it's not very useful for arch tester to install boost with tests enabled, because all it does it generate a test report. That means that it will never fail (expect for breakage outside of the test suite, i.e. bug in the ebuild, running out of disk space, ...). A lot of boost's tests fail depending on the used compiler. Just take a look at upstreams test matrix if you're curious. The best thing you can do to test boost is to build its reverse deps (with tests enabled) and to make sure they keep working.
Hmm, is it possible to collect its RDEPENDS and build them all with FEATURES="test"?
(In reply to comment #14) > Hmm, is it possible to collect its RDEPENDS and build them all with > FEATURES="test"? > Use the tatt package (https://github.com/tom111/tatt), or equery to find out all packages.
# tatt -d dev-libs/boost Traceback (most recent call last): File "/usr/bin/tatt-2.6", line 177, in <module> writerdepscript(pack) NameError: name 'writerdepscript' is not defined Ok, I'll do this manually and file a bug report for this one.
(In reply to comment #14) > Hmm, is it possible to collect its RDEPENDS and build them all with > FEATURES="test"? > Does the dindex satisfy your requirements? http://tinderbox.dev.gentoo.org/misc/dindex/
x86 OK. Packages I use that are rdeps for boost compiled and ran fine with brief testing.
Just tested it with OpenOffice (unmasked build) and Povray (unstable) on SPARC, seems to work fine.
x86 done. Thanks everybody for testing and reporting. Please keep the QA Warning in bug 334467 in mind. Thanks!
ppc done
amd64 done
It seems boost 1.42.0 has a bug. To be more specific it uses invalid c++ code ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915 , https://svn.boost.org/trac/boost/ticket/3844 ). I hit this bug compiling pokerth-0.8.2 with gcc 4.5.2.
(In reply to comment #24) > It seems boost 1.42.0 has a bug. To be more specific it uses invalid c++ code ( > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915 , > https://svn.boost.org/trac/boost/ticket/3844 ). > > I hit this bug compiling pokerth-0.8.2 with gcc 4.5.2. Please don't post loosely related comments here, but open a new bug, possibly blocking this one.
Has been tested on SPARC since November when I built OpenOffice w/ it. dev-util/boost-build-1.42.0 passes all its tests, as did dev-libs/boosts-1.42.0-r2. Please stabilise.
sparc done
ppc64 stable
Stable on alpha.
arm stable
ia64/s390/sh stable, and i'm not closing this because it won't let me close it since there are dependencies that aren't closed
None of these bugs stops stabilization. Removing them and closing.
