| Summary: | re-keyword dev-libs/boost-1.34.1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tiziano Müller (RETIRED) <dev-zero> |
| Component: | New packages | Assignee: | C++ Team [disbanded] <cpp+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
boost-build is good for ~sparc. However, boost-1.34.0 ignores user CXXFLAGS, and on sparc this is very bad. Hence, I'm holding ~sparc for boost until that is explained. In this case, I have '-mcpu=ultrasparc3' and I really mean it unless there is a reason not to. Bug 59506 explains everything. Hmm, that shouldn't happen. arch-teams: please hold on. (In reply to comment #1) > boost-build is good for ~sparc. However, boost-1.34.0 ignores user CXXFLAGS, > and on sparc this is very bad. Hence, I'm holding ~sparc for boost until that > is explained. In this case, I have '-mcpu=ultrasparc3' and I really mean it > unless there is a reason not to. Bug 59506 explains everything. > I notice that the ebuild forces optimization=none, and it thinks it is building no optimization. Looking more carefully, however, I see that the call to gcc.compile.c++ actually ends up using my CXXFLAGS: Most tests pass, so adding ~sparc keyword. My original complaint was incorrect, based on misreading what I was seeing. ~sparc is good, and sorry for the noise. Most of the python tests fail, others hardly. Added ~ppc64. ~alpha/~ia64 done Marked ~hppa. This package is nuts. The tests have been running for 13 hours already, and no sign of ending is in sight.... I see random mentions of "FATAL"'s, "failed..." and "skipped", so I'm getting a tad worried about this package. Ah well. @kumba: hehe, I told you :-) Well, some of the tests are meant to fail and mips worked well last time I tested a CVS snapshot on swarm. (In reply to comment #7) > This package is nuts. The tests have been running for 13 hours already, and no > sign of ending is in sight.... > > I see random mentions of "FATAL"'s, "failed..." and "skipped", so I'm getting a > tad worried about this package. Ah well. > On sparc SB1000 (1x900 + 1x750), tests ran for over 24 hours, several failures in the python tests (as Markus noted in Comment #4). I'm seeing lots of failures on ppc too, but I've marked it ~ppc as well. I got to the end (finally -- TMPDIR ran out of space cause I was dumb and had it on a tmpfs mount), but it seems the XML log generation flunked. ...failed updating 25 targets... ...skipped 35 targets... ...updated 4823 targets... boost_root: /usr/obj/portage/dev-libs/boost-1.34.0/work/boost_1_34_0 locate_root: /usr/obj/portage/dev-libs/boost-1.34.0/work/boost_1_34_0 no errors detected Using /usr/obj/portage/dev-libs/boost-1.34.0/work/boost_1_34_0/bin.v2/status/rational_test.test to determine compilers **** exception(205): std::string: xml: unexpected eof ******** errors detected; see standard output for details ******** !!! ERROR: dev-libs/boost-1.34.0 failed. All in all, it looks clean to me though. I'll mark ~mips if you can't think of any reason to retrieve and view the log. And I'll hope 1.35.0 is a year or more off :P unstable on mips for both boost and boost-build. ping ? |
Dear arch-team-members, please re-keyword dev-utils/boost-build-1.34.0 and dev-libs/boost-1.34.0 for your arch. Please remember that the tests will take several hours and nearly 1GB of disk-space and the ebuild will not fail on test-failures. This policy is recommended by upstream. After running the tests, there will be a file "${ROOT}usr/share/doc/${PF}/status/cs-$(uname).html" which is a short summary of all the tests, if most of them succeeded, you can safely keyword it. If there are many failures, please write a comment here and we'll see how to proceed.