Re: libsndfile 1.2.0

2023-01-11 Thread Omar Polo
On 2023/01/11 15:50:54 +0100, Jan Stary wrote: > Ah, looking at the nm(1) diff of the previous and current linsdfile.so, > the ogg_opus_seek_manual symbol is missing now (1.2.0) wrt previous (1.1.0). > Does that imply a SHARED_LIBS bump? that's a symbol used by the library, not provided by it, so

Re: libsndfile 1.2.0

2023-01-11 Thread Stuart Henderson
On 2023/01/11 15:50, Jan Stary wrote: > Ah, looking at the nm(1) diff of the previous and current linsdfile.so, > the ogg_opus_seek_manual symbol is missing now (1.2.0) wrt previous (1.1.0). > Does that imply a SHARED_LIBS bump? lower-case 't' not upper-case; that's a private internal function, no

Re: libsndfile 1.2.0

2023-01-11 Thread Theo Buehler
On Wed, Jan 11, 2023 at 03:50:54PM +0100, Jan Stary wrote: > Ah, looking at the nm(1) diff of the previous and current linsdfile.so, > the ogg_opus_seek_manual symbol is missing now (1.2.0) wrt previous (1.1.0). > Does that imply a SHARED_LIBS bump? No. ogg_opus_seek_manual wasn't public: 000782f

Re: libsndfile 1.2.0

2023-01-11 Thread Jan Stary
Ah, looking at the nm(1) diff of the previous and current linsdfile.so, the ogg_opus_seek_manual symbol is missing now (1.2.0) wrt previous (1.1.0). Does that imply a SHARED_LIBS bump? Jan On Jan 11 13:31:17, h...@stare.cz wrote: > On Jan 10 20:03:49, h...@stare.cz wrote: > > I am working

Re: libsndfile 1.2.0

2023-01-11 Thread Theo Buehler
On Wed, Jan 11, 2023 at 01:31:17PM +0100, Jan Stary wrote: > On Jan 10 20:03:49, h...@stare.cz wrote: > > I am working on an update of libsndfile to 1.2.0. > > diff below. > > Tested on current/amd64 and current/aarch64; > tested with sox (converting various formats). > Please test everywhere. >

Re: libsndfile 1.2.0

2023-01-11 Thread Jan Stary
On Jan 10 20:03:49, h...@stare.cz wrote: > I am working on an update of libsndfile to 1.2.0. diff below. Tested on current/amd64 and current/aarch64; tested with sox (converting various formats). Please test everywhere. On Jan 10 20:11:54, t...@theobuehler.org wrote: > -GH_TAGNAME=1.1.0 > +G

Re: libsndfile 1.2.0

2023-01-10 Thread Theo Buehler
On Tue, Jan 10, 2023 at 08:32:19PM +0100, Jan Stary wrote: > On Jan 10 20:11:54, t...@theobuehler.org wrote: > > On Tue, Jan 10, 2023 at 08:03:49PM +0100, Jan Stary wrote: > > > I am working on an update of libsndfile to 1.2.0. > > > > > > Sadly, I was not around for the 1.1.0 update (thank you Br

Re: libsndfile 1.2.0

2023-01-10 Thread Stuart Henderson
On 2023/01/10 20:11, Theo Buehler wrote: > > I don't think there is a disadvantage to it. It's already done. > > -GH_TAGNAME=1.1.0 > +GH_TAGNAME=1.2.0 > > make makesum > make FETCH_PACKAGES= > > and you should be ready to test (and see if you need to bump the shared > library version, e

Re: libsndfile 1.2.0

2023-01-10 Thread Jan Stary
On Jan 10 20:11:54, t...@theobuehler.org wrote: > On Tue, Jan 10, 2023 at 08:03:49PM +0100, Jan Stary wrote: > > I am working on an update of libsndfile to 1.2.0. > > > > Sadly, I was not around for the 1.1.0 update (thank you Brad), > > when apparently the decision was made to switch to the cmake

Re: libsndfile 1.2.0

2023-01-10 Thread Theo Buehler
On Tue, Jan 10, 2023 at 08:03:49PM +0100, Jan Stary wrote: > I am working on an update of libsndfile to 1.2.0. > > Sadly, I was not around for the 1.1.0 update (thank you Brad), > when apparently the decision was made to switch to the cmake build. > Is there a particular reason for that? > > Unde