[ANNOUNCE] SoX 14.4.1rc3 Released

[ANNOUNCE] SoX 14.4.1rc3 Released

[Chris Bagwell]

This is the final release candidate before official release on 1013/02/01.

git tag: sox-14.4.1rc3

Chris Bagwell (1):
      rc3 right before final release

Pascal Giard (4):
      "make distclean" should not get rid of the files distributed in the tarball; text files are deleted with the maintainer-clean target.
      Sync' with latest Debian uploads plus few updates toward the next upload.
      Fixed tarball name to match version from configure.ac.
      More Debian packaging changes, these are more interesting, some highlights:

Ulrich Klauer (2):
      Update documentation dates
      Use binary mode for pipes on all Windows compilers


http://sourceforge.net/projects/sox/files/release_candidates/sox/14.4.1rc3/sox-14.4.1rc3-macosx.zip/download

MD5:  0f17fd1e994db4a037bd4d6e7a7f9287  sox-14.4.1rc3-macosx.zip
SHA1: 60f77b75f518393350db015b231d29bab91be098  sox-14.4.1rc3-macosx.zip

http://sourceforge.net/projects/sox/files/release_candidates/sox/14.4.1rc3/sox-14.4.1rc3-win32.exe/download

MD5:  81de19cc3facbaa90e658b5bf58443eb  sox-14.4.1rc3-win32.exe
SHA1: 8aad426d6ad9a81748397601a308817ef0ca4a27  sox-14.4.1rc3-win32.exe

http://sourceforge.net/projects/sox/files/release_candidates/sox/14.4.1rc3/sox-14.4.1rc3-win32.zip/download

MD5:  b463104a3866ad65707c9d0df2143f09  sox-14.4.1rc3-win32.zip
SHA1: 17f0a4f18d312869c12ae05c2536efabaca9f479  sox-14.4.1rc3-win32.zip

http://sourceforge.net/projects/sox/files/release_candidates/sox/14.4.1rc3/sox-14.4.1rc3.tar.bz2/download

MD5:  8217dd91bec20caec0930aeaa2e3585d  sox-14.4.1rc3.tar.bz2
SHA1: 6d6f6987ddfc135088a9c76dfe877d1c35ad74af  sox-14.4.1rc3.tar.bz2

http://sourceforge.net/projects/sox/files/release_candidates/sox/14.4.1rc3/sox-14.4.1rc3.tar.gz/download

MD5:  9f725556525f9041d59913cbce1bdcb8  sox-14.4.1rc3.tar.gz
SHA1: 97524cce5d9b0f86e575d7af1d40a8e4789710a2  sox-14.4.1rc3.tar.gz


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

Hi Chris!

On Tue, Jan 29, 2013 at 10:00 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> This is the final release candidate before official release on 1013/02/01.
>
> git tag: sox-14.4.1rc3
[...]
>
> Pascal Giard (4):
>       "make distclean" should not get rid of the files distributed in the tarball; text files are deleted with the maintainer-clean target.
>       Sync' with latest Debian uploads plus few updates toward the next upload.
>       Fixed tarball name to match version from configure.ac.
>       More Debian packaging changes, these are more interesting, some highlights:

Hmmm... I guess you automated the process to generate that changelog?

Only that first change should be listed there. The rest only concerns
the Debian packaging files and thus should not be "shown" in the
upstream changelog. In fact, those last three concern the debian/
directory which is not (and should not) be part of the upstream
release tarballs.

(Some advocate that the Debian packaging files should not even be in
the same VCS as the upstream code; that they should have their own
seperate VCS to provide a clear separation with upstream. I'm not that
dogmatic. There are pros and cons to both alternatives).

Coming back to the above changelog announcing rc3, if it's
autogenerated, do you have a mean to easily improve it?
How is it done? You're simply parsing "git log"?

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Ulrich Klauer]

Chris Bagwell <chris@cnpbagwell.com>:

> This is the final release candidate before official release on 1013/02/01.

I fixed another bug, in compand/mcompand; quite nasty, but probably  
not hit very often. If you think it was too late, you could branch off  
a release branch at rc3 and release from that instead of dot:
   git checkout -b release sox-14.4.1rc3
I'll take care of merging everything into master after release. :)

Pascal Giard <evilynux@gmail.com>:

> Coming back to the above changelog announcing rc3, if it's
> autogenerated, do you have a mean to easily improve it?
> How is it done? You're simply parsing "git log"?

See lines 211 to 221 in release.sh. Essentially, it is:
   git log --no-merges sox-14.4.1rc2..sox-14.4.1rc3 | git shortlog
