> On 18 Mar 2015, at 6:11pm, René J.V. Bertin wrote:
>
> On Wednesday March 18 2015 13:52:49 Arno Hautala wrote:
>
>> Cool. I wonder if there's still an issue of sometimes using internal
>> versions and sometimes using MacPorts, but as the internal versions
>> aren't available yet, it seems lik
> On 18 Mar 2015, at 5:52pm, Arno Hautala wrote:
>
> On Wed, Mar 18, 2015 at 1:20 PM, René J.V. wrote:
>> On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:
>>
>> So, no, there should be no fear of non-reproducible builds, at least not if
>> I got in all the dependencies :)
>>
>>> Regar
On Wednesday March 18 2015 13:52:49 Arno Hautala wrote:
> Cool. I wonder if there's still an issue of sometimes using internal
> versions and sometimes using MacPorts, but as the internal versions
> aren't available yet, it seems like a minor issue if any. My internal
When trace mode becomes the
On Wed, Mar 18, 2015 at 1:20 PM, René J.V. wrote:
> On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:
>
> So, no, there should be no fear of non-reproducible builds, at least not if I
> got in all the dependencies :)
>
>> Regardless, I'd think the configure would still need to be set up to
On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:
> features should be disabled until they are available in MacPorts. Or,
> by "local version" do you mean part of the Audacity source tree?
Yes. They call that local, I just used their terminology.
So, no, there should be no fear of non-repro
On Wed, Mar 18, 2015 at 8:54 AM, René J.V. wrote:
> There
> are a few required components which are not in MacPorts and for which a
> local version is used: libsms, libsoxr, libvamp, portsmf and widgetextra.
> Audacity's configure script will detect and use the "system" versions when
> availab
For anyone interested in this kind of application: I just submitted a port for
audacity.
R.
-- Forwarded Message --
Subject: [MacPorts] #47189: submission: audacity
Date: Wednesday March 18 2015, 11:01:17
From: MacPorts
To: rjvber...@gmail.com, macports-tick