From: Theo Buehler Subject: Re: [Fix] Patch btop to report active CPU usage correctly, remove desktop runtime dependency To: Brent Cook Cc: ports@openbsd.org Date: Fri, 17 Apr 2026 15:38:35 +0200 On Fri, Apr 17, 2026 at 08:02:08AM -0500, Brent Cook wrote: > On Fri, Apr 17, 2026 at 7:53 AM Brent Cook wrote: > > > On Thu, Apr 16, 2026 at 11:14 PM Theo Buehler wrote: > > > > > > On Thu, Apr 16, 2026 at 09:47:54PM -0500, Brent Cook wrote: > > > > I like to use btop to monitor resource usage on servers, but it wasn't > > > > reporting per-core CPU usage correctly on OpenBSD. I reported and got > > > > the issue fixed upstream, but it might be a while until the next > > > > release, so I wanted to pull that diff into ports in the mean time: > > > > > > > > https://github.com/aristocratos/btop/pull/1587 > > > > > > > The CPU one makes sense to me and it definitely improves things in the > > > default display. However, the tool can't handle CPUs being added at > > > runtime. If you remove S from hw.blockcpu (or toggle hw.smt 0 -> 1), > > > a running btop throws an exception and dies: > > > > > > ERROR: Exception in runner thread -> Cpu:: -> collect() : vector > > > > > > I have no real opinion on whether that is acceptable or not. It doesn't > > > look like an absolute blocker to me, but it doesn't seem ideal. > > > > > > You'd need to add REVISION=0 to the Makefile, and I would also add a link > > > to your PR at the top of the patch. > > > > Here's v2, with a check made to active CPU count on each poll so the > > stats vectors are resized and the UI is redrawn when that changes. > > > > My 4 core machine didn't crash for some reason in testing, but I think > > As I was feeding the chickens this morning, it came to me - I was > testing with all of the cores/threads active, then removing them while > btop was running, which meant the vectors were already sized big > enough to avoid the crash. Yeah, exactly. Good thing the chicken helped with my lack of clarity. It's an 8 cores/16 threads AMD Ryzen 7 PRO 5850U where I ran into this. The modified patch doesn't help. It still exits the same way if I start btop with 8 cores and turn on smt while it's running. I don't think it's a big deal, but it would be nice to fix eventually. I'm ok with committing the patch in your first mail (the combination of the upstreamed changes) with REVISION = 0. Could you make one more change before commit, please? Since sparc64 now has gcc 15, this allows it to build the package. It works. Index: Makefile =================================================================== RCS file: /cvs/ports/sysutils/btop/Makefile,v diff -u -p -r1.8 Makefile --- Makefile 28 Dec 2025 05:40:27 -0000 1.8 +++ Makefile 17 Apr 2026 13:31:42 -0000 @@ -12,7 +12,7 @@ PERMIT_PACKAGE= Yes WANTLIB += ${COMPILER_LIBCXX} c kvm m # C++23 -COMPILER = base-clang +COMPILER = base-clang ports-gcc BUILD_DEPENDS= textproc/lowdown RUN_DEPENDS= devel/desktop-file-utils \