On Sat, 2016-04-23 at 21:26 +0000, Mattia Rizzolo wrote: > On Sat, Apr 23, 2016 at 02:37:19PM +0800, Drew Parsons wrote: > > > > It'd suit me well to host it on git. I'm familiar with git but > > have to > > track down the right svn commands each time, which slows down > > maintenance. > hoping this improve the quality of the packages (as at least dolfin > and > fenics (this one only because it's a rdep of dolfin) are on our black > list of packages causing troubles to use trying to remove > libpng12/vtk5/itk3/... from the archive), I've done it. > > https://anonscm.debian.org/git/debian-science/packages/fenics > > These are ok: > dolfin > ffc > fiat > instant > ufl
Thanks Mattia, the repos look good. The fenics "package" is a dummy package pulling the suite in. It might be more efficient to create it as a dummy package in dolfin rather than keeping a separate repo for it. It's a question of taste I guess. > ferari ... > syfi > ufc > viper These (and uflacs) are deprecated. Actually I don't know what syfi is, it's not a current FENiCS package upstream. Precursor to ufc maybe, which was a precursor to ffc. Likewise viper isn't FENiCS upstream now. I'm in favour of leaving them in svn so they don't get us confused. > These instead had directories on the svn repo, and there is some > basic > packaging, but they are not uploaded, and as so, I couldn't import > the > upstream tarball. > mshr Yeah, we should get mshr operational. > > also consider that due to the way svn-buildpackage works, the debian > tags are not in the master branch, but if you have some of what I > personally call basic knowledge of git it won't be a issue :) > > Now, for all of those packages, it wouldn't seriously harm doing an > uploads cleaning them up a bit and whatnot (several of them are out > of > testing due to RC bugs, etc...), and changing Vcs-Git. I can clean up the current core packages (apart from mshr). The deprecated ones can bitrot :) I want to set the petsc-dev dependency in dolfin to petsc3.6-dev. python-dolfin calls on petsc-dev at execution (the dolfin scripts are like "just-in-time" interpreted scripts), so I think the petsc invoked at runtime should be consistent with the one that libdolfin1.6 is compiled against (currently petsc3.6). i.e. I think we want ABI consistency. Otherwise we could be in a position where petsc3.8 is pulled in at runtime while libdolfin1.6 still uses petsc3.6. Drew
