Re: sysutils/reaction

Le 26/08/2026 à 06:45, ed@groovyexpress.com a écrit :

I'd also beware of big reaction databases. On one of my systems the
reaction database had grown to about 500MB which would require very
big daemon timeouts (60s wasn't enough, 120s is too long), would use
a very high amount of CPU usage for hours and slowly process pfctl
commands

Did you have this issue before or after v2.4.0?

https://framagit.org/ppom/reaction/-/releases/v2.4.0

An issue with big databases has been resolved, where reaction was continuously trying to GC the DB past a certain DB size.

If you still have this issue with a 2.4.0 or later, I'd be glad to have more information on that!

Best,

ppom

Re: [update] mail/mlmmj 1.4.5 -> 2.1.0

2026-08-27T14:35:58+0200 Stefan Sperling <stsp@stsp.name>: > On Thu, Aug 27, 2026 at 12:25:50PM +0000, Johannes Thyssen Tishman wrote: > > 2026-08-27T13:35:56+0200 Stefan Sperling <stsp@stsp.name>: > > > On Thu, Aug 27, 2026 at 11:16:33AM +0000, Johannes Thyssen Tishman wrote: > > > > Thanks for pointing this out. Without the fs_test.c patch, kyua-testers > > > > doesn't build on OpenBSD: > > > > > > > > ld: error: undefined symbol: lchmod > > > > >>> referenced by fs_test.c > > > > >>> fs_test-fs_test.o:(lchmod_fails) > > > > > > > > So my guess is that fs_test.c was patched such that the port would > > > > compile, but lchmod wasn't patched out completely. The error bapt > > > > mentions in the issue comes from fs.c:261 (try_unprotect_symlink()), > > > > which is thrown because HAVE_WORKING_LCHMOD isn't defined. This can be > > > > seen in the configure logs: > > > > > > > > checking for a working lchmod... no > > > > > > > > > > Ah, indeed. Now it makes sense. > > > > > > > I suppose we could use a stub with fchmodat()? > > > > > > Yes. Something like this should work: > > > > Still getting 208/261 passed (53 failed), so maybe the problem is > > somewhere else. I'll report this upstream. Should we go ahead with the > > update regardless? > > > > Yes, I think we can go ahead. Should any problems show up at run-time we > can still address them later. These test failures really look like a > test suite problem to me. Committed, thanks :)