On Friday, October 3, 2025 2:37:18 PM Mountain Standard Time Seyed Mohamad
Amin Modaresi wrote:
> Thank you.
>
> I fixed it with the 11th upload.
Thanks. vkbasalt-cli is getting close to where we can upload it. Before it
can be sponsored the following items need to be addressed.
1. You need to write a man page for vkbasalt-cli as described in the
following lintian warning:
W: vkbasalt-cli: no-manual-page [usr/bin/vkbasalt]
N:
N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should have
a manual page
N:
N: Note that though the man program has the capability to check for several
program names in the NAMES section, each of these programs should have its own
manual page (a symbolic link to the appropriate manual page is sufficient)
because other manual
N: page viewers such as xman or tkman don't support this.
N:
N: If the name of the manual page differs from the binary by case, man may
be able to find it anyway; however, it is still best practice to match the
exact capitalization of the executable in the manual page.
N:
N: If the manual pages are provided by another package on which this package
depends, Lintian may not be able to determine that manual pages are available.
In this case, after confirming that all binaries do have manual pages after
this package and its
N: dependencies are installed, please add a Lintian override.
N:
N: Please refer to Manual pages (Section 12.1) in the Debian Policy Manual
for details.
N:
N: Visibility: warning
N: Show-Always: no
N: Check: documentation/manual
N: Renamed from: binary-without-manpage
If you have never written a manpage before, you might find help2man useful (it
converts the help output of the cli to a man page, which you can then modify
into a final form). For an example of a man page written from scratch, see:
https://salsa.debian.org/soren/privacybrowser/-/blob/master/src/
privacybrowser.1?ref_type=heads
2. You are currently using the SPDX standard naming format for the licenses
in debian/copyright. However, Debian has its own standard abbreviations for
common licenses.
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
In the case of this package:
GPL-3-only -> GPL-3
LGPL-3.0-only -> LGPL-3
3. We need to clarify which is the general license under which the majority
of the files are released (those that do not contain an explicit license
statement).
Currently, you have the "Files: *" stanza in debian/copyright licensed under
the GPL-3. However, there is no document in the upstream information that
actually says that, and there is one document in the upstream information that
says it is the LGPL-3.
Analysis:
COPYING
Code in vkbasalt/lib.py (library) is licensed under lgpl-3.0-only (see
COPYING.LGPLv3)
Code in vkbasalt/cli.py (main program) is licensed under gpl-3.0-only (see
COPYING.GPLv3)
This makes clear the licensing of these two files (which is also clear in
their headers). It doesn’t mention anything about the licensing of any of the
other files in the tarball.
io.gitlab.theevilskeleton.vkbasalt.metainfo.xml
<project_license>GPL-3.0-only AND LGPL-3.0-only</project_license>
This again makes clear that both of these licenses are used, but it doesn’t
make clear which license applies to files without explicit licensing.
setup.py
license=’LGPLv3’
This file says the license is the LGPLv3. With the lack of any other
documentation, this is the clearest indication that files without an express
license header are LGPL-3.
This is all vague enough that I would recommend contacting upstream for
clarification. If upstream does not respond, I would recommend making "Files:
*” LGPL-3. If upstream does respond, I would recommend asking them to clarify
their intention in the upstream documentation so that it is clear in future
releases.
The following additional items do not need to be addressed before I sponsor
the package. Rather, they are items of which you might not be aware and
information that may be helpful to you as the package maintainer. You can
choose to follow any of these recommendations or ignore them as makes the most
sense to you.
1. It does not appear that debian/.gitignore is doing anything useful. You
can probably just delete it.
2. You might consider packaging this under the Debian Games Team, similar to
the vkbasalt package.
https://tracker.debian.org/pkg/vkbasalt
3. If you decide not to package it under the Debian Games Team, you might
consider moving the repository from your personal workspace to the Debian
workspace on Salsa (the URL would become https://salsa.debian.org/debian/
vkbasalt-cli). This indicates that other Debian Developers are welcome to
commit directly to the repository. If you would prefer not to allow that, you
can leave it in the current location, where other Debian Developers would need
to submit an MR or a patch if they want to collaborate with you. In my
personal case, I have all of my packages except for one in either the Debian
workspace or a team workspace. That one package I am very particular about
not wanting other people making changes without my prior review (because I am
the upstream developer of that package). If you do decide you would like to
move your package to the Debian workspace, you can grant me the Owner level
permission of the repository and I can do it for you.
4. debian/copyright currently lists the full text of each license in the
Files stanzas. This is acceptable and one way to comply with the debian/
copyright syntax. However, I have personally found that it is easier to read
debian/copyright files if the text of all of the licenses is moved to the
bottom of the file. I usually list the “Files: *” stanza, then the “Files:
debian/*” stanza, and then all of the upstream exceptions in alphabetical
order. Here is an example of a particularly complicated debian/copyright that
demonstrates why I find this easier to read:
https://salsa.debian.org/debian/courier/-/blob/master/debian/copyright?
ref_type=heads
5. You are free to license debian/* under any license you like (as long as it
is compatible with the upstream license). Typically, the recommendation is to
use the same license as upstream, as that makes it easier to submit patches
upstream if needed. In the case of an upstream like this with three licenses,
I personally would license debian/* as:
GPL-3 or LGPL-3 or CC-BY-SA-4.0
6. debian/rules currently contais:
dh $@ --with python3 --buildsystem=pybuild
This works, but is an older syntax. You can now switch this to be:
dh $@ --buildsystem=pybuild
And change dh-python to dh-sequence-python and remove python3 under Build-
Depends in debian/control:
Build-Depends: debhelper-compat (= 13),
*dh-sequence-python3,*
python3-setuptools
In general, any time you previously would have used "--with foo” in debian/
rules, you can replace it with dh-sequence-foo in debian/control.
7. Your salsa-ci.yml uses the older recommended default contents. The newer
recommended default currently does the same thing, although at some point in
the future it might diverge.
https://salsa.debian.org/salsa-ci-team/pipeline#salsa-continuous-integration-ci--quality-assurance-for-debian-packaging
--
Soren Stoutner
soren@debian.orgAttachment:
signature.asc
Description: This is a digitally signed message part.