[petsc-dev] moab nightlybuild failure

[Timothy J. Tautges]

I've been mulling whether by default petsc should point to a release tarball anyway, I think it should (4.6 being the latest).

Any time you grab directly from git you can expect to have to run autoreconf, since by policy we don't store configure file in the report.


- tim 

(Sent from an Androd that dosnt autocorect as wel as an ipone) 

-------- Original message --------
Subject: Re: [petsc-dev] moab nightlybuild failure 
From: Satish Balay <balay at mcs.anl.gov> 
To: Jed Brown <jedbrown at mcs.anl.gov> 
CC: petsc-dev at mcs.anl.gov,tautges at mcs.anl.gov 

On Thu, 27 Jun 2013, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > Ok - fixed in 'balay/fix-moab-git'. Any comments?
> >
> > https://bitbucket.org/petsc/petsc/commits/1f16e75d68ca70d003ea3ef4dde0f67dcfe822d6
> 
> Looks okay.  What is the recommended way to _not_ try to use the Git
> version?  Pass the URL directly?

The current code is a bit of mess.

For one - I don't know why the GNUPackage requires URLs to be split up as such:
>>>>>
    self.downloadpath      = 'http://ftp.mcs.anl.gov/pub/fathom/'
    self.downloadname      = 'moab'
    self.downloadfilename  = 'moab'
    self.downloadversion   = 'nightly'
    self.downloadext       = 'tar.gz'
<<<<

But ignoring this we currently have stuff like the following - where
the urls are attempted in the sequence specified. If the first one
fails - try the next one:

>>>>>
    self.download   = ['https://elemental.googlecode.com/files/elemental-0.79-p1.tgz',
                       'http://ftp.mcs.anl.gov/pub/petsc/externalpackages/elemental-0.79-p1.tgz']
<<<<<<

with [potential support] for multiple protocols. - as retrieval.py lists:
[we also support urls of type file://path]

>>>
# Fix parsing for nonstandard schemes
urlparse.uses_netloc.extend(['bk', 'ssh', 'svn'])
<<<<

And currently this default can be overwriten by user with:
--download-package=url

In this context we should not have a separate stuff for git
[self.giturls/self.gitcommit]. It should be rolled into the above
common url notation.

[note: the current git code ignores user specified
--download-package=url - and just goes ahead and does the git stuff
specified in package.py]

Somehow we have to add in 'prereqisites' to the 'repo' type urls in
the above scheme.

And then perhaps retrieval.py can be asked to ignore repo-urls with
some option like '--url-git=no'

Also - the repo urls need better support wrt: 'getting updates &
rebuilding package'.  Current code for this is tarball centric [with
some bad behavior - like not detecting a changed url etc..]

Satish

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130627/74eb0ef7/attachment-0001.html>