Note, however, that for "real" (non-rc) releases, the script will use  
the contents of NEWS. (Oh, I guess that needs updating before Friday  
...) There are more imperfections with the git-shortlog solution (all  
those "Update changelog" commits :-)), but I think it is OK for  
release candidates and conveys an idea of what's been done.

Ulrich


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Chris Bagwell]

[-- Attachment #1.1: Type: text/plain, Size: 1827 bytes --]

On Wed, Jan 30, 2013 at 3:13 PM, Ulrich Klauer <ulrich@chirlu.de> wrote:

> Chris Bagwell <chris@cnpbagwell.com>:
>
> > This is the final release candidate before official release on
> 1013/02/01.
>
> I fixed another bug, in compand/mcompand; quite nasty, but probably
> not hit very often. If you think it was too late, you could branch off
> a release branch at rc3 and release from that instead of dot:
>    git checkout -b release sox-14.4.1rc3
> I'll take care of merging everything into master after release. :)
>
>
I think it should be fine to include.


> Pascal Giard <evilynux@gmail.com>:
>
> > Coming back to the above changelog announcing rc3, if it's
> > autogenerated, do you have a mean to easily improve it?
> > How is it done? You're simply parsing "git log"?
>
> See lines 211 to 221 in release.sh. Essentially, it is:
>    git log --no-merges sox-14.4.1rc2..sox-14.4.1rc3 | git shortlog
> Note, however, that for "real" (non-rc) releases, the script will use
> the contents of NEWS. (Oh, I guess that needs updating before Friday
> ...) There are more imperfections with the git-shortlog solution (all
> those "Update changelog" commits :-)), but I think it is OK for
> release candidates and conveys an idea of what's been done.


Are you up for updating NEWS before real release?  If not, I'll do it but
probably will be closer to filtered shortlog than in past.

Chris


>
> Ulrich
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> SoX-devel mailing list
> SoX-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3106 bytes --]

