Created attachment 220493 [details] Patch for cpu-x Patch CMakeLists.txt to use correct libexec path This application is targeted towards x86/amd64 however a few things like benchmarking also works on other platforms while hardware detection doesn't (lack of support by upstream). While at it, limit building to arm and x86/x86-64 platforms for now. Rearrange Makefile to make Portlint happy Compile and run-time tested on FreeBSD 13.0-CURRENT #3 0381b3d8be3-c272567(master)-dirty (aarch64) (without X11) Compile and run-time tested on FreeBSD 13.0-CURRENT r367711 (amd64) (make, make check-plist) (without X11) Poudriere testport OK 12.2-RELEASE (amd64)
Thanks for the patch, albeit it's a bit too noisy for my taste. :-) - DISTVERSION and PORTREVISION are uncalled for (always prefer PORTVERSION unless it contains things like dashes, underscores, or weird suffixes, if that's the case, resort to DISTVERSION) - COPYING is just a boilerplate in this port (e.g. it does not contain copyright information), thus I've waived the LICENSE_FILE - Why `localbase' is needed on USES list? - X11_CMAKE_OFF works just fine, those boolean helpers look too smart to me :) - I don't see the need for libexec patch: the daemon ends up in the correct directory anyways, no? - ONLY_FOR_ARCHS can probably be waived as well, since the software itself is not inherently limited to them In essence, we just need to expand the .if ${ARCH} to handle more arches, which I agree is a good thing, will do.
Hi, Handbook says otherwise regarding DISTVERSION and PORTVERSION as far as I can tell. Ref: http://www.no.freebsd.org/doc/en/books/porters-handbook/book.html --> "Table 5.2. Package Naming Examples" On aarch64 I ran into issue where it wouldn't find some libs (not using poudriere), however adding localbase fixed those issues (non X11 build). Regarding libexec, depending on deps (non X11) the daemon gets installed in wrong path using Poudriere and ends up in lib instead. I opted for ONLY_FOR_ARCHS to keep the noise down (failures) as some libraries are x86/amd64 centric (and will fail on other arches) such as libcpuid.
> Regarding libexec, depending on deps (non X11) the daemon gets installed in > wrong path using Poudriere and ends up in lib instead. Indeed, after the port was flavorized, ncurses flavor now fails like you describe! I still can't reproduce it and have no idea why it's happening and only with ncurses. Looking at share/cmake/Modules/GNUInstallDirs.cmake, ${CMAKE_INSTALL_FULL_LIBEXECDIR} should be defined and point to /usr/local/libexec which is definitely present. I'll take a closer look at .build/CMakeCache.txt et al. for any clues.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ca9e112b42fdc623acc09e7ec5707249e08fa6ad commit ca9e112b42fdc623acc09e7ec5707249e08fa6ad Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-04-07 14:23:10 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2023-04-07 14:23:10 +0000 sysutils/cpu-x: try to further improve the port (part one) - Setting PKGNAMESUFFIX=-${FLAVOR} for all flavors was actually misleading: graphic version (GTK+) includes ncurses UI as well, so mark the console-only one as such (`tuionly') while keeping the full package unsuffixed - Assembler is only used to translate two x86 files which belong to the memory bandwidth code, make it conditional based on the ${ARCH} and thus (hopefully) unbreak the build on !x86 PR: 251785 sysutils/cpu-x/Makefile | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
(In reply to Alexey Dokuchaev from comment #3) > I still can't reproduce it and have no idea why it's happening and only > with ncurses. Last night we managed to reproduce it with fluffy@ and now understand the problem. Standby for the fix.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=eb6c9c8c4aa5981078c6b9b69527ecdaee5f22c9 commit eb6c9c8c4aa5981078c6b9b69527ecdaee5f22c9 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-04-08 13:05:44 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2023-04-08 13:05:44 +0000 sysutils/cpu-x@ncurses: unbreak the port's packaging under Poudriere Back in 2020 diizzy@ had reported that daemon was installed in the wrong path when the port was built under Poudriere without X11 (GTK+) support. This seemed totally odd (and not reproducible in the Tinderbox) so I've scratched my head and put it off for better times. When the port was converted to flavors, the problem had resurfaced: now the ncurses flavor was failing on the cluster! Looking at the CMake code, it calls `include(GNUInstallDirs)' which correctly sets CMAKE_INSTALL_FULL_LIBEXECDIR to `/usr/local/libexec'. The code then checks for its existence, the failure logs indicate that it does not exist, which should not be possible because it is part of the `Templates/BSD.local.dist', so it should be mtree'd inside the build jail. Tinderbox does exactly this, but not Poudriere, so unless this directory is created (populated) by the dependencies or e.g. ccache(1), one cannot assume that it really exists in pristine environment. Regardless of whether mtree'ing jail with `BSD.local.dist' is the right thing or not, checking for some common path existence and setting it to something else if it's not found is definitely wrong. This was a joint investigation by fluffy@ and yours truly. PR: 251785 sysutils/cpu-x/files/patch-CMakeLists.txt (new) | 13 +++++++++++++ 1 file changed, 13 insertions(+)
A commit in branch 2023Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2f8328651233b3c95b59b952fadf6b09b9ca3618 commit 2f8328651233b3c95b59b952fadf6b09b9ca3618 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-04-07 14:23:10 +0000 Commit: Joseph Mingrone <jrm@FreeBSD.org> CommitDate: 2023-04-12 15:23:04 +0000 sysutils/cpu-x: try to further improve the port (part one) - Setting PKGNAMESUFFIX=-${FLAVOR} for all flavors was actually misleading: graphic version (GTK+) includes ncurses UI as well, so mark the console-only one as such (`tuionly') while keeping the full package unsuffixed - Assembler is only used to translate two x86 files which belong to the memory bandwidth code, make it conditional based on the ${ARCH} and thus (hopefully) unbreak the build on !x86 PR: 251785 (cherry picked from commit ca9e112b42fdc623acc09e7ec5707249e08fa6ad) sysutils/cpu-x/Makefile | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
A commit in branch 2023Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=229ce36802676a474c0906dd485ca459e556075d commit 229ce36802676a474c0906dd485ca459e556075d Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-04-08 13:05:44 +0000 Commit: Joseph Mingrone <jrm@FreeBSD.org> CommitDate: 2023-04-12 15:23:04 +0000 sysutils/cpu-x@ncurses: unbreak the port's packaging under Poudriere Back in 2020 diizzy@ had reported that daemon was installed in the wrong path when the port was built under Poudriere without X11 (GTK+) support. This seemed totally odd (and not reproducible in the Tinderbox) so I've scratched my head and put it off for better times. When the port was converted to flavors, the problem had resurfaced: now the ncurses flavor was failing on the cluster! Looking at the CMake code, it calls `include(GNUInstallDirs)' which correctly sets CMAKE_INSTALL_FULL_LIBEXECDIR to `/usr/local/libexec'. The code then checks for its existence, the failure logs indicate that it does not exist, which should not be possible because it is part of the `Templates/BSD.local.dist', so it should be mtree'd inside the build jail. Tinderbox does exactly this, but not Poudriere, so unless this directory is created (populated) by the dependencies or e.g. ccache(1), one cannot assume that it really exists in pristine environment. Regardless of whether mtree'ing jail with `BSD.local.dist' is the right thing or not, checking for some common path existence and setting it to something else if it's not found is definitely wrong. This was a joint investigation by fluffy@ and yours truly. PR: 251785 (cherry picked from commit eb6c9c8c4aa5981078c6b9b69527ecdaee5f22c9) sysutils/cpu-x/files/patch-CMakeLists.txt (new) | 13 +++++++++++++ 1 file changed, 13 insertions(+)