Thanks for your report. I actually ran into the same problem yesterday. It is a problem in HashStack and I have reported the problem here:
https://github.com/hashdist/hashstack/issues/594 Johannes On Tue, Dec 16, 2014 at 11:43 AM, obm <[email protected]> wrote: > Dear all, > This is a failure report using the hashdist method > In a HPC environment (linux, infiniband), the petsc compilation fails with > ******************************************************************************* > 2014/12/15 20:51:22 - INFO: [package:run_job] UNABLE to CONFIGURE > with GIVEN OPTIONS (see configure.log for details): > 2014/12/15 20:51:22 - INFO: [package:run_job] > ------------------------------------------------------------------------------- > 2014/12/15 20:51:22 - INFO: [package:run_job] Could not find a functional > BLAS. Run with --with-blas-lib=<lib> to indicate the library containing > BLAS. > 2014/12/15 20:51:22 - INFO: [package:run_job] Or --download-fblaslapack=1 > to have one automatically downloaded and installed > 2014/12/15 20:51:22 - INFO: [package:run_job] > ******************************************************************************* > > > 10 Ara 2014 tarihinde 18:50 saatinde, Anders Logg <[email protected]> şunları > yazdı: > > Yes, we likely need a couple of different variants. To begin with, I think > the main focus should be on the kitchen sink variant to get something that > is as close to foolproof as possible for users. > > Note that the current version does not (as promised) build from master. I > made a mistake in how hashdist decides which changesets to use from git. So > the dev version currently builds the stable predefined version. Fix in > progress.. > > -- > Anders > > > Wed Dec 10 2014 at 5:34:42 PM skrev Martin Sandve Alnæs > <[email protected]>: >> >> Hashdist is not like any package manager. It doesn't only build packages, >> but also manages entire stacks of packages with particular versions of each >> living side by side. This allows reproducible stacks if used right, as well >> as variations of stacks without rebuilding more than the stack diffs. When >> using anything outside of the hashdist stack, reproducibility may be lost. >> Pragmatic reasons compel the use of e.g. system compilers, and IMO using >> system python as well is best for most linux users. >> >> I think we need more than one install script. In particular, the kitchen >> sink variant which builds e.g. python and numpy etc, and minimal variants >> that use system installed python etc. I'd like a variant that doesn't >> install fenics so I can install master/next/wip branches myself in another >> directory. Of course this means maintenance of stack variants for different >> platforms, similar to the dorsal platform scripts. >> >> Martin >> >> 10. des. 2014 17:10 skrev "Garth N. Wells" <[email protected]>: >>> >>> >>> >>> On Wed, 10 Dec, 2014 at 11:13 AM, Anders Logg <[email protected]> wrote: >>>> >>>> ok, so is there a limited set of Python packages that we could agree on? >>>> >>>> I assume numpy is already included. What about matplotlib? >>> >>> >>> A package manager should only install dependencies; user should install >>> other packages independently, i.e. like Debian/Ubuntu 'recommended' and >>> 'suggested' packages. >>> >>> Garth >>> >>>> Wed Dec 10 2014 at 12:05:38 PM skrev Johannes Ring <[email protected]>: >>>>> >>>>> On Wed, Dec 10, 2014 at 11:40 AM, Anders Logg <[email protected]> wrote: >>>>> > Good points. >>>>> > >>>>> > iPython seems like a good thing to include. >>>>> > >>>>> > It would be good to make the system Python libraries visible (but >>>>> > after >>>>> > hashdist in the search path) but I don't know how to automatically >>>>> > extract >>>>> > the correct path to the system Python libraries. >>>>> > >>>>> > I think Johannes knows this better than I. >>>>> >>>>> If we want to use system Python modules, then I don't think we should >>>>> build our own Python. >>>>> >>>>> Johannes >>> >>> _______________________________________________ >>> fenics mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > > > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
