Thread: [Audacity-devel] Audacity 2.0.2
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <vjo...@cs...> - 2012-07-11 00:03:04
|
We've decided on a very quick release cycle for Audacity 2.0.2. Currently targeting August 1 for string/code freeze. I'm Release Manager. Thanks, Vaughan |
From: Vaughan J. <va...@au...> - 2012-07-11 00:12:30
|
We've decided on a very quick release cycle for Audacity 2.0.2. Currently targeting August 1 for string/code freeze. I'm Release Manager. Thanks, Vaughan |
From: Benjamin D. <bd...@ub...> - 2012-07-13 22:11:32
Attachments:
signature.asc
|
Am Dienstag, den 10.07.2012, 16:54 -0700 schrieb Vaughan Johnson: > We've decided on a very quick release cycle for Audacity 2.0.2. > Currently targeting August 1 for string/code freeze. I'm Release Manager. Can we get the two remaining Debian patches [1,2] discussed before the freeze? [1] http://bugzilla.audacityteam.org/show_bug.cgi?id=233 [2] http://bugzilla.audacityteam.org/show_bug.cgi?id=483 -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2012-07-16 23:19:40
|
On 7/13/2012 3:11 PM, Benjamin Drung wrote: > Am Dienstag, den 10.07.2012, 16:54 -0700 schrieb Vaughan Johnson: >> We've decided on a very quick release cycle for Audacity 2.0.2. >> Currently targeting August 1 for string/code freeze. I'm Release Manager. > > Can we get the two remaining Debian patches [1,2] discussed before the > freeze? > > [1] http://bugzilla.audacityteam.org/show_bug.cgi?id=233 (other thread) > [2] http://bugzilla.audacityteam.org/show_bug.cgi?id=483 > Looks to me it's still not agreed on, and has an open question in comment 22. - V |
From: David T. <dt...@ii...> - 2012-07-14 03:10:27
|
On 14/07/12 08:11, Benjamin Drung wrote: > Can we get the two remaining Debian patches [1,2] discussed before the > freeze? > > [1] http://bugzilla.audacityteam.org/show_bug.cgi?id=233 "Option to link against system lame and ffmpeg" Hi Ben, with regard to patch: http://bugzilla.audacityteam.org/show_bug.cgi?id=233#c27 In the last hunk for src/FFmpeg.cpp and the first hunk for src/FFmpeg.h, this seems to be a ffmpeg version compatibility change. Would it be better to be independent of the rest of the patch ? With regard to system lame/ffmpeg, the compile options already give us this capability, don't they ? In Fedora proper, neither ffmpeg nor lame (mp3 decoding/encoding) will be available. Currently I build it independently for RPM Fusion (the add-on software repository for Fedora), with the extra ffmpeg/lame -devel packages present, set the compile flags, and define a conflict in rpm packaging to indicate that only one of either audacity or audacity-freeworld (with ffmpeg/mp3) can be installed at once. In an ideal world, I would not have to have the second audacity-freeworld package; I would build it in Fedora, and at runtime, audacity would detect and use the ffmpeg/mp3 libraries if they are available. I do not think I can do this at the moment, because currently the audacity compile is against the header (-devel) files from the ffmpeg/lame packages, and these will never be available on a pure Fedora linux system. My understanding is being able to dlopen the libraries goes some way toward making this possible, but I don't actually understand what this patch is doing, while it appears that it is actually removing this capability ? Can you help me to understand the intent of the patch ? |
From: Benjamin D. <bd...@ub...> - 2012-07-14 16:08:16
Attachments:
signature.asc
|
Am Samstag, den 14.07.2012, 13:10 +1000 schrieb David Timms: > On 14/07/12 08:11, Benjamin Drung wrote: > > Can we get the two remaining Debian patches [1,2] discussed before the > > freeze? > > > > [1] http://bugzilla.audacityteam.org/show_bug.cgi?id=233 > "Option to link against system lame and ffmpeg" > > Hi Ben, with regard to patch: > http://bugzilla.audacityteam.org/show_bug.cgi?id=233#c27 > > In the last hunk for src/FFmpeg.cpp and the first hunk for src/FFmpeg.h, > this seems to be a ffmpeg version compatibility change. Would it be > better to be independent of the rest of the patch ? I have split the patch into two parts. > With regard to system lame/ffmpeg, the compile options already give us > this capability, don't they ? No, they just give us the option to use the system header files. > In Fedora proper, neither ffmpeg nor lame (mp3 decoding/encoding) will > be available. Currently I build it independently for RPM Fusion (the > add-on software repository for Fedora), with the extra ffmpeg/lame > -devel packages present, set the compile flags, and define a conflict in > rpm packaging to indicate that only one of either audacity or > audacity-freeworld (with ffmpeg/mp3) can be installed at once. > > In an ideal world, I would not have to have the second > audacity-freeworld package; I would build it in Fedora, and at runtime, > audacity would detect and use the ffmpeg/mp3 libraries if they are > available. I do not think I can do this at the moment, because currently > the audacity compile is against the header (-devel) files from the > ffmpeg/lame packages, and these will never be available on a pure Fedora > linux system. My understanding is being able to dlopen the libraries > goes some way toward making this possible, but I don't actually > understand what this patch is doing, while it appears that it is > actually removing this capability ? Yes. My patch adds a configure option to remove the possibility to dlopen FFmpeg/lame. You seem to want to go in the other direction: You want to build audacity without the FFmpeg/lame libraries, but have the option to dlopen the libraries on runtime. This should be already doable by using the headers from lib-src/ffmpeg/. > Can you help me to understand the intent of the patch ? The patch adds a configure option to disable dlopen libraries. Nothing will change unless --disable-dynamic-loading is specified when running configure. Calling configure with --disable-dynamic-loading will dynamic link FFmpeg/lame. In this case you need the FFmpeg and lame libraries to run Audacity. In Debian and Ubuntu, libav (the fork on FFmpeg) and lame are available. The Audacity package is built with --disable-dynamic-loading and the package depends on the libav and lame library packages. The package building tools are creating those dependencies due to the dynamic linking of audacity against these libraries. -- Benjamin Drung Debian & Ubuntu Developer |
From: David T. <dt...@ii...> - 2012-07-15 12:15:41
|
On 15/07/12 02:08, Benjamin Drung wrote: > I have split the patch into two parts. Cool, might make it easier to get accepted. > You seem to want to go in the other direction: You want to build > audacity without the FFmpeg/lame libraries, but have the option to > dlopen the libraries on runtime. This should be already doable by using > the headers from lib-src/ffmpeg/. I didn't know that would work. But, wouldn't the user need to have the matching version of ffmpeg installed, that the audacity/ffmpeg/header is ? > Calling configure with --disable-dynamic-loading will dynamic > link FFmpeg/lame. In this case you need the FFmpeg and lame libraries to > run Audacity. OK. So with the option set, Audacity will fail to start at all ? > In Debian and Ubuntu, libav (the fork on FFmpeg) and lame are available. > The Audacity package is built with --disable-dynamic-loading and the > package depends on the libav and lame library packages. The package > building tools are creating those dependencies due to the dynamic > linking of audacity against these libraries. Is this so that users can choose to not have ffmpeg/mp3 installed (eg a suggests rather than a requirement) within the deb world ? I'm going to give both patches a run. |
From: Benjamin D. <bd...@ub...> - 2012-07-17 09:35:24
Attachments:
signature.asc
|
Am Sonntag, den 15.07.2012, 22:15 +1000 schrieb David Timms: > > You seem to want to go in the other direction: You want to build > > audacity without the FFmpeg/lame libraries, but have the option to > > dlopen the libraries on runtime. This should be already doable by using > > the headers from lib-src/ffmpeg/. > I didn't know that would work. But, wouldn't the user need to have the > matching version of ffmpeg installed, that the audacity/ffmpeg/header is ? It doesn't need to be the same, but it needs to be a compatible one (FFmpeg 0.6 up to FFmpeg 0.8?). You need to test the binary to detect incompatibilities. -- Benjamin Drung Debian & Ubuntu Developer |
From: Richard A. <ri...@au...> - 2012-07-15 15:46:14
|
On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: > > You seem to want to go in the other direction: You want to build > > audacity without the FFmpeg/lame libraries, but have the option to > > dlopen the libraries on runtime. This should be already doable by using > > the headers from lib-src/ffmpeg/. > I didn't know that would work. But, wouldn't the user need to have the > matching version of ffmpeg installed, that the audacity/ffmpeg/header is ? > > > Calling configure with --disable-dynamic-loading will dynamic > > link FFmpeg/lame. In this case you need the FFmpeg and lame libraries to > > run Audacity. > OK. So with the option set, Audacity will fail to start at all ? Yes, because it puts dynamic linkage into the ELF header, and ld.so will fail to resolve that linkage. > > > In Debian and Ubuntu, libav (the fork on FFmpeg) and lame are available. > > The Audacity package is built with --disable-dynamic-loading and the > > package depends on the libav and lame library packages. The package > > building tools are creating those dependencies due to the dynamic > > linking of audacity against these libraries. > Is this so that users can choose to not have ffmpeg/mp3 installed (eg a > suggests rather than a requirement) within the deb world ? The result of Benjamin's patches is that users _loose_ the facility to choose not having LAME or FFmpeg - Audacity acquires these as hard dependencies. Ubuntu favours this route seemingly on the basis that a hard failure is easier to deal with automatically than a run-time error presented to the user. One of the reasons these patches haven't just been applied is that I don't like the support implications for audacity of yet more configure script options (to test and support) and of Linux builds being linked differently depending on compile time options (which users won't known in most cases). Finally, the reason the patch for newer ffmpeg isn't going in is the same as the reason the one for ffmpeg 0.10 from Gentoo isn't going in- they are or are likely to break compatibility with the ffmpeg 0.6.2 binaries for windows we are supplying. Until we have newer binary builds for those two available and tested, we can't break those platforms. Richard |
From: Vaughan J. <va...@au...> - 2012-07-16 23:16:42
|
On 7/15/2012 8:46 AM, Richard Ash wrote: > On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: >>> [...] > The result of Benjamin's patches is that users _loose_ the facility to > choose not having LAME or FFmpeg - Audacity acquires these as hard > dependencies. That borders on license violation, I think. Or at least, over-affiliates us with LAME and FFmpeg. We *want* users to have to do something extra to get LAME or FFmpeg, so it's their choice, not ours. I think that puts bug 233 as a WONT_FIX, unless I hear otherwise. - Vaughan |
From: Benjamin D. <bd...@ub...> - 2012-07-17 09:53:36
Attachments:
signature.asc
|
Am Montag, den 16.07.2012, 16:21 -0700 schrieb Vaughan Johnson: > On 7/15/2012 8:46 AM, Richard Ash wrote: > > On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: > >>> [...] > > The result of Benjamin's patches is that users _loose_ the facility to > > choose not having LAME or FFmpeg - Audacity acquires these as hard > > dependencies. > > That borders on license violation, I think. Or at least, over-affiliates > us with LAME and FFmpeg. We *want* users to have to do something extra > to get LAME or FFmpeg, so it's their choice, not ours. Why does linking to (L)GPL libraries border a license violation? You use many GPL and LGPL libraries already. Do you fear a patent violation instead? Then you do not have to worry, because the patch only affects your source tarball distribution, but not your binary distribution. -- Benjamin Drung Debian & Ubuntu Developer |
From: Steve t. F. <ste...@gm...> - 2012-07-17 14:32:11
|
On 17 July 2012 10:53, Benjamin Drung <bd...@ub...> wrote: > Am Montag, den 16.07.2012, 16:21 -0700 schrieb Vaughan Johnson: >> On 7/15/2012 8:46 AM, Richard Ash wrote: >> > On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: >> >>> [...] >> > The result of Benjamin's patches is that users _loose_ the facility to >> > choose not having LAME or FFmpeg - Audacity acquires these as hard >> > dependencies. >> >> That borders on license violation, I think. Or at least, over-affiliates >> us with LAME and FFmpeg. We *want* users to have to do something extra >> to get LAME or FFmpeg, so it's their choice, not ours. > > Why does linking to (L)GPL libraries border a license violation? You use > many GPL and LGPL libraries already. > > Do you fear a patent violation instead? Then you do not have to worry, > because the patch only affects your source tarball distribution, but not > your binary distribution. What effect would that that have on other Linux distributions that take a more cautious line on patent/licensing issues? Would it prevent them from including Audacity in their main repositories? Steve > > -- > Benjamin Drung > Debian & Ubuntu Developer > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Benjamin D. <bd...@ub...> - 2012-07-17 15:46:58
Attachments:
signature.asc
|
Am Dienstag, den 17.07.2012, 15:32 +0100 schrieb Steve the Fiddle: > On 17 July 2012 10:53, Benjamin Drung <bd...@ub...> wrote: > > Am Montag, den 16.07.2012, 16:21 -0700 schrieb Vaughan Johnson: > >> On 7/15/2012 8:46 AM, Richard Ash wrote: > >> > On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: > >> >>> [...] > >> > The result of Benjamin's patches is that users _loose_ the facility to > >> > choose not having LAME or FFmpeg - Audacity acquires these as hard > >> > dependencies. > >> > >> That borders on license violation, I think. Or at least, over-affiliates > >> us with LAME and FFmpeg. We *want* users to have to do something extra > >> to get LAME or FFmpeg, so it's their choice, not ours. > > > > Why does linking to (L)GPL libraries border a license violation? You use > > many GPL and LGPL libraries already. > > > > Do you fear a patent violation instead? Then you do not have to worry, > > because the patch only affects your source tarball distribution, but not > > your binary distribution. > > What effect would that that have on other Linux distributions that > take a more cautious line on patent/licensing issues? Would it prevent > them from including Audacity in their main repositories? It would have no effect, because the distributions can decide on compile time what kind of linkage they want. Nothing will change with the patch unless --disable-dynamic-loading is passed to configure. -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2012-07-25 00:53:03
|
On 7/17/2012 8:46 AM, Benjamin Drung wrote: > Am Dienstag, den 17.07.2012, 15:32 +0100 schrieb Steve the Fiddle: >> On 17 July 2012 10:53, Benjamin Drung <bd...@ub...> wrote: >>> Am Montag, den 16.07.2012, 16:21 -0700 schrieb Vaughan Johnson: >>>> On 7/15/2012 8:46 AM, Richard Ash wrote: >>>>> On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: >>>>>>> [...] >>>>> The result of Benjamin's patches is that users _loose_ the facility to >>>>> choose not having LAME or FFmpeg - Audacity acquires these as hard >>>>> dependencies. >>>> >>>> That borders on license violation, I think. Or at least, over-affiliates >>>> us with LAME and FFmpeg. We *want* users to have to do something extra >>>> to get LAME or FFmpeg, so it's their choice, not ours. >>> >>> Why does linking to (L)GPL libraries border a license violation? You use >>> many GPL and LGPL libraries already. >>> >>> Do you fear a patent violation instead? Yes, thanks. >>>Then you do not have to worry, >>> because the patch only affects your source tarball distribution, but not >>> your binary distribution. I don't know the law on that. Can anybody else confirm? >> >> What effect would that that have on other Linux distributions that >> take a more cautious line on patent/licensing issues? Would it prevent >> them from including Audacity in their main repositories? > > It would have no effect, because the distributions can decide on compile > time what kind of linkage they want. Nothing will change with the patch > unless --disable-dynamic-loading is passed to configure. > Likewise, more comments on this point, please. Thanks, Vaughan |
From: Benjamin D. <bd...@ub...> - 2012-07-26 11:58:48
Attachments:
signature.asc
|
Am Dienstag, den 24.07.2012, 17:57 -0700 schrieb Vaughan Johnson: > On 7/17/2012 8:46 AM, Benjamin Drung wrote: > > Am Dienstag, den 17.07.2012, 15:32 +0100 schrieb Steve the Fiddle: > >> On 17 July 2012 10:53, Benjamin Drung <bd...@ub...> wrote: > >>> Am Montag, den 16.07.2012, 16:21 -0700 schrieb Vaughan Johnson: > >>>> On 7/15/2012 8:46 AM, Richard Ash wrote: > >>>>> On Sun, 2012-07-15 at 22:15 +1000, David Timms wrote: > >>>>>>> [...] > >>>>> The result of Benjamin's patches is that users _loose_ the facility to > >>>>> choose not having LAME or FFmpeg - Audacity acquires these as hard > >>>>> dependencies. > >>>> > >>>> That borders on license violation, I think. Or at least, over-affiliates > >>>> us with LAME and FFmpeg. We *want* users to have to do something extra > >>>> to get LAME or FFmpeg, so it's their choice, not ours. > >>> > >>> Why does linking to (L)GPL libraries border a license violation? You use > >>> many GPL and LGPL libraries already. > >>> > >>> Do you fear a patent violation instead? > > Yes, thanks. > > > >>>Then you do not have to worry, > >>> because the patch only affects your source tarball distribution, but not > >>> your binary distribution. > > I don't know the law on that. Can anybody else confirm? IANAL, but distributing source code seems to be safe. LAME, FFmpeg, x264 are all distributed in source code form for a long time and I am not aware of lawsuit against them. You can't judge, if a users who compiles your source code violate a patent. They could have a license that allows it. Your Windows and Mac binaries are not affected by the patch. > >> What effect would that that have on other Linux distributions that > >> take a more cautious line on patent/licensing issues? Would it prevent > >> them from including Audacity in their main repositories? > > > > It would have no effect, because the distributions can decide on compile > > time what kind of linkage they want. Nothing will change with the patch > > unless --disable-dynamic-loading is passed to configure. > > > > Likewise, more comments on this point, please. Here's what Debian says to this topic: http://www.debian.org/reports/patent-faq -- Benjamin Drung Debian & Ubuntu Developer |
From: Gale A. <ga...@au...> - 2012-07-29 04:21:51
|
A practical rather than legal question - IIRC the patches that Debian use remove the Libraries section of Preferences. If that is still the case, what happens when we re-introduce FFmpeg On-Demand, which has a checkbox in Libraries Preferences? Gale |
From: Benjamin D. <bd...@ub...> - 2012-07-30 23:05:26
Attachments:
signature.asc
|
Am Sonntag, den 29.07.2012, 05:21 +0100 schrieb Gale Andrews: > A practical rather than legal question - IIRC the patches that > Debian use remove the Libraries section of Preferences. Yes. > If that is still the case, what happens when we re-introduce > FFmpeg On-Demand, which has a checkbox in Libraries > Preferences? We either could get the Libraries section back with just this checkbox or we could move the checkbox somewhere else (for example to the Import / Export section). -- Benjamin Drung Debian & Ubuntu Developer |