[petsc-dev] moab nightlybuild failure

Satish Balay balay at mcs.anl.gov
Thu Jun 27 20:36:31 CDT 2013

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',

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:

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..]


More information about the petsc-dev mailing list