Thanks Stuart and Theo; is this still ok to commit with the lock coming?

On Fri, Apr 17, 2026 at 8:43 AM Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2026/04/17 15:38, Theo Buehler wrote:
> > On Fri, Apr 17, 2026 at 08:02:08AM -0500, Brent Cook wrote:
> > > On Fri, Apr 17, 2026 at 7:53 AM Brent Cook <busterb@gmail.com> wrote:
> > >
> > > > On Thu, Apr 16, 2026 at 11:14 PM Theo Buehler <tb@theobuehler.org> 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. <facepalm>
> >
> > 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.
>
> agreed on all counts.
>
> > 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 \
> >