Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#60288 - [dune] wrong installation path of manual pages

Attached to Project: Community Packages
Opened by Jakub Klinkovský (lahwaacz) - Wednesday, 03 October 2018, 08:34 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Tuesday, 23 October 2018, 13:58 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The manual pages are installed directly in /usr/share/man/ instead of the proper section subdirectory /usr/share/man/man1/

usr/share/man/dune-build.1.gz
usr/share/man/dune-clean.1.gz
usr/share/man/dune-config.5.gz
usr/share/man/dune-exec.1.gz
usr/share/man/dune-external-lib-deps.1.gz
usr/share/man/dune-help.1.gz
usr/share/man/dune-install.1.gz
usr/share/man/dune-installed-libraries.1.gz
usr/share/man/dune-printenv.1.gz
usr/share/man/dune-promote.1.gz
usr/share/man/dune-rules.1.gz
usr/share/man/dune-runtest.1.gz
usr/share/man/dune-subst.1.gz
usr/share/man/dune-uninstall.1.gz
usr/share/man/dune-unstable-fmt.1.gz
usr/share/man/dune-utop.1.gz
usr/share/man/dune.1.gz
This task depends upon

Closed by  Bruno Pagani (ArchangeGabriel)
Tuesday, 23 October 2018, 13:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in repo and upstream.
Comment by Bruno Pagani (ArchangeGabriel) - Thursday, 11 October 2018, 18:42 GMT
Please report upstream. I’ll fix the package in the meantime, but this should be fixed globally.
Comment by Jakub Klinkovský (lahwaacz) - Friday, 12 October 2018, 04:26 GMT
dune seems to have a --mandir parameter so maybe you're just configuring it wrong: https://github.com/ocaml/dune/issues/680#issuecomment-379190897

Also, just telling people to report such packaging problems upstream is rather discouraging for people who never tried to build the package manually or even never used the package itself. There are ways to detect these problems programmatically so if this is not the way to get this fixed, what is?
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 12 October 2018, 11:18 GMT
Well I know you from your numerous wiki edit, so I figured out that you must be an Arch power user and would be able to do such things. ;)
I acknowledge this should be my role, but I have very little free time at hand currently unfortunately… Plus my interest in the OCaml stack vanished some weeks ago, so… I need to get in touch with the former maintainer, I seem to remember he might be interested in becoming a TU.

Anyway the mandir arg is not the solution, because the correct value to pass would be `usr/share/man/`. Note that there is a man5 entry amongst those (dune-config.5), so hacking it to install under `man1` is not the right thing to do. Since I had a bit of time available right now, I’ve opened a ticket upstream for this: https://github.com/ocaml/dune/issues/1441.

BTW, we apparently don’t have automatic checking for this kind of issue.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 12 October 2018, 11:30 GMT
(Also currently those options do not exist, only --prefix and --libdir do)
Comment by Eli Schwartz (eschwartz) - Friday, 12 October 2018, 13:12 GMT
> Also, just telling people to report such packaging problems upstream is rather discouraging for people who never tried to build the package manually or even never used the package itself. There are ways to detect these problems programmatically so if this is not the way to get this fixed, what is?

I'm completely lost, how on earth is it discouraging to ask users to report the bug to the right location? What on earth does this have to do with "tried to build the package manually"?

If you've "even never used the package itself", how did you discover the bug? I assume anyone clever enough to write their own tooling to detect manpages installed in the wrong location, is also clever enough to discover that the upstream url for the package in question, is a github project page, and find the relevant issue reporting facility therein.

"Also, just telling people to report such packaging problems upstream" -- but that's not even true either, since he actually said he would fix it himself while waiting for upstream to fix it, and in fact has done so.

...

Can we not go around picking fights, and extremely surreal fights at that?
Comment by Jakub Klinkovský (lahwaacz) - Friday, 12 October 2018, 18:51 GMT
The bug was found thanks to a warning in an update script [1] for some website. I have indeed never used this package and without trying to build the package manually I don't have the necessary knowledge to collect information for a sensible upstream bug report. What's discouraging is that most people seem to think that I must have much more spare time than them so they ask these seemingly trivial things. I'm sorry if my comment offended anybody, that was not the intention.

[1] https://github.com/lahwaacz/archweb_manpages/blob/master/update.py#L135
Comment by Eli Schwartz (eschwartz) - Friday, 12 October 2018, 21:13 GMT
So, you could say that without claiming that asking the reporter to do so is somehow discouraging people from reporting bugs? How is the package maintainer supposed to know you're the unusual person who has a manpages tool that incidentally lints the entire archlinux repository?

"I would love to report the bug upstream, however in this case I don't actually use the package, and discovered the issue due to running an unrelated service that processes manpages for all archlinux packages. Therefore, I think it would be a better idea for the package maintainer, who uses and understands the software, to research why the bug happens and determine whether to file an upstream bug and if so, what information to provide."

Isn't that so much better than "I find your request for me to report a bug upstream, to be rather discouraging, because in the general case you shouldn't go around saying that to people who might not have used the software themselves"?
Which is a contextless argument and opens the door to saying that the package maintainer should like assume by default that people reporting bugs for a program, discovered the bug without using it.

tl;dr
I only noticed anything, because you started throwing around words like "discouraging".

Loading...