On Sat, Nov 11, 2023 at 12:57:38PM +0800, Maytham Alsudany wrote: > 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.
Ah, right! > > > 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. I have seen python as being more common. Possibly because people use venv for python stuff and that always has a bin/python executable. > > > 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. For now, I suppose that'd be the case. > > > 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. I did. Maybe we will switch to a non-dhgolang layout if this continues to be an issue. I used this because it avoid symlinking everything that'd there in usr/share/gocode and automates the built-using field thingy etc. We will re-evaluate this at a later point. > Hopefully we can get kitty to be stable enough to move into unstable, > I'm excited to see it propagate into testing! I will meanwhile ask a couple of people to test out the new kitty package. BTW, oddly enough kitty is failing its build on ppc64el[7] which will block migration. The tests failing in the question are trying to open a PTY, which I suppose ppc64 does not like. I am in favor of skipping these on that architecture, if you're fine with that. > Regarding lintian's errors, would you like me to add descriptions to > your patches (by that, I mean copy-paste your commit messages)? Ah, sure. I had been lazy to not do that. > Additionally, I keep forgetting to mention that lintian.debian.org > seems to not work, I am also involved with lintian maintenance in "some" capacity and while getting lintian.d.o is in TODO, no-one realistically has the time for that. Lintian.d.o has been effectively replaced with its UDD counterpart[7] > so I've had to resort to `lintian-explain-tags`. I > don't think it's supposed to be that way. Agreed. There's a plan to implement tag explanations within UDD at some point as has been pointed out in this thread[8]. > > > [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/ [7]: https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg [8]: https://lists.debian.org/debian-devel/2023/09/msg00394.html Best, Nilesh
signature.asc
Description: PGP signature
