{vis} [intel-2015b] Mesa 11.0.2 (REVIEW)#2038
Conversation
|
Easyconfigs unit test suite FAILed. See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/4670/console for more details. Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do. |
|
Easyconfigs unit test suite FAILed. See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/4691/console for more details. Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do. |
|
@boegel I am sorry, its getting to be fat. |
|
@hajgato: well, you did a really nice job on building up towards this with a whole series of other PRs, so let's roll with it |
There was a problem hiding this comment.
@hajgato: M4 here too in Mesa-10.5.5-intel-2015a-Python-2.7.10.eb, so add it here too?
There was a problem hiding this comment.
@boegel it is a bug or a feature. When I put M4-intel-2015b, then eb said that this conficts with M4-GNU-4.9.3-2.25. And it is a builddep in Autotools. I have checked the path in the eb log, and the path for M4-GNU-4.9.3-2.25 was clearly there. software/M4/1.4.17-GNU-4.9.3-2.25/bin I can put it back, but then it must be the GNU-4.9.3-2.25 version
There was a problem hiding this comment.
eb produces the conflict, or the tests report a conflict?
There was a problem hiding this comment.
eb produced the conflict.
There was a problem hiding this comment.
@boegel anyway, its easy to check, M4-intel-2015b in this PR.
There was a problem hiding this comment.
That means the conflict is caused by one of the other build dependencies, which has M4 as a (runtime) dep?
There was a problem hiding this comment.
@boegel Ok, I figured out Autotools have libtool dep, and libtool have a M4 runtime dep. So whats now? What M4 builddep should I add to Mesa?
https://gist.github.com/hajgato/750e9cd5dbb23a1b0010
There was a problem hiding this comment.
OK, so Autotools load libtool, which has M4 as a runtime dep, that's where the conflict comes.
But, that also means there's no need to include it as a direct dep here, since M4 will be loaded as a build dep when building Mesa.
There was a problem hiding this comment.
testing it as we speak, should be good to go I think
|
Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/4694/console for more details). This pull request is now ready for review/testing. Please try and find someone who can tackle this; contact @boegel if you're not sure what to do. |
There was a problem hiding this comment.
same here, we already have libXext-1.3.3-intel-2015a-Python-2.7.10.eb, so keep the versionsuffix?
|
Test report by @boegel |
|
Test report by @boegel |
|
@hajgato: it works, just some minor style remarks mostly w.r.t. versionsuffixes; since we already have easyconfigs for those software versions, let's stick to the versionsuffix we're using there? |
|
@boegel I delibearately deleted the |
|
@hajgato: well, the real solution for this issue lies elsewhere anyway, I'm just trying to keep things somewhat consistent, but it's a battle we can't win anyway; so, leave it as is |
|
@boegel I am open to everything, so if you say we should put the versionsuffix because it was there before, it is fine for me. |
|
@hajgato: what we really want as a solution to this is support for version ranges ( |
|
Test report by @boegel |
|
Test report by @boegel |
|
Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/4703/console for more details). This pull request is now ready for review/testing. Please try and find someone who can tackle this; contact @boegel if you're not sure what to do. |
Needs PR
#2030#2031