Hi Nilesh, On Sat, 2023-11-11 at 09:44 +0530, Nilesh Patra wrote: > On 11 November 2023 8:31:25 am IST, Maytham Alsudany > <maytha8the...@gmail.com> wrote: > > On Sat, 2023-11-11 at 02:31 +0530, Nilesh Patra wrote: > > > My personal experience is that maintainer maintained manpages are > > > seldom well-maintained and tend to get outdated with new versions > > > if the maintainer forgets to update these regularly. > > > Also, that manpages keep introducing new lintian warnings with new > > > version of troff/groff. > > > > > > Since this package already requires some maintenance, I feel it would be > > > an additional burden on me and you. It is IMHO the best case scenario if > > > the upstream maintains a manpage themselves. > > > > Opened an issue upstream[1]. > > Since they said PRs are welcome, maybe we could send them a manpage and a > script to recreate it everytime. > I think createmanpages script could be handy > > <https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages>
Upstream uses sphinx to generate both the HTML docs and the manpages, so perhaps we should update sphinx's man_pages[4] option in docs/conf.py[5] in a PR and/or patch, adding a kitten manpage that points to an existing/new RST file. > > Regarding the inconsistent shebangs in the Python files, I've opened an > > issue upstream regarding that[3]. > > Yep, and it seems to have been changed to "usr/bin/env python" instead in the > fixing commit :-/ > > Seems like we will have to keep the `sed` call for a while. With the experience you have packaging software written in Python, is it standard to use "python" or "python3" in shebangs? The fixing commit references PEP 394[6], which allows either shebang. > > Regarding splitting up the kitty and kitten components, I've opened an > > issue upstream[2], but the upstream author promptly closed it, stating > > Something similar happened with me when I forwarded > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054633> > > Upstream which I can reproduce and it was closed very quickly. > > My impression is that the upstream is somewhat tricky to deal with - but I > guess with time, we will manage somehow. I guess we'll have to stick to patching bugs ourselves. > > that "the Go code depends on the rest of the code so splitting it is > > not going to happen." > > I've added a comment there. Let's see if they consider to do something about > it. I'm assuming you've seen upstream's reply. > > > Would you like me to bump the version of the package to 0.31.0 now that > > 0.30.1 has been uploaded to experimental? > > Sure, if you have the time! :) Hopefully we can get kitty to be stable enough to move into unstable, I'm excited to see it propagate into testing! Regarding lintian's errors, would you like me to add descriptions to your patches (by that, I mean copy-paste your commit messages)? Additionally, I keep forgetting to mention that lintian.debian.org seems to not work, so I've had to resort to `lintian-explain-tags`. I don't think it's supposed to be that way. > > [1]: https://github.com/kovidgoyal/kitty/issues/6808 > > [2]: https://github.com/kovidgoyal/kitty/issues/6809 > > [3]: https://github.com/kovidgoyal/kitty/issues/6810 [4]: https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-man_pages [5]: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L178 [6]: https://peps.python.org/pep-0394/ Kind regards, Maytham
signature.asc
Description: This is a digitally signed message part
