Bug 251520 - x11-wm/ctwm: ctwm.1.gz orphan/missing
Summary: x11-wm/ctwm: ctwm.1.gz orphan/missing
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Kurt Jaeger
Depends on:
Reported: 2020-12-02 06:00 UTC by John Kennedy
Modified: 2020-12-20 09:18 UTC (History)
2 users (show)

See Also:
pi: maintainer-feedback+

ctwm pkg-plist patch (339 bytes, patch)
2020-12-02 15:31 UTC, John Kennedy
no flags Details | Diff
poudriere build log (117.59 KB, text/plain)
2020-12-04 14:29 UTC, John Kennedy
no flags Details
Hardcode share/man as the man location. (386 bytes, patch)
2020-12-12 20:27 UTC, fullermd
fullermd: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Kennedy 2020-12-02 06:00:32 UTC
It looks like ctwm-4.0.3,1 has an issue about where to find the man page for ctwm:
man/man1/ctwm.1.gz vs share/man/man1/ctwm.1.gz

[poudriere testport -j 13 -p master x11-wm/ctwm]
-- Installing: /wrkdirs/usr/ports/x11-wm/ctwm/work/stage/usr/local/share/ctwm/images/xman.xpm
-- Installing: /wrkdirs/usr/ports/x11-wm/ctwm/work/stage/usr/local/share/ctwm/images/xmosaic.xpm
-- Installing: /wrkdirs/usr/ports/x11-wm/ctwm/work/stage/usr/local/man/man1/ctwm.1.gz
-- Installing: /wrkdirs/usr/ports/x11-wm/ctwm/work/stage/usr/local/share/doc/ctwm/ctwm.1.html
====> Compressing man pages (compress-man)
====> Running Q/A tests (stage-qa)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: man/man1/ctwm.1.gz
===> Checking for items in pkg-plist which are not in STAGEDIR
Error: Missing: share/man/man1/ctwm.1.gz
===> Error: Plist issues found.
*** Error code 1

make: stopped in /usr/ports/x11-wm/ctwm
=>> Error: check-plist failures detected
build of x11-wm/ctwm | ctwm-4.0.3,1 ended at Tue Dec  1 21:46:38 PST 2020
build time: 00:00:15
!!! build failure encountered !!!
[00:00:23] Error: Build failed in phase: check-plist
[00:00:23] Cleaning up
[00:00:23] Unmounting file systems
Comment 1 John Kennedy 2020-12-02 15:31:06 UTC
Created attachment 220172 [details]
ctwm pkg-plist patch

This fixes my problem, and seems correct to me.
Comment 2 fullermd 2020-12-04 03:17:19 UTC
I'm puzzled about how this is happening.  Note that it was also recently seen on 12.1 on the package builder:


See from the configure stage output:
  -- Installing manpage to      /usr/local/man/man1

(I'm unable to find any _other_ older builds for it in a little digging; there doesn't seem to be any particularly useful interface to the package build logs)

However, the proposed fix is the _inverse_ of ports r523493 which was done in the shadow of ports r523104 and so doesn't seem like it'd be expected behavior...

I can't reproduce it on some -STABLE boxes, or a 12.1 system.  Nor can I obviously see a way the ports framework would be passing an explicit dir in, which means it's down to ctwm's cmake build.  That checks (in order) for $PREFIX/share/man and $PREFIX/man to determine where to put things, with a fallback to $PREFIX/man if it can't find either.  So it could only wind up using $PREFIX/man if $PREFIX/share/man didn't exist.  And if neither existed and it used the fallback, it would print a warning we don't see in the build cluster log:

  -- Enabling standard warnings.
  -- Found X11: /usr/local/include   

