Summary: | dev-cpp/eigen-2.0.13 fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde, orzel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 398545 | ||
Bug Blocks: | |||
Attachments: | build.log.gz |
Description
Paweł Hajdan, Jr. (RETIRED)
2011-11-22 07:42:04 UTC
2.0.13 is quite old. Do you still have problem with eigen on gentoo ? (In reply to comment #1) > 2.0.13 is quite old. Do you still have problem with eigen on gentoo ? That's the latest stable version. Should a more recent version be stabilized? I'm not going to re-test since this report is not even 30 days old. gentoo64 eigen # emerge =dev-cpp/eigen-2.0.13 -- Configuring incomplete, errors occurred! * ERROR: dev-cpp/eigen-2.0.13 failed (test phase): * cmake failed * ebuild.sh, line 75: Called src_test * environment, line 2895: Called cmake-utils_src_configure * environment, line 798: Called _execute_optionaly 'src_configure' * environment, line 301: Called enable_cmake-utils_src_configure * The specific snippet of code: * "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake failed"; It fell over at an earlier stage. Could not complete the 'configure for the test' phase. (In reply to comment #2) > (In reply to comment #1) > > 2.0.13 is quite old. Do you still have problem with eigen on gentoo ? > > That's the latest stable version. Should a more recent version be stabilized? > > I'm not going to re-test since this report is not even 30 days old. Of course, 2.0.17 is out and should definitely be used in production / stable tree, see: http://eigen.tuxfamily.org i've just renamed last 2.0.16 to my local overlay but i can't manage to emerge. I'm not familiar enough to understand how to fix the pb, but i can explain * The source directory '/var/tmp/portage/dev-cpp/eigen-2.0.17/work/eigen-eigen-2.0.17' doesn't exist The tarballs are directly provided by the mercurial soft at bitbucket. And recently (~nov 2011), they changed how this stuff works and the directory that the tarballs extracts has changed. We got some reports from BSD with similar problems too. It used to extract to, say, 'eigen-2.0.17/', and now extracts to 'eigen-eigen-b23437e61a07/' (where the last part is the hash to the mercurial version labelled as '2.0.17'). If someone know how to fix this.. (In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > 2.0.13 is quite old. Do you still have problem with eigen on gentoo ? > > > > That's the latest stable version. Should a more recent version be stabilized? > > > > I'm not going to re-test since this report is not even 30 days old. > > Of course, 2.0.17 is out and should definitely be used in production / stable > tree, see: > http://eigen.tuxfamily.org I will take care of this. okay I played around and there where random errors in the testsuite when repeated. I assume it to be a parallel test bug. Could you please test with serial build? (In reply to comment #5) > i've just renamed last 2.0.16 to my local overlay but i can't manage to emerge. > I'm not familiar enough to understand how to fix the pb, but i can explain > > * The source directory > '/var/tmp/portage/dev-cpp/eigen-2.0.17/work/eigen-eigen-2.0.17' doesn't exist > > The tarballs are directly provided by the mercurial soft at bitbucket. And > recently (~nov 2011), they changed how this stuff works and the directory that > the tarballs extracts has changed. We got some reports from BSD with similar > problems too. > It used to extract to, say, 'eigen-2.0.17/', and now extracts to > 'eigen-eigen-b23437e61a07/' (where the last part is the hash to the mercurial > version labelled as '2.0.17'). > > If someone know how to fix this.. The correct way to fix this is for upstream to provide a "sane" directory name. Using the vcs commit hash for the directory name on a release tarball introduces "uncertainty" and causes more work for downstream. Binary distributions that have developers manually download a tarball and creating a binary archive on their box and that redistribute that to their users are not too worried, but any source distribution that uses the upstream tarball and their "build recipe" to build a package, will need to update their "build recipe" (an ebuild in Gentoo) to update the change of the "moving directory name". So please, *pretty* please if you want to be a good upstream, provide stable URLs for releases and use as the directory name inside a tarball a good convention, such as ${PN}-${PV} with ${PN} being the package name and ${PV} being the package version. |