Bug 183343 - man XMoveWindow fails (man3x -> man3 problem)
man XMoveWindow fails (man3x -> man3 problem)
Product: Fedora
Classification: Fedora
Component: libX11 (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: EasyFix
Depends On:
  Show dependency treegraph
Reported: 2006-02-28 08:38 EST by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-06 05:12:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing shadow manpages (62.40 KB, patch)
2006-03-01 04:52 EST, Hans de Goede
no flags Details | Diff

  None (edit)
Description Hans de Goede 2006-02-28 08:38:59 EST
[hans@shalem devel]$ man XMoveWindow
fopen: No such file or directory
Cannot open man page /usr/share/man/man3x/XConfigureWindow.3x.gz
No manual entry for XMoveWindow

man XConfigureWindow works fine. The problem is:
[hans@shalem devel]$ cat /usr/share/man/man3/XMoveWindow.3x.gz | gzip -d | cat
.so man3x/XConfigureWindow.3x
[hans@shalem devel]$

So the .so text needs man3x changed to man3. There are most likely others.
Comment 1 Hans de Goede 2006-02-28 13:13:35 EST
I was wondering if you guys (Mike ?) would accept a (clean) patch for this
before FC5 goes out. I'm willing to invest time to write a patch for this, but
only if it has a real chance of getting in before FC5.
Comment 2 Mike A. Harris 2006-03-01 02:41:05 EST
The sooner a patch is attached to the bug, the more likely it would have a
chance of getting into FC5, however that's up to release engineering to
decide wether to allow a package in now.

See: http://fedoraproject.org/wiki/Core/ReleaseFreezeProcess

Comment 3 Hans de Goede 2006-03-01 04:18:24 EST
Thanks for the heads up. Working on a patch as we speak. The problem is in
libX11/man/Makefile.xx it uses the manpage suffix (3x) while creating the
shadoew manpages and not only for the suffix but also for the path to the page.

I'll fix this so that it uses the correct path, but it might be an idea to
change the suffix in the future to the standard .3 suffix or is their a special
reason for the 3x ?
Comment 4 Hans de Goede 2006-03-01 04:53:00 EST
Created attachment 125456 [details]
Patch fixing shadow manpages

As requested / promised a patch fixing this. AFAIK its 100% safe / ok, but my
Makefile skills aren't fully up to spec, so please review before applying (its
Comment 5 Mike A. Harris 2006-03-01 20:57:01 EST
Seems it was already fixed upstream.
Comment 6 Hans de Goede 2006-03-04 02:59:50 EST
Ah, I see and it affects other packages too. Any chance of extracting the fix
from upstream CVS and fixing this before FC5 or with one of the first updates?

Since I'm doing some Xlib programming its rather anoying, then again I guess not
that much people do Xlib programming so its no priority.
Comment 7 Mike A. Harris 2006-06-06 05:12:11 EDT
Works now in libX11-1.0.1-2
Comment 8 Ralf Corsepius 2006-08-14 00:31:00 EDT
Still unfixed in FC5.

Note You need to log in before you can comment on or make changes to this bug.