[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)


> - please add a "pristine-tar" branch, we rely on it in the Debian Science Team


> - 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:


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


> 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?



Reply to: