Bug 524511
| Summary: | ORTE_ERROR_LOG: Not found while running freefem++-3.5 testsuite | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominik 'Rathann' Mierzejewski <dominik> | ||||||||||
| Component: | openmpi | Assignee: | Jay Fenlason <fenlason> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 13 | CC: | dledford, fenlason, jfeeney, jonathan.underwood | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2011-06-27 14:24:12 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Dominik 'Rathann' Mierzejewski
2009-09-21 00:18:20 UTC
Created attachment 361849 [details]
log from a failed x86_64 build
I get an error when I attempt to access the link in the attachment. Can you attach the actual log instead of just a link to it? I wasn't able to get freefem++ to build locally on my rawhide box until I enclosed the %build section in "exec bash << EOF" and "EOF" lines. Apparently the /etc/profile.d/modules.sh script contains some bash-isms that don't work when run by /bin/sh. That might be a bug in the environment-modules package. However, once I edited the spec file, freefem++-3.5-2 compiled against openmpi-1.3.3-6.fc12 without problem. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping New builds are failing in exact the same way on koji/dist-f13. See for yourself: koji build --scratch --arch=x86_64 dist-f13 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/freefem++/devel#HEAD' It works fine in mock. Created attachment 376386 [details] build log from a failed x86_64 build Build log from: http://koji.fedoraproject.org/koji/taskinfo?taskID=1851955 Created attachment 376391 [details]
log from a failed local mock build (rawhide/x86_64)
I was wrong, local mock rawhide build fails, too.
ping? still fails with current rawhide (in mock) I'm not sure that this can reasonably be expected to work. The error is a failure to run the openmpi runtime during the build process. While it is expected that you can build an openmpi using app in a build root, there is no guarantee that you can run the same app in the build root. It may have worked in the past, and they may have been pure coincidence that the defaults for a totally unconfigured openmpi install allow you to run a single process mpi job. We can look into it, but I make no promises that running an mpi job in a build root will be officially supported. Is it possible to configure the openmpi environment in an automated way as part of the build process then? I don't mind adding a few lines of shell script before running the testsuite in %check. This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I don't believe you can run openmpi programs on the builders, because you can't make any assumptions about the network configurations on the build machines. (Or even that they have networking at all.) This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. I realize this bug is closed, but I just hit this problem myself while building some packages for internal consumption and found a workaround. The issue is described more clearly here: http://permalink.gmane.org/gmane.comp.clustering.open-mpi.user/966 And the workaround I used was to simply add BuildRequires: rsh to my spec file. An alternative would be touch /usr/bin/rsh I suppose. I do wonder if openmpi-devel should Require the rsh package such that (single host) opnmpi can be ran during %build/%check. Anyway, posting this here in case someone else runs into the problem in the future. |