Created attachment 233023 [details] Patch to include missing man page section Occasionally when building openvpn, the included doc/openvpn.8 man page isn't used, and it attempts to rebuild the man page from source. This fails because the doc/man-sections/cipher-negotiation.rst file is missing from the distribution tarball. I have reported this upstream: https://community.openvpn.net/openvpn/ticket/1461 The attached patches fix this for me. Errors seen: --- openvpn.8 --- rst2man openvpn.8.rst > openvpn.8 --- openvpn.8.html --- rst2html openvpn.8.rst > openvpn.8.html --- openvpn.8 --- openvpn.8.rst:78: (SEVERE/4) Problems with "include" directive path: InputError: [Errno 2] No such file or directory: 'man-sections/cipher-negotiation.rst'. Exiting due to level-4 (SEVERE) system message. *** [openvpn.8] Error code 1 make[4]: stopped in /ports-work/usr/ports/security/openvpn/work/openvpn-2.5.6/doc --- openvpn.8.html --- openvpn.8.rst:78: (SEVERE/4) Problems with "include" directive path: InputError: [Errno 2] No such file or directory: 'man-sections/cipher-negotiation.rst'. Exiting due to level-4 (SEVERE) system message. *** [openvpn.8.html] Error code 1
Created attachment 233024 [details] Add missing man page section to doc Makefile
Created attachment 233025 [details] Patch to add missing man page section.
Jan Martin, thanks for the report. While the description seems plausible, this did not show up in my testing. Any clues as to why the build tries to rebuild the documentation? What are your port options? How exactly are you building? What tools (poudriere, portmaster, ...) and settings? Is the computer clock in synch? What file systems involved? Network storage involved (NFS, NAS, ...)? USB sticks involved?
Note that we patch the *output* documentation because we do not run openvpn as "nobody", but under its own account instead. This is why I am asking for your computer clock - if you build with a clock that is sufficiently behind, these things will happen because the patch would then make the output older than the source.
(In reply to Matthias Andree from comment #4) Hi Matthias, The build machine has a clock synchronised using chronyd and NTP. The filesystem is a local ZFS filesystem on mirrored SATA SSDs. The build is done as part of an in-house build system, building many things in parallel, on a fresh filesystem. The package options are defaults. Other things: MAKE_JOBS_NUMBER_LIMIT=32 BATCH=yes NO_DEPENDS=yes PACKAGE_BUILDING=yes I see the patch against the output file, but I also see a patch against the man page source: patch-doc_man-sections_generic-options.rst The problem does seem to be timing related. It did not occur on each run. During the run, the machine can be very busy. On earlier runs, the machine has recently been upgraded from 12.2 to 13.1, and the OpenZFS autotrim property had not been turned on for the SSD pool. The lack of autotrim caused performance problems with one of the SSDs after a lot of writes, it is possible I first saw this problem while that also affecting the timing.
OK. Patches are to be applied in lexicographical order, so I deemed it safe. I have no experience with OpenZFS or its timestamp precision or visibility and attribute caching behavior, I have only ever used the native ZFS, and I have never seen my builds attempt to rebuild the manpage. Given we do not install the .rst file, and I do not deliberate rebuilding it in the port -- would removing the source patch files/patch-doc_man-sections_generic-options.rst fix the build issue for you? That would be a simpler fix and should not change the resulting package (because, as you've written and I believe you, that an attempt to rebuild the manual page from incomplete sources will fail, so no package).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5f10d01ce1d79fed8456d454b7cb24afea1a4ae3 commit 5f10d01ce1d79fed8456d454b7cb24afea1a4ae3 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2022-04-26 21:58:20 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2022-04-26 21:59:42 +0000 security/openvpn: drop man source patch There has been a report of sporadic man-page rebuilds on OpenZFS. While the patch order is correct, we do not intend to rebuild the manpage (after a nobody -> openvpn change, for instance), and we also patch the output files. So just remove the source patch. This should go without any functional changes, so ships without bumping PORTREVISION. There is an upstream ticket reporting a missing source file in the tarball. https://community.openvpn.net/openvpn/ticket/1461 Reported by: Jan Martin Mikkelsen PR: 263116 .../files/patch-doc_man-sections_generic-options.rst (gone) | 11 ----------- 1 file changed, 11 deletions(-)
I believe this commit should avoid the issue. If it does not, feel free to reopen this report and adding more data that will help me understand the issue. For the records, I believe the build system is faulty somehow, but cleaning up the port should not hurt either.
I agree that removing the source code patch is good approach, especially given the source doesn't build. The real solution is for the missing file to be added to the upstream distribution tar file. Thanks for updating the port.
Yes, the upstream will have to fix the Makefile.am (but I suppose since they ship the output, a "make distcheck" would not flag the error) - for the port we don't need the fix, we just stop changing the source so that the output files that we do patch are definitely newer. I should not have committed the source patch in 2.5.4_1 in the first place...