Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: [NEW] comms/qrq
To:
Enzo Nicosia <me@katolaz.net>
Cc:
ports@openbsd.org
Date:
Tue, 30 Dec 2025 10:46:48 +0000

Download raw body.

Thread
I would drop the flavour. My understanding is that the OSS emulation in
libossaudio shouldn't be used for new things - the preferred option is
patching to use sndio - sio_open(3) etc - bit otherwise I would use the
existing pulseaudio support.

Various comments,

- option-specific patches are a pain to deal with, if the flavour was
necessary everything you've done in the patch variants could be handled
by a smaller patch + MAKE_ENV/MAKE_FLAGS instead

- generally don't patch for strlcpy snprintf etc in ports, if done at all
that should go upstream (but also should check return values etc).
patching to use PATH_MAX+300 for a string holding a path makes no sense.
i'd just drop that patch

- qrqscore needs p5-libwww to run. not sure if it's worth adding a dep.
a note in DESCR might be appropriate but considering the code quality
(besides the string handling, there's unsafe /tmp use, calls to system
for things that woukd be better done from C, etc) I'm not sure I'd
want it going near data fetched from the net

- no need to patch for 'make uninstall', it's never called from ports

possible simpler tar attached