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 Stop. 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
Created attachment 220172 [details] ctwm pkg-plist patch This fixes my problem, and seems correct to me.
I'm puzzled about how this is happening. Note that it was also recently seen on 12.1 on the package builder: http://package19.nyi.freebsd.org/data/121amd64-default-build-as-user/556467/logs/ctwm-4.0.3,1.log 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?
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 JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 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
Created attachment 220248 [details] poudriere build log Full build log included as attachment.
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.
Created attachment 220511 [details] Hardcode share/man as the man location.
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.
Committed, thanks!
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 Log: 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> Changes: head/x11-wm/ctwm/Makefile