id summary reporter owner description type status priority milestone component version resolution keywords cc port 62798 "freeciv 2.6.4: man freeciv-gtk2 etc. ""can't open"" ""No such file or directory"" (.so directive and .gz?)" JDLH "The **freeciv** and **freeciv-x11** ports install both conventional and stub man pages in man6. The stub man pages do not display correctly. I suspect that this may be due to the stub manpages using an .so directive to include another freeciv man page, and MacPorts storing those man pages using .gz compression. **How to reproduce** 1. Install **freeciv** or **freeciv-x11** ports 2. `man freeciv-gtk2` **Observed behaviour** {{{ :14: can't open `man6/freeciv-client.6': No such file or directory (END) }}} **Expected behaviour** The same page appears as when one commands, `man freeciv-client`. **Discussion** Any of the stub man pages, freeciv-gtk2, freeciv-gtk3.22, freeciv-gtk3, freeciv-mp-cli, freeciv-mp-gtk2, freeciv-mp-gtk3, freeciv-mp-qt, freeciv-qt, freeciv-ruledit, freeciv-sdl, freeciv-sdl2, freeciv-xaw, will fail in a similar way. All these pages appear to consist only of a few lines of comments, then a troff ""include file"" directive of the form, {{{ .so man6/freeciv-client.6 }}} The stubs might refer to `man6/freeciv-modpack.6` instead, depending on the stub. I notice that MacPorts installs these man files in compressed form, as `/opt/local/share/man/man6/freeciv-client.6.gz` and similar. So I speculate that maybe the groff or whatever is displaying these man pages is not able to translate the `.so man6/freeciv-client.6` directive into the require action to find `man6/freeciv-client.6.gz` and decompress it. If this is correct, then more ports might be affected than just **freeciv**. A possible fix might be for MacPorts to install `man6/freeciv-client.6` and `man6/freeciv-modpack.6` in uncompressed form, as a special case. Is there a way to specify that in the portfile? " defect new Normal ports 2.6.4 upstream freeciv