improving the 404 manpage not found?
Closed this issue · 5 comments
https://dyn.manpages.debian.org/jump?q=command-not-found
could the webserver get the binary, run help2man thecommand > thecommand.1 (or the right section, if from /usr/games, section 6 etc) provide that page, in a editable way (like on github) and on submission do a patch on debian bts? if the project is on github, also a pull request with the manual page to the right project on github?
For reference from man man
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]
could the webserver get the binary, run help2man thecommand > thecommand.1 (or the right section, if from /usr/games, section 6 etc) provide that page, in a editable way (like on github) and on submission do a patch on debian bts?
Thanks for your suggestion! I’d love it if this was possible. Unfortunately, we face a number of technical challenges here, AFAIK:
- getting the binary is prohibitively expensive: we’d need to extract the entire .deb (otherwise the binary may or may not even start), which can be large, then run that command, which is potentially computationally expensive or maybe even harmful. This would need to be sandboxed, rate-limited and run in the background, for all of which we lack infrastructure.
- I’m not aware of web-based submission to the Debian BTS
if the project is on github, also a pull request with the manual page to the right project on github?
Perhaps unexpectedly, this might actually be the most feasible part :). We’d need to act on behalf of the user, though, which requires an oauth prompt at least. I haven’t thought through whether that would have security/privacy implications (i.e. would we need to store sensitive data, such as oauth tokens).
One more note when thinking about this on a higher level: note that it’s a Debian policy violation to ship binaries without manpages. Hence, I expect this case to be rare, which places this feature further down on the priority list.
I’ll close this issue as “limitation”, as we’re limited by other services, infrastructure and our stack.
absolutely fine, if i still can add comments here, for the help2man, this could be done on a separate machine, i guess i could do so... but where would i put all the manpage-skeletons?
and for the web based bts, give me some more time, i've got something in the works
oh, and there's a LOT:
https://lintian.debian.org/tags/binary-without-manpage.html
for the help2man, this could be done on a separate machine, i guess i could do so... but where would i put all the manpage-skeletons
Note that my concern is not just about the resource consumption itself, but also about the general complexity and number of moving parts in the Debiman setup. Hence, offering a machine is nice, but doesn’t address my concerns.
and for the web based bts, give me some more time, i've got something in the works
Please keep me in the loop, I’m very interested.
here's something that only looks like a bug reporter how i would create one, with the following notes:
certainly not yet functional, complete, nor anything, just it would work for me for the most basic bug reports (like, oh look this pkg is there in a newer version, can you please upgrade it?). feedback/tips/patches/whatever welcome
http://www.aiei.ch/debian/
(using framework7 and i know about pseudo-packages that i somehow want to get in also)
and for the pkglist/versions, i'm not sure if i want it in a list, or in a field with autocomplete