Re: libsndfile 1.2.0
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 no bump is needed. /usr/src/lib/check_sym is quite handy for these things, (assuming you have the 'old' version installed) you can use it to compare the system version in /usr/local/lib with the one in the fake tree /usr/ports/pobj//fake-amd64/usr/local/lib/ and look at its output.
Re: libsndfile 1.2.0
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, not exported $ /usr/src/lib/check_sym /usr/local/lib/libsndfile.so.7.0 /usr/obj/ports/libsndfile-1.2.0/fake-amd64/usr/local/lib/libsndfile.so.7.0 /usr/local/lib/libsndfile.so.7.0 --> /usr/obj/ports/libsndfile-1.2.0/fake-amd64/usr/local/lib/libsndfile.so.7.0 No dynamic export changes
Re: libsndfile 1.2.0
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: 000782f0 t ogg_opus_seek_manual If it had been an uppercase T then this would have warranted a major bump due to symbol removal. (I verified with /usr/lib/check_sym and checked by looking at the diff that your update didn't require a bump)
Re: libsndfile 1.2.0
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 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
> > +GH_TAGNAME=1.2.0
>
> On Jan 10 19:35:22, s...@spacehopper.org wrote:
> > Though now https://github.com/libsndfile/libsndfile/issues/816 has been
> > fixed and the uploaded tar.xz should work with cmake, it may make sense
> > to switch to that instead of the on-the-fly generated tar.gz.
>
> That's what I did; it downloads the "static" tar.xz,
> but I kept the cmake build of the 1.1.0 port: it detects
> the MPEG dependencies correctly, unlike the ./configure script.
>
> Jan
>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/libsndfile/Makefile,v
> retrieving revision 1.41
> diff -u -p -r1.41 Makefile
> --- Makefile 3 Apr 2022 11:12:38 - 1.41
> +++ Makefile 11 Jan 2023 12:13:49 -
> @@ -1,11 +1,12 @@
> COMMENT= library to handle various audio file formats
>
> -GH_ACCOUNT= libsndfile
> -GH_PROJECT= libsndfile
> -GH_TAGNAME= 1.1.0
> +V= 1.2.0
> +DISTNAME=libsndfile-${V}
> +EXTRACT_SUFX=.tar.xz
> CATEGORIES= audio
>
> HOMEPAGE=https://libsndfile.github.io/libsndfile/
> +MASTER_SITES=
> https://github.com/libsndfile/libsndfile/releases/download/${V}/
>
> MAINTAINER= Jan Stary
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/audio/libsndfile/distinfo,v
> retrieving revision 1.20
> diff -u -p -r1.20 distinfo
> --- distinfo 3 Apr 2022 11:12:38 - 1.20
> +++ distinfo 11 Jan 2023 12:13:49 -
> @@ -1,2 +1,2 @@
> -SHA256 (libsndfile-1.1.0.tar.gz) =
> ZCqHa9YbY/k0ZijbpfigNWo611DH9vQgGdJs5gumoVs=
> -SIZE (libsndfile-1.1.0.tar.gz) = 684409
> +SHA256 (libsndfile-1.2.0.tar.xz) =
> DjDnBy+D3ISGPi5V8pkXXH4EpZAq55z7mdQknuj21go=
> +SIZE (libsndfile-1.2.0.tar.xz) = 730268
Re: libsndfile 1.2.0
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. > > On Jan 10 20:11:54, t...@theobuehler.org wrote: > > -GH_TAGNAME=1.1.0 > > +GH_TAGNAME=1.2.0 > > On Jan 10 19:35:22, s...@spacehopper.org wrote: > > Though now https://github.com/libsndfile/libsndfile/issues/816 has been > > fixed and the uploaded tar.xz should work with cmake, it may make sense > > to switch to that instead of the on-the-fly generated tar.gz. > > That's what I did; it downloads the "static" tar.xz, > but I kept the cmake build of the 1.1.0 port: it detects > the MPEG dependencies correctly, unlike the ./configure script. Committed, thanks.
Re: libsndfile 1.2.0
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
> +GH_TAGNAME=1.2.0
On Jan 10 19:35:22, s...@spacehopper.org wrote:
> Though now https://github.com/libsndfile/libsndfile/issues/816 has been
> fixed and the uploaded tar.xz should work with cmake, it may make sense
> to switch to that instead of the on-the-fly generated tar.gz.
That's what I did; it downloads the "static" tar.xz,
but I kept the cmake build of the 1.1.0 port: it detects
the MPEG dependencies correctly, unlike the ./configure script.
Jan
Index: Makefile
===
RCS file: /cvs/ports/audio/libsndfile/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile3 Apr 2022 11:12:38 - 1.41
+++ Makefile11 Jan 2023 12:13:49 -
@@ -1,11 +1,12 @@
COMMENT= library to handle various audio file formats
-GH_ACCOUNT=libsndfile
-GH_PROJECT=libsndfile
-GH_TAGNAME=1.1.0
+V= 1.2.0
+DISTNAME= libsndfile-${V}
+EXTRACT_SUFX= .tar.xz
CATEGORIES=audio
HOMEPAGE= https://libsndfile.github.io/libsndfile/
+MASTER_SITES= https://github.com/libsndfile/libsndfile/releases/download/${V}/
MAINTAINER=Jan Stary
Index: distinfo
===
RCS file: /cvs/ports/audio/libsndfile/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo3 Apr 2022 11:12:38 - 1.20
+++ distinfo11 Jan 2023 12:13:49 -
@@ -1,2 +1,2 @@
-SHA256 (libsndfile-1.1.0.tar.gz) = ZCqHa9YbY/k0ZijbpfigNWo611DH9vQgGdJs5gumoVs=
-SIZE (libsndfile-1.1.0.tar.gz) = 684409
+SHA256 (libsndfile-1.2.0.tar.xz) = DjDnBy+D3ISGPi5V8pkXXH4EpZAq55z7mdQknuj21go=
+SIZE (libsndfile-1.2.0.tar.xz) = 730268
Re: libsndfile 1.2.0
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 Brad), > > > when apparently the decision was made to switch to the cmake build. > > > Is there a particular reason for that? > > > > > > Under https://github.com/libsndfile/libsndfile/releases > > > they provide a tar.gz (as just a tag really) without ./configure, > > > so to use that is to pull in autoreconf and automake etc. However, > > > there is also a tar.xz which provides ./configure; I propose to switch > > > back to the gnu ./configure build, considering the archivers/xzcat > > > dependency a lesser evil than the cmake dependency. > > > > > > Are there any advantages to the cmake build? > > > > 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= > > Yes, I have that already; but I would like to get rid > of the cmake dependency, and the python dependency. Then I suggest that you finish that up, submit the update get that committed, then you can play with switching to autoconf and send a diff for that.
Re: libsndfile 1.2.0
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, etc). Though now https://github.com/libsndfile/libsndfile/issues/816 has been fixed and the uploaded tar.xz should work with cmake, it may make sense to switch to that instead of the on-the-fly generated tar.gz.
Re: libsndfile 1.2.0
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 build. > > Is there a particular reason for that? > > > > Under https://github.com/libsndfile/libsndfile/releases > > they provide a tar.gz (as just a tag really) without ./configure, > > so to use that is to pull in autoreconf and automake etc. However, > > there is also a tar.xz which provides ./configure; I propose to switch > > back to the gnu ./configure build, considering the archivers/xzcat > > dependency a lesser evil than the cmake dependency. > > > > Are there any advantages to the cmake build? > > 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= Yes, I have that already; but I would like to get rid of the cmake dependency, and the python dependency. Jan > and you should be ready to test (and see if you need to bump the shared > library version, etc). > > > Are there any objections? > > > > Jan > > >
Re: libsndfile 1.2.0
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? > > Under https://github.com/libsndfile/libsndfile/releases > they provide a tar.gz (as just a tag really) without ./configure, > so to use that is to pull in autoreconf and automake etc. However, > there is also a tar.xz which provides ./configure; I propose to switch > back to the gnu ./configure build, considering the archivers/xzcat > dependency a lesser evil than the cmake dependency. > > Are there any advantages to the cmake build? 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, etc). > Are there any objections? > > Jan >
