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