Re: sox -> sox_ng?

[Martin Guy <sox_ng%fastmail.com@localhost>]

Hi and sorry for the year-late reply; I only saw this exchange now:

On Thu, 3 Jul 2025 17:49:32 +0200 Thomas Klausner wrote:
> audio/sox has been unmaintained for many years, and has even
> accumulated a number of security reports.
>
> There's a followup project, now packaged as audio/sox_ng.
>
> If you use sox, please take a look at sox_ng and provide feedback if
> we should replace sox with sox_ng.

and on Thu, 03 Jul 2025 12:25:16 -0400 Greg Troxel wrote:

> I guess the big questions are:
>
>   Given sox_ng, would anyone want to use sox?  Seems like sox_ng's
>   opinion is "no".
>
>   What does sox_ng think that packages should be called?  They are
>   calling it sox_ng, not just saying sox, so it sounds like the repo,
>   the package are sox_ng.  And, the installed files are play_ng.  The
>   command name change surprises me.
>
>   Do the sox_ng people expect sox-depending projects to search for and
>   use foo_ng instead?
>
>   You say "replace", but it sounds like "repoint any pkg that depends on
>   sox, and when complete, remove sox".
>
>   What are other packaging systems doing about naming/superceding?

sox_ng is the maintenance and development of sox, as I was unable to 
wrest sox.sf.net from its no-releases-in-nine-years maintainer, so I 
hard forked it in May 2024 and have been working on it for two years.

All 20 CVEs are fixed as well as many, many other bugs, and the release 
series 14.[5678].* each add new effects, options and audio file formats,
but remaining backward-compatible is a criterion for it (except for 
fixing things that previously were unusable or gave wrong output.

Most distros are switching their "sox" package to use sox_ng as its 
upstream in "./configure --enable-replace" mode to create links 
sox->sox_ng, play->play_ng and so on for libs, headers, manual pages, etc.

I see that pkgsrc now has separate sox and sox_ng packages at 14.4.2 and 
14.6.0.2 respectively, presumably leaving users to have to know about 
sox_ng, install it explicitly and modify their scripts to use sox_ng 
instead of sox; unless they do this, anything that uses sox or depends 
on libsox remains two dozen security holes and all the things that 
didn't work properly and have been fixed.

If making pkgsrc's "sox" package transition to "sox_ng" is not an option 
now that both exist, or if making "sox" use sox_ng-latest seems risky, I 
would at least suggest making "sox" transition to the latest 
sox_ng-14.4.* which is for CVE and bug fixes only to old sox-14.4.2.
There have been occasional reports of things that worked before not 
working in some new-feature releases, such as reading very broken WAV 
files, but all that have been reported have been fixed in subsequent 
patch releases (14.X.Y.*).
In any case, updating "sox_ng" package from 14.6 to 14.8 would bring 
another year's work of improvements.

Compilation and testing is done regularly on NetBSDen on mips and evbarm 
architectures, big and little endian, 32- and 64-bit thanks to the GCC 
Compile Farm.

Sorry for the delay and the length of the reply!

    M