[-- Attachment #2: Type: text/plain, Size: 238 bytes --]

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

Hi guys,

On Wed, Jan 30, 2013 at 7:45 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>
>
>
> On Wed, Jan 30, 2013 at 3:13 PM, Ulrich Klauer <ulrich@chirlu.de> wrote:
>>
>> Chris Bagwell <chris@cnpbagwell.com>:
>>
>> > This is the final release candidate before official release on
>> > 1013/02/01.

Year 1013? I will assume 2013 ;-p

Seriously though, still about Debian packaging and proper shared
library handling.

For 14.4.1, I intend to switch from shlibs to the newly introduced
symbol mechanism for shared library packaging.

While shlib was pretty coarse, a shared library either kept the same
ABI or it was broken, symbol file(s) offer fine grained control.

That being said, it would help me if you could tell me if a new symbol
was introduced or an existing one modified in 14.4.1.
See [1] for details on what constitutes an ABI change.

I don't know if I can automate that verification, I would assume there
must be a way to at least partly automate this. Otherwise maintaining
big unstable shared libraries would be a nightmare.

Cheers,

-Pascal
[1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

On Wed, Jan 30, 2013 at 9:52 PM, Pascal Giard <evilynux@gmail.com> wrote:
> That being said, it would help me if you could tell me if a new symbol
> was introduced or an existing one modified in 14.4.1.
> See [1] for details on what constitutes an ABI change.
>
> I don't know if I can automate that verification, I would assume there
> must be a way to at least partly automate this. Otherwise maintaining
> big unstable shared libraries would be a nightmare.
>
> Cheers,
>
> -Pascal
> [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates

Answering to my own email, dpkg-gensymbols is the tool to use for symbols.
Unless I'm not using it properly, there is no symbol change introduced
in 14.4.1.

However, that doesn't necessarily mean that 14.4.1 is binary
compatible with 14.4.0.
Some changes can not be catched by checking symbols e.g. a struct that
changed size.

Do you know if there has been a change that could break binary compatibility?

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Chris Bagwell]

[-- Attachment #1.1: Type: text/plain, Size: 1510 bytes --]

On Wed, Jan 30, 2013 at 9:24 PM, Pascal Giard <evilynux@gmail.com> wrote:

> On Wed, Jan 30, 2013 at 9:52 PM, Pascal Giard <evilynux@gmail.com> wrote:
> > That being said, it would help me if you could tell me if a new symbol
> > was introduced or an existing one modified in 14.4.1.
> > See [1] for details on what constitutes an ABI change.
> >
> > I don't know if I can automate that verification, I would assume there
> > must be a way to at least partly automate this. Otherwise maintaining
> > big unstable shared libraries would be a nightmare.
> >
> > Cheers,
> >
> > -Pascal
> > [1]
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates
>
> Answering to my own email, dpkg-gensymbols is the tool to use for symbols.
> Unless I'm not using it properly, there is no symbol change introduced
> in 14.4.1.
>
> However, that doesn't necessarily mean that 14.4.1 is binary
> compatible with 14.4.0.
> Some changes can not be catched by checking symbols e.g. a struct that
> changed size.
>
> Do you know if there has been a change that could break binary
> compatibility?
>
> Cheers,
>


For SoX, you should be able to get an idea of API and ABI modifications
using "git log -u src/sox.h" since that defines our interface to library.
That shows no modifications in dot branch since 14.4.0 release.

I'll have to read up on this new approach.  Is it OK to ignore API/ABI
changes related to internal-only symbols that we are allowing to leak out
(those prefixed with lsx_)?

Chris

[-- Attachment #1.2: Type: text/html, Size: 2196 bytes --]

[-- Attachment #2: Type: text/plain, Size: 238 bytes --]

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

On Wed, Jan 30, 2013 at 10:30 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> For SoX, you should be able to get an idea of API and ABI modifications
> using "git log -u src/sox.h" since that defines our interface to library.
> That shows no modifications in dot branch since 14.4.0 release.

Good!

> I'll have to read up on this new approach.  Is it OK to ignore API/ABI
> changes related to internal-only symbols that we are allowing to leak out
> (those prefixed with lsx_)?

Hmm... are we suggesting users to make use of them in some cases?
Or we're discouraging that practice?

The initial project description that ended up creating those symbol
file mechanism does mention the case of libraries exposing private
symbols. It's considered noise and thus I would assume the maintainer
is expected to remove those symbols from the symbol file. That has the
consequence of having untracked symbols and thus, if applications uses
them, things will break and they'll be on their own.

In any case, why are we "leaking" them? I see there are lots of them,
they actually constitute the vast majority of symbols! (340/393).

I'm still not very experienced with shared library packaging. If I get
stuck, I may very well ask for advice on the debian-devel ML. More
experienced Debian devs/maintainers may shed some light.

Related to packaging changes I made recently and that will be
introduced in 14.4.1/14.4.2, it may also benefit SoX outside Debian to
build hardened binaries (see [1]). AFAIU, when gcc is used, it's only
a matter of adding some build flags e.g. "-D_FORTIFY_SOURCE=2",
"-fstack-protector --param ssp-buffer-size=4", etc.

Cheers,

-Pascal
[1] http://wiki.debian.org/Hardening
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Ulrich Klauer]

Chris Bagwell <chris@cnpbagwell.com>:

> Are you up for updating NEWS before real release?  If not, I'll do it but
> probably will be closer to filtered shortlog than in past.

Just pushed a draft. The list is a bit short, but I think those are  
the fixes that are most likely to be noticeable for more than a  
handful of users.

The links at the end will start to work as soon as there is a  
"sox-14.4.1" tag. To test them now, just replace this part of the URL  
with ...rc3 or something.

Ulrich


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Ulrich Klauer]

Pascal Giard <evilynux@gmail.com>:

> On Wed, Jan 30, 2013 at 10:30 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> > For SoX, you should be able to get an idea of API and ABI modifications
> > using "git log -u src/sox.h" since that defines our interface to library.
> > That shows no modifications in dot branch since 14.4.0 release.
> Good!

This was part of the plan for dot. :-)  However, reading section 8.6.2  
of the Policy Manual, I wonder where the difference is between a  
library_do_operation() taking an enum and a sox_find_effect() or  
sox_effect_options() taking a string. Wouldn't that mean that it is  
considered an "ABI change" whenever an effect changes behaviour (e.g.,  
due to a bug being fixed)?

> > I'll have to read up on this new approach.  Is it OK to ignore API/ABI
> > changes related to internal-only symbols that we are allowing to leak out
> > (those prefixed with lsx_)?
> Hmm... are we suggesting users to make use of them in some cases?
> Or we're discouraging that practice?

The latter, I think. This is what sox.h says about it at the moment:
> Symbols starting with "lsx_" or "LSX_" are internal use by libSoX  
> and plugins. LSX_ and lsx_ symbols should not be used by  
> libSoX-based applications.

> In any case, why are we "leaking" them? I see there are lots of them,
> they actually constitute the vast majority of symbols! (340/393).

I'm not sure, but since the library is divided into many compilation  
units, we can't simply declare all of those functions static. That  
would mean a helper function from effects_i.c couldn't be used from  
within spectrogram.c anymore. So removing these symbols would have to  
happen at or after linking; I don't know how complicated or easy that  
is.

Ulrich


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

On Thu, Jan 31, 2013 at 10:24 PM, Ulrich Klauer <ulrich@chirlu.de> wrote:
> Pascal Giard <evilynux@gmail.com>:
>
>> On Wed, Jan 30, 2013 at 10:30 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>> > For SoX, you should be able to get an idea of API and ABI modifications
>> > using "git log -u src/sox.h" since that defines our interface to library.
>> > That shows no modifications in dot branch since 14.4.0 release.
>> Good!
>
> This was part of the plan for dot. :-)  However, reading section 8.6.2
> of the Policy Manual, I wonder where the difference is between a
> library_do_operation() taking an enum and a sox_find_effect() or
> sox_effect_options() taking a string. Wouldn't that mean that it is
> considered an "ABI change" whenever an effect changes behaviour (e.g.,
> due to a bug being fixed)?

I think the answer is "it depends". I think it could constitute a
modification as defined in section 8.6.2.
Could you elaborate on the modifications you have in mind that could
constitute a modification please?
Based on your judgement, do you think an application using libsox2
could reasonably depend on the previous behavior?

>> > I'll have to read up on this new approach.  Is it OK to ignore API/ABI
>> > changes related to internal-only symbols that we are allowing to leak out
>> > (those prefixed with lsx_)?
>> Hmm... are we suggesting users to make use of them in some cases?
>> Or we're discouraging that practice?
>
> The latter, I think. This is what sox.h says about it at the moment:
>> Symbols starting with "lsx_" or "LSX_" are internal use by libSoX
>> and plugins. LSX_ and lsx_ symbols should not be used by
>> libSoX-based applications.

Fair enough. I feel confortable ignoring lsx_* symbol and ditching
them from the autogenerated symbol files.
If an app author complains that its applications breaks in connection
to an lsx_* symbol having changed, we'll be free to handle the matter
as gentleman e.g.
1) Access whether he/she holds a valid use case for that lsx_* symbol;
2) Consider moving it in sox_*;
3) Include that change in a dot release (as it's an addition, not a
modif or removal)?

