Re: Bug#849427: ITP: mpgrafic -- MPI version of N-body initial conditions grafic package
Hi Boud,
On 06.01.2017 02:15, Boud Roukema wrote:
> I think I've tidied up for most of the points you made regarding
> mpgrafic, and I've pushed to alioth git. I'm aware that I'm long past
> the Debian Stretch freeze deadline - what's important is that mpgrafic
> is on its way to getting into the debian pipeline, and that I can
> become familiar enough with the process in order to handle some
> other cosmo packages later. :)
Yea, great. And it will also make its way into the next Ubuntu releases.
And you may backport it to Stretch.
However, in the moment, ftp-masters will probably not (or only very
slowly) process the NEW queue for packages that are not going into
Stretch, so it will take quite a while.
> Here are some questions/comments which you or someone else
> here might help me on, for which RTFMing and duckduckgoing haven't
> (yet) given me answers.
>
> * In my local copy of the alioth repository for mpgrafic, I have
> master, upstream and pristine-tar branches. Independently, in the
> upstream (bitbucket) repository, there is also a branch that is called
> "master", but from my local (and the alioth) repository(ies) point of
> view, it should be called "upstream". Can I set up config parameters
> with ordinary git commands so that "git pull" or "git pull bitbucket"
> will update my local branch called "upstream" from the bitbucket
> branch called "master"? My worry is that the bitbucket "master" branch
> will be fetched/merged into my local "master" branch. (I don't yet
> want to try the git-* frontends to debian packaging tools, because I
> prefer to first get some idea of how these work at the lower level.)
Hmm. No idea. I never used the upstream repo directly, but rely on the
tarball they produce and create a completely independent repository.
Please ask on the debian-mentors list. There should be people more
experienced than me ;-)
> * What version-tagging policy makes sense on the alioth
> git repository?
Please tag the upstream branch with
upstream/<version>
and the debian branch with
debian/<version>-<debian-revision>
You don't need to tag pristine-tar.
> * The following warnings when doing pdebuild seem to me minor
> issues. For example, linking with -lgsl normally requires
> that -lgslcblas be given too, so finding a way to modify the
> debian build sequence to avoid linking to gslcblas (i) might
> be a messy hack and (ii) would, it seems to me, cause a fatal
> error when compiling. Of course, minimising dependencies is
> a critical element in allowing scalability and upgradability
> of the whole distribution, so if someone thinks that these
> are worth working on, maybe they could at least go in something
> like a debian/TODO file...
I would not care too much about this. However, in Debian libgsl should
already resolve its own dependencies, so linking to gslcblas is not
needed (unless there is something specific). Since gslcblas is anyway an
(indirect) dependency, I would just keep it as it is. And, gslcblas is
in the same package as libgsl, so in fact there is no additional
dependency. And these warning are (from my experience) sometimes wrong.
> * I didn't find a way on bitbucket to sign the tarballs - these
> seem to be created automatically for every commit that has a tag:
>
> lintian -I -E --pedantic ../mpgrafic_0.3.4-1_source.changes
>
> P: mpgrafic source: debian-watch-may-check-gpg-signature
Please also ask that on debian-mentors; I have no glue. Using signed
tarballs is also just a wish, not a requirement. This would not delay
upload.
>From my point of view, the package looks ready to upload. What you
however still should do is to commit the .orig.tar.gz file to
pristine-tar under its Debian name (mpgrafic_0.3.4.orig.tar.gz). The
original name is irrelevant here.
If you give me a "go", I will upload.
Cheers
Ole
Reply to: