Hello, just a gentle reminder on this one. Is it OK?
Regards Enzo On Mon, Jan 05, 2026 at 02:52:32PM +0000, Enzo Nicosia wrote: > Hello Stuart, > > thanks a lot for your comments and sorry for the late reply. > > Thanks for the simpler tgz. I only made a change in DESCR to note that > qrqscore would need p5-libwww in order to run. Amended tgz attached, and > responses to your points are inline below. > > Is this OK? > > Enzo > > On Tue, Dec 30, 2025 at 10:46:48AM +0000, Stuart Henderson wrote: > > 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. > > I agree on removing the FLAVORS, if the OSS emulation is considered > legacy. The pulseaudio version was the original one I built. Then I > realised that the OSS version compiled and ran seamlessly with minimal > changes, and no added deps. That's why I tried the version with two > FLAVORS. I will see if it is easy to get a native sndio version in the > future, but I think it is safer to include only the pulseaudio option > for now. > > > > > 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 > > > > OK, point taken. I have now read again about MAKE_ENV/MAKE_FLAGS, and I > see what you mean. That makes total sense. > > > - 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 > > > > OK, I will then make a proper patch and upstream it to the author > instead of including it in the port. > > > - 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 > > > > I have added a note in DESCR about that. Well, makes a single request > to a page owned by the qrq author. I would probably leave it like it is. > > > - no need to patch for 'make uninstall', it's never called from ports > > > > point taken. Thanks. > > > possible simpler tar attached > > > > -- --
