Re: [RFS] mseed2sac and sac2mseed: seismic data conversion tools
Hello Sébastien,
Thanks for your careful review.
On 2018-01-23 16:47, Sébastien Villemot wrote:
> I just looked at mseed2sac, but maybe the remarks below also apply to
> sac2mseed:
Indeed most of them did apply also to sac2mseed.
> - the Vcs-Git and Vcs-Browser fields in debian/control should point to the
> Debian packaging (on salsa.debian.org), not to the upstream sources
Fixed, but of course at some point I would prefer to host the
repositories in the science-team group.
> - it looks like you repackaged the original tarball by removing the libmseed/
> directory. This should be made clear in the Debian version by adding a suffix
> (typically "+ds", for "Debian source", so that the Debian version will be
> "2.2+ds-1").
Done, I'm using 2.2+ds1-1, so I have a version number to bump if I have
to modify the Debian source branch.
> Then you also want to update debian/watch to take into account the +ds
> suffix (with the "dversionmangle" option), and also debian/copyright (by
> using the Files-Excluded field) to make repacking easy (see the manpage for
> "uscan" for both points)
Done.
> - please add a "pristine-tar" branch, we rely on it in the Debian Science Team
Done.
> - please also use standard git-buildpackage branch names, i.e. "upstream" for
> upstream sources and "master" for Debian packaging (this naming scheme is
> expected in the Debian Science Team).
Well, I chose this naming scheme (branch "master" tracks upstream,
branch "debian/sid" contains the Debian packaging) because it was what
the gbp documentation suggested, see:
/usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html
Are you asking me to change the names of the branches just to keep the
structure of the debian-science packages uniform, or is there another
reason I'm missing? I'm asking just to understand: I have no problem in
changing the names, but on the other side I'd like to stick with a
somehow uniform workflow for my Debian packages. Is there a general best
practice to follow when using git and upstream tagged releases?
> - why do you add -O3 in debian/rules? Unless you have a good reason (like it
> avoids a build failure), you are expected to use standard Debian build flags
Done.
> Otherwise your packaging looks good (though I can't promise that there are no
> other issues that may be discovered in a second round of review).
Thanks. In debian-science do you rely on mentors for reviewing, or do
you review directly from the git repository?
Cheers,
Paride
Reply to: