On Mon, 10 Jun 2019, Balay, Satish via petsc-dev wrote:
> For now - I'll try out a simpler model [i.e manually rebuild as needed]
I've rebuilt the packages [keeping the old ones for maint tests]. And updated
master to reflect this.
Satish
Sure, but we could have our own petsc-centric tests triggered by gitlab CI
also
> On Jun 10, 2019, at 4:51 PM, Balay, Satish wrote:
>
> On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
>
>>
>>
>>> On Jun 10, 2019, at 4:33 PM, Balay, Satish wrote:
>>>
>>> now configure needs t
On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
>
>
> > On Jun 10, 2019, at 4:33 PM, Balay, Satish wrote:
> >
> > now configure needs to know and support full spack build and query all the
> > dependency info from spack..
>
> We could have some test cases where PETSc is also buil
> On Jun 10, 2019, at 4:33 PM, Balay, Satish wrote:
>
> now configure needs to know and support full spack build and query all the
> dependency info from spack..
We could have some test cases where PETSc is also built by spack, which
presumably works and would also test petsc-spack
>
>
> On Jun 10, 2019, at 4:31 PM, Balay, Satish wrote:
>
> Well its a complex automation problem..
>
> For one - all dependencies would have to be rebuilt - and then manage
> the new/old locations of the packages. i.e its running 2 or more
> builds in 1. [with a different prefix in each build]
"Smith, Barry F." writes:
> That seems ok. We could also overload --download-mpich=spack for anal
> people like me :-)
>
> Somehow we also need to let configure know where the spack configuration
> is.
Right, --with-spack=/path/to/spack/bin/spack or use spack from PATH if it's
there.
Well its a complex automation problem..
For one - all dependencies would have to be rebuilt - and then manage
the new/old locations of the packages. i.e its running 2 or more
builds in 1. [with a different prefix in each build]
Satish
On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
>
now configure needs to know and support full spack build and query all the
dependency info from spack..
For now - I'll try out a simpler model [i.e manually rebuild as needed]
Satish
On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
> That seems ok. We could also overload --download-
That seems ok. We could also overload --download-mpich=spack for anal people
like me :-)
Somehow we also need to let configure know where the spack configuration is.
> On Jun 10, 2019, at 4:21 PM, Jed Brown wrote:
>
> "Smith, Barry F." writes:
>
>> Yes, spack could be used to do this. I
"Smith, Barry F." writes:
> Yes, spack could be used to do this. I guess essentially Buildsystem would
> issues commands to spack on each "prebuilt" package each time it runs in test
> mode (using the URL in the package file?) and after the first time spack
> would ignore the commands since
Yes, spack could be used to do this. I guess essentially Buildsystem would
issues commands to spack on each "prebuilt" package each time it runs in test
mode (using the URL in the package file?) and after the first time spack would
ignore the commands since it already had the version ready.
"Smith, Barry F. via petsc-dev" writes:
> Yes. If the testing system were smart enough we could have the tests
> actually update the "prebuilt" automatically when things change. This would
> be more scalable in human efficiency. In addition when setting up a new test
> machine no need to man
Yes. If the testing system were smart enough we could have the tests actually
update the "prebuilt" automatically when things change. This would be more
scalable in human efficiency. In addition when setting up a new test machine no
need to manually make the prebuilts, the testing will just
Ok - this must be the result of having prebuilt external packages used
for jenkins - for both maint/master [while master changes with updates
to use newer versions]
I think I might have to split maint/master part of prebuild external
packages - and upgrade the master version [as master gets update
I've noticed this issue with Jenkins tests recently but don't see it in next
nightly builds
https://petsc-dev.org/jenkins/blue/organizations/jenkins/pj02%2Farch-jenkins-linux-gcc-pkgs-opt/detail/PR-1773/1/tests
perhaps related to last MUMPS release? One number seems oddly large
ICNTL(38) (esti
15 matches
Mail list logo