>> In any case, why are we "leaking" them? I see there are lots of them,
>> they actually constitute the vast majority of symbols! (340/393).
>
> I'm not sure, but since the library is divided into many compilation
> units, we can't simply declare all of those functions static. That
> would mean a helper function from effects_i.c couldn't be used from
> within spectrogram.c anymore. So removing these symbols would have to
> happen at or after linking; I don't know how complicated or easy that
> is.

I'm not competent enough in the matter to give my opinion on this.
However, I see that it's not unusual to leak private symbols so I can
live with it.

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Ulrich Klauer]

Pascal Giard <evilynux@gmail.com>:

> Could you elaborate on the modifications you have in mind that could 
> constitute a modification please?
> Based on your judgement, do you think an application using libsox2
> could reasonably depend on the previous behavior?

That would mean a change that is not backward compatible? Probably not. But in the other direction, a client might want/need to ensure that the library it uses can read 64-bit WAVs, or doesn't crash when resampling very long audio streams, etc.

Actually, upon thinking about it again, it appears that this symbol-specific version behaves like the second part of SHLIB_VERSION and should be increased whenever there are any changes in functionality at all. The question is just, in our case where there are lots of format handlers and effects that are accessed via a few common functions: Won't it be necessary to always increase more or less every symbol's version at the same time? If so, the finer granularity is only theoretical.

Ulrich

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan

Re: [ANNOUNCE] SoX 14.4.1rc3 Released

[Pascal Giard]

On Fri, Feb 1, 2013 at 7:40 PM, Ulrich Klauer <ulrich@chirlu.de> wrote:
> Pascal Giard <evilynux@gmail.com>:
>
>> Could you elaborate on the modifications you have in mind that could
>> constitute a modification please?
>> Based on your judgement, do you think an application using libsox2
>> could reasonably depend on the previous behavior?
>
> That would mean a change that is not backward compatible? Probably not. But in the other direction, a client might want/need to ensure that the library it uses can read 64-bit WAVs, or doesn't crash when resampling very long audio streams, etc.

In that case they should make sure they depend on the proper package
version, not rely on the shlib or symbol mechanism.

> Actually, upon thinking about it again, it appears that this symbol-specific version behaves like the second part of SHLIB_VERSION and should be increased whenever there are any changes in functionality at all. The question is just, in our case where there are lots of format handlers and effects that are accessed via a few common functions: Won't it be necessary to always increase more or less every symbol's version at the same time? If so, the finer granularity is only theoretical.

I'm afraid SoX may constitute a corner case. I'll ask for advice, I
can't seem to figure how to handle this properly. In any case it seems
the symbol files will eventually become mandatory.

-Pascal
-- 
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb