The most recent upload to the mentors page (2026-09-05 01:08 UTC, currently labeled as upload #2) added issues the earlier upload (2026-09-04 05:08 UTC, currenly labeled as #1) did not have.
- Because `palmer-mail` is unknown to Debian (by the query https://tracker.debian.org/search?package_name=palmer-mail), the introduction requires d/control to link to the ITP bug (one type of the WNPP bug tickets) - as in upload by September 4. - Check why `VCS field` (about the repository to package) is dysfunctional in uploads to the mentors page. Unable to tell if there might be an issue with / a gap of support for codeberg, one could try salsa (as a good number of packages use). A repository to package to Debian typically is not the upstream repository (where the program is developed). Because down the road, maybe once you need patches to the commit history specific to packaging to Debian, but irrelevant to Fedora. Their rules and best practices may differ from the ones here in Debian; i.e. to ease house keeping. - Version numbering on `-1` (in `1.4.0-1`) and `-2` (in `1.4.0-2`). The counter about the upload to the mentors page (`Upload #1`, `Upload #2`, etc) is not the `-debian-revision` (see section 5.6.12 Debian policy). To introduce upstream version `1.4.0` to Debian, this field should be `1.4.0-1` - regardless of the number of iterations necessary to satisfy checks on the mentors page, either automatic or by a human reviewer / potential sponsor for an upload. A `1.4.0-2` can become useful later (the source-only upload). - Current `d/changelog` (`90b6cbeda7` on codeberg) reads more about improving the program (what I expect to happen in an upstream repository) than about packaging only. Compare with already admitted packages, for instance https://salsa.debian.org/debichem-team/jmol/ The presence of multiple version entries in `d/changelog` (about packaging) however contradicts with the presence of only one commit to the repository to package. In the salsa repository about packaging Jmol, code -> tags for instance allows to travel in time to specific commits tagged, code -> branches to access the three mandatory branches `pristine-tar`, an upstream and a default branch. The codeberg repository might serve well enough as an upstream reference, because of the missing branches it however is not fit for packaging. As above, to prepare the package is easier to manage if it is in a repository separate from the one about the upstream reference. - In current `d/control` (`90b6cbeda7`), there is a great number of comments. That's unusual, unwanted clutter. Some dependencies explicitly define a minimal version (an advantage), though the pattern is not consistently applied. - `d/watch` still is `version=4` instead of current `Version: 5`. - `pyproject.toml` (still) includes a great number of comments. Some don't belong here (e.g., the groff command `.TH` for a man page), or are not needed (e.g., definition of the version tuple, notes on Ubuntu). This pattern is similar to the one of source code written by some LLMs yet without subsequent manual lint. - Personally, I no longer retain a `requirements.txt` while organizing Python dependencies within `pyproject.toml`. Regarding `pytest`: for more important scripts, I tend to specify its usage in further detail, for instance ```pyproject.toml [tool.pytest] pythonpath = ["src"] testpaths = ["tests"] filterwarnings = ["ignore::pytest.PytestCacheWarning"] markers = [ "blackbox: test series from the outside", "imported: a test which imports a function of the script", ] minversion = "9" log_level = "INFO" strict = true addopts = ["-ra"] ``` Regards, Norwid