(it'd be between those lines)

I don't see any recent changes in ports/Mk that sound suspicious either.  Does anything enlightening show up in your output for the 'configure' stage?
Comment 3 John Kennedy 2020-12-04 14:27:11 UTC
I should probably point out that this is a 13-current box, and I'm obviously building my ports from source and pulling from the master ports branch.

I agree that this is probably something else triggering a change in behavior from ctwm.  -4.0.3,1 has been out there quite a while and was building just fine up to a point and then started failing.

This is output for my patched version, but I assume it'd show you what you wanted to see.

===>  Configuring for ctwm-4.0.3,1
===>  Performing out-of-source build
/bin/mkdir -p /wrkdirs/usr/ports/x11-wm/ctwm/work/.build
-- The C compiler identification is Clang 11.0.0
-- Performing Test COMPILER_TAKES_WALL - Success
-- Enabling standard warnings.
-- Found X11: /usr/local/include
-- Looking for XOpenDisplay in /usr/local/lib/libX11.so;/usr/local/lib/libXext.so
-- Found yacc: /usr/bin/yacc
-- Can't build manpage, using prebuilt version.
-- Can't build HTML manual, using prebuilt version.
-- Installing examples in     /usr/local/share/examples/ctwm
-- Installing manpage to      /usr/local/man/man1
-- Building for ctwm version 4.0.3

[I'll attach the whole thing for you]

I have both of those directories, at least outside of poudriere:

# ls -lasd /usr/local/share/man/ /usr/local/man
9 drwxr-xr-x  32 root  wheel  33 Dec  1 21:28 /usr/local/man
1 drwxr-xr-x   2 root  wheel   3 Dec  1 21:17 /usr/local/share/man/

(/usr/local/share/man only has mandoc.db, but /usr/local/man seems to have the bulk of the contents.

Perhaps an aha (looking at jail via poudriere testport):

# ls -lasd /usr/local/share/man/ /usr/local/man
ls: /usr/local/share/man/: No such file or directory
1 drwxr-xr-x  7 root  wheel  7 Dec  4 14:13 /usr/local/man

Not sure who is responsible for /usr/local/share/man getting created.

# poudriere jail -l
13       13.0-CURRENT 1300130 amd64 src=/usr/src 2020-12-01 20:53:25 /usr/local/poudriere/jails/13

# uname -a
FreeBSD ouroboros.phouka.net 13.0-CURRENT FreeBSD 13.0-CURRENT #235 r368272+9066456bbf48-c273301(master): Tue Dec  1 20:13:08 PST 2020     warlock@ouroboros.phouka.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
Comment 4 John Kennedy 2020-12-04 14:29:57 UTC
Created attachment 220248 [details]
poudriere build log

Full build log included as attachment.
Comment 5 fullermd 2020-12-12 20:26:49 UTC
So, $PREFIX/man and $PREFIX/share/man should be setup by mtree, using $PORTS/Templates/bsd.local.dist.  The ports framework itself only seems to run that to setup the staging dir during the build; it doesn't seem to ever have any involvement in running it on the live system.  And I don't see where poudriere ever references it at all.

So, that covers how you don't have share/man.  But why do you have man?  In a quick glance over the build-depends (or even just simply pkg itself, which is a build-dep of everything anyway), they seem to have scattered various manpages in man/manX.  So that'd bring those into being when doing the build.

So, apparently poudriere _doesn't_ setup the "real" /usr/local/ in its build environments at all.  I'd be inclined to view that as a bug, and I can only assume it's a recent change since this just started popping up.  So I guess we just have to force a choice in the build, since poudriere doesn't let us probe the gross structure /usr/local will always have.

I _assume_ from the referenced earlier changes that moved to it, that share/man is the currently Preferred(tm) place, even though all the deps use man, and my system has 100 meg in /usr/local/man vs 340k in /usr/local/share/man.  But, whatever...

The following (attachment) should jam it over that way.
Comment 6 fullermd 2020-12-12 20:27:21 UTC
Created attachment 220511 [details]
Hardcode share/man as the man location.
Comment 7 John Kennedy 2020-12-13 02:14:43 UTC
My guess would be that one of the dependencies creates ${PREFIX}/man along the way.  In any case, your patch fixed my issue in a way that's less likely to swap in the future.
Comment 8 Kurt Jaeger freebsd_committer 2020-12-20 09:18:11 UTC
Committed, thanks!
Comment 9 commit-hook freebsd_committer 2020-12-20 09:18:55 UTC
A commit references this bug:

Author: pi
Date: Sun Dec 20 09:18:00 UTC 2020
New revision: 558734
URL: https://svnweb.freebsd.org/changeset/ports/558734

  x11-wm/ctwm: fix man page location

  - Hardcode share/man as the man location

  PR:		251520
  Submitted by:	Matthew D. Fuller <fullermd@over-yonder.net> (maintainer)
  Reported by:	John Kennedy <warlock@phouka.net>