Nicolas, I believe a bunch of these were answered by Jeroen, but I will answer them as well in care you still have any questions.
On Wednesday, October 9, 2024 12:27:46 AM MST Nicolas Schodet wrote:
> * Soren Stoutner <so...@debian.org> [2024-10-08 19:00]:
> > It’s fine to send me a direct email as we have worked together in the past.
> > What are your questions regarding the packaging?
>
> I have written them down in the RFS (#1084800):
>
> The package is a reintroduction, nxt-python was removed in 2020.
>
> About bugs #885467, #937175 and #773201: they were closed when the
> package was removed, should I re-open them before the upload, or is it
> handled at upload time?
You should reopen them after the upload, but only if you think they still
apply. For example, #937175 won’t apply, because anything you build in
unstable right now has to work with Python 3.
> About lintian report, I would like to have some advice on how to handle
> it rather than going directly with an override:
>
> I: nxt-python source: built-using-field-on-arch-all-package (in section for
> python3-nxt) Built-Using ${sphinxdoc:Built-Using}, [debian/control:34]
>
> I think this is a bug in lintian as this is required by sphinx, see
> https://bugs.debian.org/999785
Just override the tag with a comment explaining why it doesn’t apply. Note
that I haven’t spent the time to ascertain that you are correct about it not
applying, but I trust your knowledge of the situation.
> P: python3-nxt: image-file-has-unexpected-name (is PNG)
> [usr/share/doc/python3-nxt/html/_static/favicon.ico]
>
> Having a PNG inside a .ico is actually typical. Also see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717818#17
>
> > I did not implement .ICO because it is, or has evolved into, a
> > container format that can also contain PNG images.
>
> P: nxt-python source: maintainer-manual-page [debian/man/nxt_push.1]
> P: nxt-python source: maintainer-manual-page [debian/man/nxt_server.1]
> P: nxt-python source: maintainer-manual-page [debian/man/nxt_test.1]
>
> I am also the upstream maintainer, I plan to add them to
> upstream package in the future. Maybe I should add an override
> for this one.
>
> X: python3-nxt: application-in-library-section python [usr/bin/nxt_push]
> X: python3-nxt: application-in-library-section python [usr/bin/nxt_server]
> X: python3-nxt: application-in-library-section python [usr/bin/nxt_test]
> X: python3-nxt: library-package-name-for-application [usr/bin/nxt_push]
> X: python3-nxt: library-package-name-for-application [usr/bin/nxt_server]
> X: python3-nxt: library-package-name-for-application [usr/bin/nxt_test]
>
> Not sure how to handle this one, is it acceptable to have some
> script shipped inside the python module package? Should I make a
> separated -utils package or an override.
>
> nxt_push could be useful without nxt-python, but there are other
> software doing the same thing already in other packages.
>
> nxt_server is only useful with nxt-python, so it falls as an
> helper.
>
> nxt_test primary objective is to test connectivity with
> nxt-python, so this is also a helper.
>
> So… I think I should do an override.
>
> X: nxt-python source: debian-watch-does-not-check-openpgp-signature
> [debian/watch]
>
> This is related to PyPI not encouraging PGP signature. Should I,
> as the upstream author, make releases outside of PyPI?
>
> X: nxt-python source: very-long-line-length-in-source-file 3559 > 512
> [setup.py:20]
>
> This is from generated upstream package, quoting the README
> inside the setup.py.
Don’t even worry about overriding pedantic or experimental lintian tags. Just
ignore them if they are incorrect or not helpful.
From the manpage:
"Pedantic tags are Lintian at its most pickiest and include checks for
particular Debian packaging styles and checks that many people disagree with.
Expect false positives and Lintian tags that you don't consider useful if you
use this option. Adding overrides for pedantic tags is probably not worth the
effort.”
"If a tag is marked experimental, this means that the code that generates this
message is not as well tested as the rest of Lintian, and might still give
surprising results. Feel free to ignore Experimental messages that do not seem
to make sense, though of course bug reports are always welcome (particularly
if they include fixes).”
https://manpages.debian.org/stretch/lintian/lintian.1.en.html
--
Soren Stoutner
so...@debian.org
signature.asc
Description: This is a digitally signed message part.
