Hello. Here are some comments about the current packaging. Hope this helps…
As upstream contributor, you should merge your changes into the original project at https://github.com/mevdschee. Your fork misses README.md, latest bug fixes, and the original project would probably welcome a manpage and improvements in the Makefile. The attachment fixes cosmetic issues in the manpage (https://liw.fi/manpages/), and contains many suggestions for the Makefile: * allow prefix /= /usr * avoid as many repetitions as possible, so that any renaming or version change is easyer (I suggest a name starting with a letter for the package and executable) * reduce the subshell runs, declare .PHONY targets, use := variables (for performance) Once an upstream tarball is released * without any debian/ subdirectory (there may be other distributors) * without .gitignore (the tarball is unrelated with the VCS) * with explicit authors and license * maybe with a short ./changelog file, either referencing the version control system or manually listing changes. * visible somewhere on the web (for automatic detection of new versions) * maybe signed by your electronic signature you can start the Debian packaging. debian/2048.debhelper.log debian/2048.substvars debian/files show that you have committed without cleaning your working directory. debian/changelog should only contain the history of the official Debian packages (currently, only one). In other words, it only sees the debian/subdirectory. In normal circumstances, changes to the upstream sources should be mentioned in ./changelog (or the VCS it refers to). Text files should end with an empty line (it helps diff tools). Your package is ready for debhelper 10 and Standards-Version 4.1.0. control/Vcs-* and copyright/Source changes should be self-explaining. I hate trailing whitespaces, but YMMV. Once upstream releases visible tarballs, adding a watch file scanning new upstream releases and checking signatures would be a good thing. See uscan(1).
