Re: updating mpi-defaults (decommissioning lam)
- To: firstname.lastname@example.org
- Cc: Manuel Prinz <email@example.com>
- Subject: Re: updating mpi-defaults (decommissioning lam)
- From: Drew Parsons <firstname.lastname@example.org>
- Date: Mon, 20 Jun 2011 12:18:56 +1000
- Message-id: <[🔎] 1308536336.21089.35.camel@pug>
- Reply-to: email@example.com
- In-reply-to: <20110519203134.GC9329@woodstock>
- References: <1302152322.5206.17.camel@pug> <20110407142531.GO6199@onerussian.com> <20110407181423.GA1845@xanadu.blop.info> <1302224087.7214.4.camel@pug> <20110409121240.GA6273@woodstock> <1302419585.4651.20.camel@pug> <1302452423.30269.90.camel@workhorse> <20110519203134.GC9329@woodstock>
On Thu, 2011-05-19 at 22:31 +0200, Manuel Prinz wrote:
> So these are basically two orthogonal changes, and the new mpi-defaults
> helps the LAM removal. I will upload a fixed mpi-defaults soon so that
> the LAM removal can take place ASAP.
Hi Manuel, thanks for uploading the new version of mpi-defaults to
I uploaded gerris 20110329-dfsg.2-2~experimental1 to experimental to
test the build. The results are odd, I really don't know how to
interpret them. The build log
says that the former failing lam architectures (armel, mips, s390,
sparc) are now building successfully. Hurrah, on the surface of it, that
looks like my mpi trouble is not fixed.
The problem is in the fine print: reading the build logs for those
arches, I find that they're actually still using lam anyway. Their
buildds have not yet picked up the new version of mpi-defaults (v1.0),
they're still using v0.6.
So two questions:
1) why is the experimental buildd not using the latest experimental
2) why is gerris all of a sudden building successfully against lam,
where previously it failed?
The code in gerris is the same (20110329-dfsg.2), and the lam version
has also not changed, 7.1.2-2.
I'll ask the buildd admins to trigger another build attempt of gerris in