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,

Reply via email to