Hi François, On 26 March 2018 at 19:56, François Mazen <franc...@mzf.fr> wrote: > I've manually changed the timestamp of the changelog file from the > original repo, and I haven't check that the date was wrong. I can > update the changelog file.
I've seen new commits in the repo. Let's assume it's the latest version we would talk about. The following discussion will be based on https://github.com/moleculext/taptempo > The public key is published on the sks-keyservers network. Should I > sent it to debian keyring or other keyserver? I can retrieve the key now. > Should I submit a new revision of the package (1.2.1-2) or re-upload > with the current revision number (1.2.1-1)? Not necessary. Further changes are needed, I'll check the git repo directly since there is delay for mentor uploads. Here are a list of problems I have found: 0. This program seems to be a terminal bpm meter. I'm not quite good at music stuff, so I'd like to make sure: 0.1 For what purpose can this program be used? 0.2 Who's the targeted people of this program? 1. Upstream source should not contain a "debian" directory. However, you seem to be the upstream author, so you have two choices: (a) remove debian directory from source, and create another packaging repo where the debian directory is tracked. (b) change source/format to 3.0 (naitive). In this way you can keep the debian directory in upstream source. 2. The standards version is quite out of date. You could lookup the update checklist of Debian Policy[2], and update the standards version to the latest one (version 4.1.3). 3. Debhelper compatibility version is old. Version 11 is preferred. 4. control: the long discription is somewhat short. Could you please explain a bit more about the program's purpose and functionality? 5. changelog: It should close the ITP bug you've submitted. e.g. Close: #XXX 6. control: I'd recommend to add the Vcs-Git and Vcs-Browser field which point to the packaging repository. And add a homepage which points to the upstream homepage or simply the upstream repo. 7. Hardening flags[3] should be added to rules. i.e. export DEB_BUILD_MAINT_OPTIONS = hardening=+all 8. When you have built the latest version of the modified package, you could run lintian against it: lintian -EviI --pedantic xxxx.changes There generally shouldn't be any Error or Warning. 9. changelog: please keep the version number aligned with upstream version. or thing may get into a mess. I'll check the git repo again once you have updated it. If you have any questions about the above points, just feel free to ask [1] https://www.debian.org/doc/manuals/maint-guide/index.en.html [2] https://www.debian.org/doc/debian-policy/ [3] https://wiki.debian.org/Hardening -- Best,
