Signed jc10 Portable Settings dmg

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Signed jc10 Portable Settings dmg

James Crook
I've just shared a jc10 signed alpha with relevant people.

This fixes the 2 Nyquist problems.  Nyquist effects now appear and can
be used, and there aren't redundant Nyquist files in the dmg.

This works for me (El Capitan) as guest user, downloading as guest,
installing using admin authorisation, and then running as guest.

Because it is using Portable Settings, I expect it not to have the
problem that Gale saw.
I've fixed http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 but as
this is currently just in my GitBranch, I'm not marking that
Devel-fixmade yet.

The changes can be seen here:
https://github.com/JamesCrook/audacity/commits/master

However I am going to tidy them up and push -f the cleanup to my repo
before I commit the changes to main.  These changes mean we do have a
working Portable Settings option that also avoids bug 1567.

This can be converted to not using portable settings by deleting the
Portable Settings Folder.  I've tried this for guest and did not need to
authorise to do so.


This is looking promising to me.  I'm expecting issues:
- LAME (unavoidable?)
- Downloading as one user and installer, and then using as a different user.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Peter Sampson-2
Looking good when testing on
a) Guest - installed on desktop
b) Test (standard - non priv) - installed on desktop
c) Admin a/c - installed in Applications folder

1) Nyquist below-the-line effects prent and correct ) and work
2) no request to set temp files location
3) no exports to Applications folder
4) No LAME though still on Guest and Test (separate test results sent to Gale)

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Gale
Administrator
In reply to this post by James Crook
James,

I don't understand the point Paul and I spending time on a
better fix for bug 1567 if you are going in the opposite direction.

Can you explain more about this version please. Are you saying
that in this version, we still have an optional Portable Settings
feature where users can have different settings, and that
upgraders won't lose their settings? .

I think we could be quite close to a proper fix for 1567 that
does not involve messing with Portable Settings or symlinks.
There must be some significance in false starting Audacity
curing the bug.

I don't know about LAME until I look into this. It looks like
a P1 to me if we can't make it work for Peter.


Gale


On 3 January 2017 at 13:07, James Crook <[hidden email]> wrote:

> I've just shared a jc10 signed alpha with relevant people.
>
> This fixes the 2 Nyquist problems.  Nyquist effects now appear and can
> be used, and there aren't redundant Nyquist files in the dmg.
>
> This works for me (El Capitan) as guest user, downloading as guest,
> installing using admin authorisation, and then running as guest.
>
> Because it is using Portable Settings, I expect it not to have the
> problem that Gale saw.
> I've fixed http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 but as
> this is currently just in my GitBranch, I'm not marking that
> Devel-fixmade yet.
>
> The changes can be seen here:
> https://github.com/JamesCrook/audacity/commits/master
>
> However I am going to tidy them up and push -f the cleanup to my repo
> before I commit the changes to main.  These changes mean we do have a
> working Portable Settings option that also avoids bug 1567.
>
> This can be converted to not using portable settings by deleting the
> Portable Settings Folder.  I've tried this for guest and did not need to
> authorise to do so.
>
>
> This is looking promising to me.  I'm expecting issues:
> - LAME (unavoidable?)
> - Downloading as one user and installer, and then using as a different user.
>
> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

James Crook
Thanks Gale.

If you and Paul find a way forward with current investigations that is
better than Portable Settings, then that is what we will go with.

On 1/3/2017 2:04 PM, Gale Andrews wrote:
> James,
>
> I don't understand the point Paul and I spending time on a
> better fix for bug 1567 if you are going in the opposite direction.
I don't think the better fix is working yet.  It sounds to me as if the
nearest it has come so far has some similar problems to portable
settings.  You have said yourself there is no candidate yet to make a
signed version of.  If there were a candidate I would build it so we
could test a signed version.

You do agree we need Portable Settings to work anyway?  So time spent on
making sure it works is not wasted time whether we use it or not.  If
Portable Settings does provide a workaround, we do have some insurance
against the routes you and Paul are investigating not actually yielding
a workaround.  Which I currently think quite likely.

More reasons: We are now, I think, committed to all in the app.  You
said you thought we would need to go in that direction in time in any
case.  We are all in the app in git now, and surely will be for 2.1.3.  
jc10 is helping to make sure that all in the app does actually work.

A specific problem of the 'better fix' based on symlinks is that on
affected systems, the one time in 16 that they don't work the first time
is not addressed.  My understanding is that Portable Settings and jc10
does in fact address that.  At the moment Portable Settings is closer to
being a releasable solution than the solutions we are hoping for.



> Can you explain more about this version please. Are you saying
> that in this version, we still have an optional Portable Settings
> feature where users can have different settings, and that
> upgraders won't lose their settings? .
in jc10 Portable Settings are the default.
This (currently) makes audacity effectively single user, and upgraders
lose settings.

Users who want to be multi user need to delete portable settings, and
after doing that on systems that have the 1567 problem they probably
still need the xattr solution.  At least we can give user instructions
to do this, while the majority of users, who do not need to be multi
user, are protected from the 1567 problem without taking any extra steps
(which they might not read).


> I think we could be quite close to a proper fix for 1567 that
> does not involve messing with Portable Settings or symlinks.
> There must be some significance in false starting Audacity
> curing the bug.
I'm glad of that, but less optimistic.

At the moment the Portable Settings solution is the closest we have to a
solution.
If we want to we can improve it to help upgraders by copying the old
config in, if there was no config already in portable settings. Even on
1567 affected machines that can be expected to work 1/16 of the times on
the first go, and if it does fail, the default config is no disaster -
certainly a lesser disaster than 1567.
It we want to, we can probably improve it to make it multi user using
wxGetUserId() in the name/path of the config file.  For example we could
have a folder 'User Settings' which is just like Portable settings, but
uses the wxGetUserId(0 trick to keep configs separate.

> I don't know about LAME until I look into this. It looks like
> a P1 to me if we can't make it work for Peter.
Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Gale
Administrator
Hi James,

On 3 January 2017 at 15:18, James Crook <[hidden email]> wrote:

> Thanks Gale.
>
> If you and Paul find a way forward with current investigations that is
> better than Portable Settings, then that is what we will go with.
>
> On 1/3/2017 2:04 PM, Gale Andrews wrote:
>> James,
>>
>> I don't understand the point Paul and I spending time on a
>> better fix for bug 1567 if you are going in the opposite direction.
> I don't think the better fix is working yet.  It sounds to me as if the
> nearest it has come so far has some similar problems to portable
> settings.

I have not even tested symlinks with standard user yet, because
we are trying to look for solutions that don't change the file system.

If those don't work out, I do still conjecture that moving the
configuration folder inside the bundle on a per-user basis "might"
avoid problems with standard or guest users. With your expertise
you might tell me I am wrong. Even then, I assume we can retain
user settings, which to me is a huge advance over the Portable
Settings solution.


> You have said yourself there is no candidate yet to make a
> signed version of.  If there were a candidate I would build it so we
> could test a signed version.
>
> You do agree we need Portable Settings to work anyway?

Yes absolutely, though I am figuring that is only P3 even if it
affects standard users. I wasn't really clear from skim reading
your description what had changed here.


> So time spent on making sure it works is not wasted time whether we use it or not.  If
> Portable Settings does provide a workaround, we do have some insurance
> against the routes you and Paul are investigating not actually yielding
> a workaround.  Which I currently think quite likely.

I do feel lines of enquiry with sleep or retry are very much open.


> More reasons: We are now, I think, committed to all in the app.  You
> said you thought we would need to go in that direction in time in any
> case.  We are all in the app in git now, and surely will be for 2.1.3.
> jc10 is helping to make sure that all in the app does actually work.

OK but it's about my testing priorities. I think for the next couple of
days mine should be on any new 1567 fixes Paul (or you?) come
up with, and looking at Peter's LAME issue.

With others testing your latest jc's I didn't think there was anything
in them that I really needed to test, especially if we are able to
fix 1567 another way.

So let me know if there is anything here I really should try.


> A specific problem of the 'better fix' based on symlinks is that on
> affected systems, the one time in 16 that they don't work the first time
> is not addressed.

I totally agree. For that reason symlinks is not actually in my
"better fix" category, unless Paul does a single symlink to
to the configuration folder and somehow makes the link
still get created even if the bug triggers first time.

Are we sure there is no way to ship a single symlink with
Audacity, or at least have the DMG create it when dragging
Audacity from the DMG to its target location?


 > My understanding is that Portable Settings and jc10
> does in fact address that.  At the moment Portable Settings is closer to
> being a releasable solution than the solutions we are hoping for.

That depends on the weight put on preserving user settings,
where we have different opinions.


>> Can you explain more about this version please. Are you saying
>> that in this version, we still have an optional Portable Settings
>> feature where users can have different settings, and that
>> upgraders won't lose their settings? .
> in jc10 Portable Settings are the default.
> This (currently) makes audacity effectively single user, and upgraders
> lose settings.
>
> Users who want to be multi user need to delete portable settings, and
> after doing that on systems that have the 1567 problem they probably
> still need the xattr solution.  At least we can give user instructions
> to do this, while the majority of users, who do not need to be multi
> user, are protected from the 1567 problem without taking any extra steps
> (which they might not read).

What about a single user who wants to turn on/off a different set
of settings, which is possible with the Portable Settings feature in
2.1.2. Is that feature lost in jc10?


>> I think we could be quite close to a proper fix for 1567 that
>> does not involve messing with Portable Settings or symlinks.
>> There must be some significance in false starting Audacity
>> curing the bug.
> I'm glad of that, but less optimistic.

Can you be specific why you are less optimistic?


> At the moment the Portable Settings solution is the closest we have to a
> solution.
> If we want to we can improve it to help upgraders by copying the old
> config in, if there was no config already in portable settings.

We mean all three .cfg files, as I understand it. Yes loss of user
settings is my main problem with the "Portable Settings" fix. It
will be P1 for 2.1.4-alpha and it's veering on P1 now IMO, if left
unameliorated. It makes all the difference to me if we "ameliorate"
it.

Copy or move, though? I understood you were concerned about
leaving behind .cfg files in the original configuration folder.


> Even on 1567 affected machines that can be expected to work 1/16 of
> the times on the first go, and if it does fail, the default config is no disaster -
> certainly a lesser disaster than 1567.
> It we want to, we can probably improve it to make it multi user using
> wxGetUserId() in the name/path of the config file.  For example we could
> have a folder 'User Settings' which is just like Portable settings, but
> uses the wxGetUserId(0 trick to keep configs separate.

So with that, and moving in the old .cfg files into the app, isn't that
very similar to my proposal I refer to at the start of this message?

And couldn't we then retain the original purpose of Portable
Settings? The fix does not require a "Portable Settings" folder
as such.

It *does* (unless we stop it triggering some other way) require
the .cfg files to be somewhere inside the app (or there to be a
symlink in the app to the .cfg files, but I don't see that as a good
way forward right now).


>> I don't know about LAME until I look into this. It looks like
>> a P1 to me if we can't make it work for Peter.
> Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.

Let's see. FFmpeg is also unsigned. If there is no problem with
FFmpeg then it is not a signing problem.



Gale


> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Cliff Scott
In reply to this post by Peter Sampson-2
Same results here. Everything works fine on 10.11.6 and 10.12.2 admin.

Cliff

> On Jan 3, 2017, at 7:29 AM, Peter Sampson <[hidden email]> wrote:
>
> Looking good when testing on
> a) Guest - installed on desktop
> b) Test (standard - non priv) - installed on desktop
> c) Admin a/c - installed in Applications folder
>
> 1) Nyquist below-the-line effects prent and correct ) and work
> 2) no request to set temp files location
> 3) no exports to Applications folder
> 4) No LAME though still on Guest and Test (separate test results sent to Gale)
>
> Peter.
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

James Crook
In reply to this post by Gale
On 1/3/2017 5:03 PM, Gale Andrews wrote:

> Hi James,
>
> On 3 January 2017 at 15:18, James Crook <[hidden email]> wrote:
>> Thanks Gale.
>>
>> If you and Paul find a way forward with current investigations that is
>> better than Portable Settings, then that is what we will go with.
>>
>> On 1/3/2017 2:04 PM, Gale Andrews wrote:
>>> James,
>>>
>>> I don't understand the point Paul and I spending time on a
>>> better fix for bug 1567 if you are going in the opposite direction.
>> I don't think the better fix is working yet.  It sounds to me as if the
>> nearest it has come so far has some similar problems to portable
>> settings.
> I have not even tested symlinks with standard user yet, because
> we are trying to look for solutions that don't change the file system.
>
> If those don't work out, I do still conjecture that moving the
> configuration folder inside the bundle on a per-user basis "might"
> avoid problems with standard or guest users. With your expertise
> you might tell me I am wrong.
I expect that to avoid the problem.
More specifically, if 'Portable Settings' is free of 1567, which we
fully believe it is, then there is no reason why 'User Settings' in the
bundle, with different audacity.cfg's for different users in that should
also not be free of 1567.  There is a tiny question mark about whether
reading an older audacity.cfg from outside the bundle or reading and
deleting (on the very first run) might trigger 1567. I think the reading
is very very unlikely to, and it's the rewriting that does it, but of
course we don't know for sure.


> Even then, I assume we can retain user settings, which to me is a huge advance over the Portable Settings solution.
IF we are still struggling with 1567 in a week's time, then I am going
to move forward on releasing with portable settings, which will then be
your cue to raise the limitations of portable settings as a P1 blocker,
and we can then address them.  Or we might decide to explore the 'User
Settings' sooner, if the other approaches don't yield gold.
>> You do agree we need Portable Settings to work anyway?
> Yes absolutely, though I am figuring that is only P3 even if it
> affects standard users.
Agree it is P3.  As RM I am entitled to fix things that aren't P1 or P2,
and in this case I think it was worth doing.

> I wasn't really clear from skim reading your description what had changed here.
I went round in circles a bit, but the net result is now in GitHub, with
these commits:

Make get_gitident.sh runnable
https://github.com/audacity/audacity/commit/51f91f3

Create temporary directory recursively + Reduced search path.
https://github.com/audacity/audacity/commit/90738ce

Bug 1304 - Starting Save or Export directory is not set, so is unwrit...
https://github.com/audacity/audacity/commit/e9b9fcb

Script tweaks.  …
https://github.com/audacity/audacity/commit/29a392f


The script tweaks are not germane.

The 90738ce patch fixes the duff temporary directory that Peter saw.  If
we have a long path to the temp directory, we now make sure all the
intermediate directories exist.  Previously Mkdir could fail if the
parent did not exist.
The reduced search path is removing a path for searching the dmg that we
don't need anymore.  Everything should be in the .app. and we could just
ship the app.


> I do feel lines of enquiry with sleep or retry are very much open.
Great.  Look forward to something coming out of that.

>
>> More reasons: We are now, I think, committed to all in the app.  You
>> said you thought we would need to go in that direction in time in any
>> case.  We are all in the app in git now, and surely will be for 2.1.3.
>> jc10 is helping to make sure that all in the app does actually work.
> OK but it's about my testing priorities. I think for the next couple of
> days mine should be on any new 1567 fixes Paul (or you?) come
> up with, and looking at Peter's LAME issue.
Fine with that.  Having Peter's testing of jc10 is giving me good
confidence in the latest commits, and also that I am building and
signing correctly.  The latest commits will now be in nightlies anyway,
so will get tested.

> With others testing your latest jc's I didn't think there was anything
> in them that I really needed to test, especially if we are able to
> fix 1567 another way.
>
> So let me know if there is anything here I really should try.
What Peter and others are doing is enough.  It will for example pick up
any major issue with signing.

>
>> A specific problem of the 'better fix' based on symlinks is that on
>> affected systems, the one time in 16 that they don't work the first time
>> is not addressed.
> I totally agree. For that reason symlinks is not actually in my
> "better fix" category, unless Paul does a single symlink to
> to the configuration folder and somehow makes the link
> still get created even if the bug triggers first time.
>
> Are we sure there is no way to ship a single symlink with
> Audacity, or at least have the DMG create it when dragging
> Audacity from the DMG to its target location?
I think both are unlikely.  If they were possible they would likely be
fragile.


>   > My understanding is that Portable Settings and jc10
>> does in fact address that.  At the moment Portable Settings is closer to
>> being a releasable solution than the solutions we are hoping for.
> That depends on the weight put on preserving user settings,
> where we have different opinions.
>
>
>>> Can you explain more about this version please. Are you saying
>>> that in this version, we still have an optional Portable Settings
>>> feature where users can have different settings, and that
>>> upgraders won't lose their settings? .
>> in jc10 Portable Settings are the default.
>> This (currently) makes audacity effectively single user, and upgraders
>> lose settings.
>>
>> Users who want to be multi user need to delete portable settings, and
>> after doing that on systems that have the 1567 problem they probably
>> still need the xattr solution.  At least we can give user instructions
>> to do this, while the majority of users, who do not need to be multi
>> user, are protected from the 1567 problem without taking any extra steps
>> (which they might not read).
> What about a single user who wants to turn on/off a different set
> of settings, which is possible with the Portable Settings feature in
> 2.1.2. Is that feature lost in jc10?
How do they turn the settings on or off in 2.1.2?

>
>>> I think we could be quite close to a proper fix for 1567 that
>>> does not involve messing with Portable Settings or symlinks.
>>> There must be some significance in false starting Audacity
>>> curing the bug.
>> I'm glad of that, but less optimistic.
> Can you be specific why you are less optimistic?
Because writing audacity.cfg just once on exit does not help.
Frequent rewriting / flush seemed to me the most promising lead as to
the root cause.  It is the kind of thing where antivirus/gatekeeper
might want to check every single write and say 'too much, too quick, I
give up' and so block access in some way.


>
>> At the moment the Portable Settings solution is the closest we have to a
>> solution.
>> If we want to we can improve it to help upgraders by copying the old
>> config in, if there was no config already in portable settings.
> We mean all three .cfg files, as I understand it. Yes loss of user
> settings is my main problem with the "Portable Settings" fix. It
> will be P1 for 2.1.4-alpha and it's veering on P1 now IMO, if left
> unameliorated. It makes all the difference to me if we "ameliorate"
> it.
>
> Copy or move, though? I understood you were concerned about
> leaving behind .cfg files in the original configuration folder.
I'm vacillating.
Copy is almost 100% likely to not have the 1567 bug.
Move has the advantage of being less confusing if the user ever deletes
the "User Settings" audacity.cfg.  The settings from long ago don't
suddenly reappear in use.



>
>> Even on 1567 affected machines that can be expected to work 1/16 of
>> the times on the first go, and if it does fail, the default config is no disaster -
>> certainly a lesser disaster than 1567.
>> It we want to, we can probably improve it to make it multi user using
>> wxGetUserId() in the name/path of the config file.  For example we could
>> have a folder 'User Settings' which is just like Portable settings, but
>> uses the wxGetUserId(0 trick to keep configs separate.
> So with that, and moving in the old .cfg files into the app, isn't that
> very similar to my proposal I refer to at the start of this message?
>
> And couldn't we then retain the original purpose of Portable
> Settings? The fix does not require a "Portable Settings" folder
> as such.
Indeed.  But if we can't get 'Portable Settings' to work properly, then
we have no hope of getting 'User Settings' to work as described above.  
So fixing and checking 'Portable Settings' shipped on with Audacity is a
necessary precursor to working on and shipping 'User Settings'
defaulting on with Audacity.


> It *does* (unless we stop it triggering some other way) require
> the .cfg files to be somewhere inside the app (or there to be a
> symlink in the app to the .cfg files, but I don't see that as a good
> way forward right now).
So we hold out for a better solution for a little longer.




>
>>> I don't know about LAME until I look into this. It looks like
>>> a P1 to me if we can't make it work for Peter.
>> Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.
> Let's see. FFmpeg is also unsigned. If there is no problem with
> FFmpeg then it is not a signing problem.
If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
hope for LAME.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Gale
Administrator
On 3 January 2017 at 20:44, James Crook <[hidden email]> wrote:

> On 1/3/2017 5:03 PM, Gale Andrews wrote:
>> Hi James,
>>
>> On 3 January 2017 at 15:18, James Crook <[hidden email]> wrote:
>>> Thanks Gale.
>>>
>>> If you and Paul find a way forward with current investigations that is
>>> better than Portable Settings, then that is what we will go with.
>>>
>>> On 1/3/2017 2:04 PM, Gale Andrews wrote:
>>>> James,
>>>>
>>>> I don't understand the point Paul and I spending time on a
>>>> better fix for bug 1567 if you are going in the opposite direction.
>>> I don't think the better fix is working yet.  It sounds to me as if the
>>> nearest it has come so far has some similar problems to portable
>>> settings.
>> I have not even tested symlinks with standard user yet, because
>> we are trying to look for solutions that don't change the file system.
>>
>> If those don't work out, I do still conjecture that moving the
>> configuration folder inside the bundle on a per-user basis "might"
>> avoid problems with standard or guest users. With your expertise
>> you might tell me I am wrong.
> I expect that to avoid the problem.
> More specifically, if 'Portable Settings' is free of 1567, which we
> fully believe it is, then there is no reason why 'User Settings' in the
> bundle, with different audacity.cfg's for different users in that should
> also not be free of 1567.  There is a tiny question mark about whether
> reading an older audacity.cfg from outside the bundle or reading and
> deleting (on the very first run) might trigger 1567. I think the reading
> is very very unlikely to, and it's the rewriting that does it, but of
> course we don't know for sure.

I don't expect reading an older cfg file to create a problem.

It doesn't seem that rewriting audacity.cfg (to disk) in itself triggers
the bug, given the bug happens more often when we don't
write/rewrite it to disk at all during the Audacity session.


>> Even then, I assume we can retain user settings, which to me is a huge advance over the Portable Settings solution.
> IF we are still struggling with 1567 in a week's time, then I am going
> to move forward on releasing with portable settings
> which will then be
> your cue to raise the limitations of portable settings as a P1 blocker,
> and we can then address them.

What will the signal for that be? We don't need a collision with
you releasing RC1 and me responding by raising a P1, unless
you think a week of testing of RC1 would be good anyhow with
an RC2 to come.

I agree "a week" is more than reasonable to decide where we're
going with this.


>  Or we might decide to explore the 'User Settings' sooner, if the
> other approaches don't yield gold.

I can see that happening if someone is willing to code it. It would
be possible to argue high confidence in that solution, from where
we are now (if Portable Settings test correctly).


>>> You do agree we need Portable Settings to work anyway?
>> Yes absolutely, though I am figuring that is only P3 even if it
>> affects standard users.
> Agree it is P3.  As RM I am entitled to fix things that aren't P1 or P2,
> and in this case I think it was worth doing.
>
>> I wasn't really clear from skim reading your description what had changed here.
> I went round in circles a bit, but the net result is now in GitHub, with
> these commits:
>
> Make get_gitident.sh runnable
> https://github.com/audacity/audacity/commit/51f91f3
>
> Create temporary directory recursively + Reduced search path.
> https://github.com/audacity/audacity/commit/90738ce
>
> Bug 1304 - Starting Save or Export directory is not set, so is unwrit...
> https://github.com/audacity/audacity/commit/e9b9fcb
>
> Script tweaks.  …
> https://github.com/audacity/audacity/commit/29a392f
>
>
> The script tweaks are not germane.
>
> The 90738ce patch fixes the duff temporary directory that Peter saw.  If
> we have a long path to the temp directory, we now make sure all the
> intermediate directories exist.  Previously Mkdir could fail if the
> parent did not exist.
> The reduced search path is removing a path for searching the dmg that we
> don't need anymore.  Everything should be in the .app. and we could just
> ship the app.
>
>
>> I do feel lines of enquiry with sleep or retry are very much open.
> Great.  Look forward to something coming out of that.
>
>>
>>> More reasons: We are now, I think, committed to all in the app.  You
>>> said you thought we would need to go in that direction in time in any
>>> case.  We are all in the app in git now, and surely will be for 2.1.3.
>>> jc10 is helping to make sure that all in the app does actually work.
>> OK but it's about my testing priorities. I think for the next couple of
>> days mine should be on any new 1567 fixes Paul (or you?) come
>> up with, and looking at Peter's LAME issue.
> Fine with that.  Having Peter's testing of jc10 is giving me good
> confidence in the latest commits, and also that I am building and
> signing correctly.  The latest commits will now be in nightlies anyway,
> so will get tested.
>
>> With others testing your latest jc's I didn't think there was anything
>> in them that I really needed to test, especially if we are able to
>> fix 1567 another way.
>>
>> So let me know if there is anything here I really should try.
> What Peter and others are doing is enough.  It will for example pick up
> any major issue with signing.
>
>>
>>> A specific problem of the 'better fix' based on symlinks is that on
>>> affected systems, the one time in 16 that they don't work the first time
>>> is not addressed.
>> I totally agree. For that reason symlinks is not actually in my
>> "better fix" category, unless Paul does a single symlink to
>> to the configuration folder and somehow makes the link
>> still get created even if the bug triggers first time.
>>
>> Are we sure there is no way to ship a single symlink with
>> Audacity, or at least have the DMG create it when dragging
>> Audacity from the DMG to its target location?
> I think both are unlikely.  If they were possible they would likely be
> fragile.
>
>
>>   > My understanding is that Portable Settings and jc10
>>> does in fact address that.  At the moment Portable Settings is closer to
>>> being a releasable solution than the solutions we are hoping for.
>> That depends on the weight put on preserving user settings,
>> where we have different opinions.
>>
>>
>>>> Can you explain more about this version please. Are you saying
>>>> that in this version, we still have an optional Portable Settings
>>>> feature where users can have different settings, and that
>>>> upgraders won't lose their settings? .
>>> in jc10 Portable Settings are the default.
>>> This (currently) makes audacity effectively single user, and upgraders
>>> lose settings.
>>>
>>> Users who want to be multi user need to delete portable settings, and
>>> after doing that on systems that have the 1567 problem they probably
>>> still need the xattr solution.  At least we can give user instructions
>>> to do this, while the majority of users, who do not need to be multi
>>> user, are protected from the 1567 problem without taking any extra steps
>>> (which they might not read).
>> What about a single user who wants to turn on/off a different set
>> of settings, which is possible with the Portable Settings feature in
>> 2.1.2. Is that feature lost in jc10?
> How do they turn the settings on or off in 2.1.2?

Turn off by renaming the "Portable Settings" folder to something else.

Rename back to "Portable Settings" to turn back on.


>>>> I think we could be quite close to a proper fix for 1567 that
>>>> does not involve messing with Portable Settings or symlinks.
>>>> There must be some significance in false starting Audacity
>>>> curing the bug.
>>> I'm glad of that, but less optimistic.
>> Can you be specific why you are less optimistic?
> Because writing audacity.cfg just once on exit does not help.
> Frequent rewriting / flush seemed to me the most promising lead as to
> the root cause.  It is the kind of thing where antivirus/gatekeeper
> might want to check every single write and say 'too much, too quick, I
> give up' and so block access in some way.

Startup being "too fast" could be the problem - we might not have
the sleep in the correct place where we tried it before.

Unless it is something else - e.g. Gatekeeper becomes "lenient"
if the app did not start correctly - a strange theory to me.


>>> At the moment the Portable Settings solution is the closest we have to a
>>> solution.
>>> If we want to we can improve it to help upgraders by copying the old
>>> config in, if there was no config already in portable settings.
>> We mean all three .cfg files, as I understand it. Yes loss of user
>> settings is my main problem with the "Portable Settings" fix. It
>> will be P1 for 2.1.4-alpha and it's veering on P1 now IMO, if left
>> unameliorated. It makes all the difference to me if we "ameliorate"
>> it.
>>
>> Copy or move, though? I understood you were concerned about
>> leaving behind .cfg files in the original configuration folder.
> I'm vacillating.
> Copy is almost 100% likely to not have the 1567 bug.
> Move has the advantage of being less confusing if the user ever deletes
> the "User Settings" audacity.cfg.  The settings from long ago don't
> suddenly reappear in use.

I would try move first if we go that route.


>>> Even on 1567 affected machines that can be expected to work 1/16 of
>>> the times on the first go, and if it does fail, the default config is no disaster -
>>> certainly a lesser disaster than 1567.
>>> It we want to, we can probably improve it to make it multi user using
>>> wxGetUserId() in the name/path of the config file.  For example we could
>>> have a folder 'User Settings' which is just like Portable settings, but
>>> uses the wxGetUserId(0 trick to keep configs separate.
>> So with that, and moving in the old .cfg files into the app, isn't that
>> very similar to my proposal I refer to at the start of this message?
>>
>> And couldn't we then retain the original purpose of Portable
>> Settings? The fix does not require a "Portable Settings" folder
>> as such.
> Indeed.  But if we can't get 'Portable Settings' to work properly, then
> we have no hope of getting 'User Settings' to work as described above.
> So fixing and checking 'Portable Settings' shipped on with Audacity is a
> necessary precursor to working on and shipping 'User Settings'
> defaulting on with Audacity.

OK.

>> It *does* (unless we stop it triggering some other way) require
>> the .cfg files to be somewhere inside the app (or there to be a
>> symlink in the app to the .cfg files, but I don't see that as a good
>> way forward right now).
> So we hold out for a better solution for a little longer.
>
>
>
>
>>
>>>> I don't know about LAME until I look into this. It looks like
>>>> a P1 to me if we can't make it work for Peter.
>>> Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.
>> Let's see. FFmpeg is also unsigned. If there is no problem with
>> FFmpeg then it is not a signing problem.
> If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
> hope for LAME.

Both are dynamically loaded if using Libraries Preferences.


Gale


--James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

James Crook
On 1/4/2017 2:35 AM, Gale Andrews wrote:
> On 3 January 2017 at 20:44, James Crook <[hidden email]> wrote:

>> IF we are still struggling with 1567 in a week's time, then I am going
>> to move forward on releasing with portable settings
>> which will then be
>> your cue to raise the limitations of portable settings as a P1 blocker,
>> and we can then address them.
> What will the signal for that be?
Something like me setting IS_ALPHA to 0, asking Peter to set the manual
to release, and me asking you if you are ready for me to send you a
Portable-Settings RC?
My guess is you would say 'No, not ready' and we'd have to move towards
a 'User-Settings' alpha instead.  So I guess the Portable Settings RC
happens only if we've got nowhere between then and now.

> We don't need a collision with you releasing RC1 and me responding by raising a P1, unless you think a week of testing of RC1 would be good anyhow with an RC2 to come.
>
> I agree "a week" is more than reasonable to decide where we're
> going with this.
>
>
>>   Or we might decide to explore the 'User Settings' sooner, if the
>> other approaches don't yield gold.
> I can see that happening if someone is willing to code it. It would
> be possible to argue high confidence in that solution, from where
> we are now (if Portable Settings test correctly).
I think pretty high confidence too.

>> How do they turn the settings on or off in 2.1.2?
> Turn off by renaming the "Portable Settings" folder to something else.
>
> Rename back to "Portable Settings" to turn back on.
Not much difference to renaming Library/Audacity then.
Yes, they would still be able to do as you describe via Portable
Setting.  They would need to go into the bundle, but once they rename
Portable Settings audacity won't look there.


>> If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
>> hope for LAME.
> Both are dynamically loaded if using Libraries Preferences.
Anything from Apple store is apple signed, and so compatible with other
signed programs.  But Apple is special that way, and signed by Tom
should not interoperate with signed by Jerry (unless Tom and Jerry are
from the same company).  But we're assuming FFmpeg is completely
unsigned and so should only work with gatekeeper off (or FFmpeg
xattr'd/out-of-quarantine/self-built).

--James.




>
>
> Gale
>
>
> --James.
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Paul Licameli
In reply to this post by Gale


On Tue, Jan 3, 2017 at 9:35 PM, Gale Andrews <[hidden email]> wrote:
On 3 January 2017 at 20:44, James Crook <[hidden email]> wrote:
> On 1/3/2017 5:03 PM, Gale Andrews wrote:
>> Hi James,
>>
>> On 3 January 2017 at 15:18, James Crook <[hidden email]> wrote:
>>> Thanks Gale.
>>>
>>> If you and Paul find a way forward with current investigations that is
>>> better than Portable Settings, then that is what we will go with.
>>>
>>> On 1/3/2017 2:04 PM, Gale Andrews wrote:
>>>> James,
>>>>
>>>> I don't understand the point Paul and I spending time on a
>>>> better fix for bug 1567 if you are going in the opposite direction.
>>> I don't think the better fix is working yet.  It sounds to me as if the
>>> nearest it has come so far has some similar problems to portable
>>> settings.
>> I have not even tested symlinks with standard user yet, because
>> we are trying to look for solutions that don't change the file system.
>>
>> If those don't work out, I do still conjecture that moving the
>> configuration folder inside the bundle on a per-user basis "might"
>> avoid problems with standard or guest users. With your expertise
>> you might tell me I am wrong.
> I expect that to avoid the problem.
> More specifically, if 'Portable Settings' is free of 1567, which we
> fully believe it is, then there is no reason why 'User Settings' in the
> bundle, with different audacity.cfg's for different users in that should
> also not be free of 1567.  There is a tiny question mark about whether
> reading an older audacity.cfg from outside the bundle or reading and
> deleting (on the very first run) might trigger 1567. I think the reading
> is very very unlikely to, and it's the rewriting that does it, but of
> course we don't know for sure.

I don't expect reading an older cfg file to create a problem.

It doesn't seem that rewriting audacity.cfg (to disk) in itself triggers
the bug, given the bug happens more often when we don't
write/rewrite it to disk at all during the Audacity session.


If you refer to behavior in commit 0a7e6ad8d74f1b633a8af490c4407e5b2e3e7647, you are incorrect: the file is written (replaced), though just once, at end of session.  It seems something happens between sessions, and the bug manifests when you restart the program.  It could be that there is something about the timing of the less frequent writes that makes the bug more likely.

But actually writing, as distinct from deleting and replacing replacing, audacity.cfg -- so that it is always at the same inode -- is what will happen in my commit 407fc70957217d36921b4a664588179e9c831efa, and that might make some difference.

Has this been tried?

PRL


 

>> Even then, I assume we can retain user settings, which to me is a huge advance over the Portable Settings solution.
> IF we are still struggling with 1567 in a week's time, then I am going
> to move forward on releasing with portable settings
> which will then be
> your cue to raise the limitations of portable settings as a P1 blocker,
> and we can then address them.

What will the signal for that be? We don't need a collision with
you releasing RC1 and me responding by raising a P1, unless
you think a week of testing of RC1 would be good anyhow with
an RC2 to come.

I agree "a week" is more than reasonable to decide where we're
going with this.


>  Or we might decide to explore the 'User Settings' sooner, if the
> other approaches don't yield gold.

I can see that happening if someone is willing to code it. It would
be possible to argue high confidence in that solution, from where
we are now (if Portable Settings test correctly).


>>> You do agree we need Portable Settings to work anyway?
>> Yes absolutely, though I am figuring that is only P3 even if it
>> affects standard users.
> Agree it is P3.  As RM I am entitled to fix things that aren't P1 or P2,
> and in this case I think it was worth doing.
>
>> I wasn't really clear from skim reading your description what had changed here.
> I went round in circles a bit, but the net result is now in GitHub, with
> these commits:
>
> Make get_gitident.sh runnable
> https://github.com/audacity/audacity/commit/51f91f3
>
> Create temporary directory recursively + Reduced search path.
> https://github.com/audacity/audacity/commit/90738ce
>
> Bug 1304 - Starting Save or Export directory is not set, so is unwrit...
> https://github.com/audacity/audacity/commit/e9b9fcb
>
> Script tweaks.  …
> https://github.com/audacity/audacity/commit/29a392f
>
>
> The script tweaks are not germane.
>
> The 90738ce patch fixes the duff temporary directory that Peter saw.  If
> we have a long path to the temp directory, we now make sure all the
> intermediate directories exist.  Previously Mkdir could fail if the
> parent did not exist.
> The reduced search path is removing a path for searching the dmg that we
> don't need anymore.  Everything should be in the .app. and we could just
> ship the app.
>
>
>> I do feel lines of enquiry with sleep or retry are very much open.
> Great.  Look forward to something coming out of that.
>
>>
>>> More reasons: We are now, I think, committed to all in the app.  You
>>> said you thought we would need to go in that direction in time in any
>>> case.  We are all in the app in git now, and surely will be for 2.1.3.
>>> jc10 is helping to make sure that all in the app does actually work.
>> OK but it's about my testing priorities. I think for the next couple of
>> days mine should be on any new 1567 fixes Paul (or you?) come
>> up with, and looking at Peter's LAME issue.
> Fine with that.  Having Peter's testing of jc10 is giving me good
> confidence in the latest commits, and also that I am building and
> signing correctly.  The latest commits will now be in nightlies anyway,
> so will get tested.
>
>> With others testing your latest jc's I didn't think there was anything
>> in them that I really needed to test, especially if we are able to
>> fix 1567 another way.
>>
>> So let me know if there is anything here I really should try.
> What Peter and others are doing is enough.  It will for example pick up
> any major issue with signing.
>
>>
>>> A specific problem of the 'better fix' based on symlinks is that on
>>> affected systems, the one time in 16 that they don't work the first time
>>> is not addressed.
>> I totally agree. For that reason symlinks is not actually in my
>> "better fix" category, unless Paul does a single symlink to
>> to the configuration folder and somehow makes the link
>> still get created even if the bug triggers first time.
>>
>> Are we sure there is no way to ship a single symlink with
>> Audacity, or at least have the DMG create it when dragging
>> Audacity from the DMG to its target location?
> I think both are unlikely.  If they were possible they would likely be
> fragile.
>
>
>>   > My understanding is that Portable Settings and jc10
>>> does in fact address that.  At the moment Portable Settings is closer to
>>> being a releasable solution than the solutions we are hoping for.
>> That depends on the weight put on preserving user settings,
>> where we have different opinions.
>>
>>
>>>> Can you explain more about this version please. Are you saying
>>>> that in this version, we still have an optional Portable Settings
>>>> feature where users can have different settings, and that
>>>> upgraders won't lose their settings? .
>>> in jc10 Portable Settings are the default.
>>> This (currently) makes audacity effectively single user, and upgraders
>>> lose settings.
>>>
>>> Users who want to be multi user need to delete portable settings, and
>>> after doing that on systems that have the 1567 problem they probably
>>> still need the xattr solution.  At least we can give user instructions
>>> to do this, while the majority of users, who do not need to be multi
>>> user, are protected from the 1567 problem without taking any extra steps
>>> (which they might not read).
>> What about a single user who wants to turn on/off a different set
>> of settings, which is possible with the Portable Settings feature in
>> 2.1.2. Is that feature lost in jc10?
> How do they turn the settings on or off in 2.1.2?

Turn off by renaming the "Portable Settings" folder to something else.

Rename back to "Portable Settings" to turn back on.


>>>> I think we could be quite close to a proper fix for 1567 that
>>>> does not involve messing with Portable Settings or symlinks.
>>>> There must be some significance in false starting Audacity
>>>> curing the bug.
>>> I'm glad of that, but less optimistic.
>> Can you be specific why you are less optimistic?
> Because writing audacity.cfg just once on exit does not help.
> Frequent rewriting / flush seemed to me the most promising lead as to
> the root cause.  It is the kind of thing where antivirus/gatekeeper
> might want to check every single write and say 'too much, too quick, I
> give up' and so block access in some way.

Startup being "too fast" could be the problem - we might not have
the sleep in the correct place where we tried it before.

Unless it is something else - e.g. Gatekeeper becomes "lenient"
if the app did not start correctly - a strange theory to me.


>>> At the moment the Portable Settings solution is the closest we have to a
>>> solution.
>>> If we want to we can improve it to help upgraders by copying the old
>>> config in, if there was no config already in portable settings.
>> We mean all three .cfg files, as I understand it. Yes loss of user
>> settings is my main problem with the "Portable Settings" fix. It
>> will be P1 for 2.1.4-alpha and it's veering on P1 now IMO, if left
>> unameliorated. It makes all the difference to me if we "ameliorate"
>> it.
>>
>> Copy or move, though? I understood you were concerned about
>> leaving behind .cfg files in the original configuration folder.
> I'm vacillating.
> Copy is almost 100% likely to not have the 1567 bug.
> Move has the advantage of being less confusing if the user ever deletes
> the "User Settings" audacity.cfg.  The settings from long ago don't
> suddenly reappear in use.

I would try move first if we go that route.


>>> Even on 1567 affected machines that can be expected to work 1/16 of
>>> the times on the first go, and if it does fail, the default config is no disaster -
>>> certainly a lesser disaster than 1567.
>>> It we want to, we can probably improve it to make it multi user using
>>> wxGetUserId() in the name/path of the config file.  For example we could
>>> have a folder 'User Settings' which is just like Portable settings, but
>>> uses the wxGetUserId(0 trick to keep configs separate.
>> So with that, and moving in the old .cfg files into the app, isn't that
>> very similar to my proposal I refer to at the start of this message?
>>
>> And couldn't we then retain the original purpose of Portable
>> Settings? The fix does not require a "Portable Settings" folder
>> as such.
> Indeed.  But if we can't get 'Portable Settings' to work properly, then
> we have no hope of getting 'User Settings' to work as described above.
> So fixing and checking 'Portable Settings' shipped on with Audacity is a
> necessary precursor to working on and shipping 'User Settings'
> defaulting on with Audacity.

OK.

>> It *does* (unless we stop it triggering some other way) require
>> the .cfg files to be somewhere inside the app (or there to be a
>> symlink in the app to the .cfg files, but I don't see that as a good
>> way forward right now).
> So we hold out for a better solution for a little longer.
>
>
>
>
>>
>>>> I don't know about LAME until I look into this. It looks like
>>>> a P1 to me if we can't make it work for Peter.
>>> Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.
>> Let's see. FFmpeg is also unsigned. If there is no problem with
>> FFmpeg then it is not a signing problem.
> If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
> hope for LAME.

Both are dynamically loaded if using Libraries Preferences.


Gale


--James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Gale
Administrator
In reply to this post by James Crook
On 4 January 2017 at 12:14, James Crook <[hidden email]> wrote:

> On 1/4/2017 2:35 AM, Gale Andrews wrote:
>> On 3 January 2017 at 20:44, James Crook <[hidden email]> wrote:
>
>>> IF we are still struggling with 1567 in a week's time, then I am going
>>> to move forward on releasing with portable settings
>>> which will then be
>>> your cue to raise the limitations of portable settings as a P1 blocker,
>>> and we can then address them.
>> What will the signal for that be?
> Something like me setting IS_ALPHA to 0, asking Peter to set the manual
> to release, and me asking you if you are ready for me to send you a
> Portable-Settings RC?
> My guess is you would say 'No, not ready' and we'd have to move towards
> a 'User-Settings' alpha instead.  So I guess the Portable Settings RC
> happens only if we've got nowhere between then and now.

I think we should aim to have "User-Settings" as the fallback position
if we can't stop bug 1567 triggering, and not "Portable Settings" as
the fallback.

We have the switch to all-in-one and quite possibly user's custom-added
plugins left behind inside the old Audacity installation folder. Those are
big enough changes for users (necessary as they are) without adding
loss of settings into the mix. Again I urge you not to go that "Portable
Settings" route (unless all else including User-Settings fails).

Best way, keep me apprised of your plans if you wouldn't mind.


Gale

>> We don't need a collision with you releasing RC1 and me responding by raising a P1, unless you think a week of testing of RC1 would be good anyhow with an RC2 to come.
>>
>> I agree "a week" is more than reasonable to decide where we're
>> going with this.
>>
>>
>>>   Or we might decide to explore the 'User Settings' sooner, if the
>>> other approaches don't yield gold.
>> I can see that happening if someone is willing to code it. It would
>> be possible to argue high confidence in that solution, from where
>> we are now (if Portable Settings test correctly).
> I think pretty high confidence too.
>
>>> How do they turn the settings on or off in 2.1.2?
>> Turn off by renaming the "Portable Settings" folder to something else.
>>
>> Rename back to "Portable Settings" to turn back on.
> Not much difference to renaming Library/Audacity then.
> Yes, they would still be able to do as you describe via Portable
> Setting.  They would need to go into the bundle, but once they rename
> Portable Settings audacity won't look there.
>
>
>>> If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
>>> hope for LAME.
>> Both are dynamically loaded if using Libraries Preferences.
> Anything from Apple store is apple signed, and so compatible with other
> signed programs.  But Apple is special that way, and signed by Tom
> should not interoperate with signed by Jerry (unless Tom and Jerry are
> from the same company).  But we're assuming FFmpeg is completely
> unsigned and so should only work with gatekeeper off (or FFmpeg
> xattr'd/out-of-quarantine/self-built).
>
> --James.
>
>
>
>
>>
>>
>> Gale
>>
>>
>> --James.
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Paul Licameli
In reply to this post by Paul Licameli


On Wed, Jan 4, 2017 at 10:27 AM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 3, 2017 at 9:35 PM, Gale Andrews <[hidden email]> wrote:
On 3 January 2017 at 20:44, James Crook <[hidden email]> wrote:
> On 1/3/2017 5:03 PM, Gale Andrews wrote:
>> Hi James,
>>
>> On 3 January 2017 at 15:18, James Crook <[hidden email]> wrote:
>>> Thanks Gale.
>>>
>>> If you and Paul find a way forward with current investigations that is
>>> better than Portable Settings, then that is what we will go with.
>>>
>>> On 1/3/2017 2:04 PM, Gale Andrews wrote:
>>>> James,
>>>>
>>>> I don't understand the point Paul and I spending time on a
>>>> better fix for bug 1567 if you are going in the opposite direction.
>>> I don't think the better fix is working yet.  It sounds to me as if the
>>> nearest it has come so far has some similar problems to portable
>>> settings.
>> I have not even tested symlinks with standard user yet, because
>> we are trying to look for solutions that don't change the file system.
>>
>> If those don't work out, I do still conjecture that moving the
>> configuration folder inside the bundle on a per-user basis "might"
>> avoid problems with standard or guest users. With your expertise
>> you might tell me I am wrong.
> I expect that to avoid the problem.
> More specifically, if 'Portable Settings' is free of 1567, which we
> fully believe it is, then there is no reason why 'User Settings' in the
> bundle, with different audacity.cfg's for different users in that should
> also not be free of 1567.  There is a tiny question mark about whether
> reading an older audacity.cfg from outside the bundle or reading and
> deleting (on the very first run) might trigger 1567. I think the reading
> is very very unlikely to, and it's the rewriting that does it, but of
> course we don't know for sure.

I don't expect reading an older cfg file to create a problem.

It doesn't seem that rewriting audacity.cfg (to disk) in itself triggers
the bug, given the bug happens more often when we don't
write/rewrite it to disk at all during the Audacity session.


If you refer to behavior in commit 0a7e6ad8d74f1b633a8af490c4407e5b2e3e7647, you are incorrect: the file is written (replaced), though just once, at end of session.  It seems something happens between sessions, and the bug manifests when you restart the program.  It could be that there is something about the timing of the less frequent writes that makes the bug more likely.

But actually writing, as distinct from deleting and replacing replacing, audacity.cfg -- so that it is always at the same inode -- is what will happen in my commit 407fc70957217d36921b4a664588179e9c831efa, and that might make some difference.

Has this been tried?

PRL

Putting it differently:  I described the experience with 0a7e6ad8d74f1b633a8af490c4407e5b2e3e7647 as proving that the PATTERN of (not-really) writes (but rather replacements) of audacity.cfg is very definitely relevant to this bug.  This is unlike the conclusion Gale takes from it.

The pattern changed in a big way, so that there were fewer replacements, but still one, possibly at a time (application exit) when there had not been one before, because the flushes of preferences had been happening earlier.
 
Again, what we have not yet tried, is updating audacity.cfg with writes that are really writes, not replacements, of the file.

PRL



 

>> Even then, I assume we can retain user settings, which to me is a huge advance over the Portable Settings solution.
> IF we are still struggling with 1567 in a week's time, then I am going
> to move forward on releasing with portable settings
> which will then be
> your cue to raise the limitations of portable settings as a P1 blocker,
> and we can then address them.

What will the signal for that be? We don't need a collision with
you releasing RC1 and me responding by raising a P1, unless
you think a week of testing of RC1 would be good anyhow with
an RC2 to come.

I agree "a week" is more than reasonable to decide where we're
going with this.


>  Or we might decide to explore the 'User Settings' sooner, if the
> other approaches don't yield gold.

I can see that happening if someone is willing to code it. It would
be possible to argue high confidence in that solution, from where
we are now (if Portable Settings test correctly).


>>> You do agree we need Portable Settings to work anyway?
>> Yes absolutely, though I am figuring that is only P3 even if it
>> affects standard users.
> Agree it is P3.  As RM I am entitled to fix things that aren't P1 or P2,
> and in this case I think it was worth doing.
>
>> I wasn't really clear from skim reading your description what had changed here.
> I went round in circles a bit, but the net result is now in GitHub, with
> these commits:
>
> Make get_gitident.sh runnable
> https://github.com/audacity/audacity/commit/51f91f3
>
> Create temporary directory recursively + Reduced search path.
> https://github.com/audacity/audacity/commit/90738ce
>
> Bug 1304 - Starting Save or Export directory is not set, so is unwrit...
> https://github.com/audacity/audacity/commit/e9b9fcb
>
> Script tweaks.  …
> https://github.com/audacity/audacity/commit/29a392f
>
>
> The script tweaks are not germane.
>
> The 90738ce patch fixes the duff temporary directory that Peter saw.  If
> we have a long path to the temp directory, we now make sure all the
> intermediate directories exist.  Previously Mkdir could fail if the
> parent did not exist.
> The reduced search path is removing a path for searching the dmg that we
> don't need anymore.  Everything should be in the .app. and we could just
> ship the app.
>
>
>> I do feel lines of enquiry with sleep or retry are very much open.
> Great.  Look forward to something coming out of that.
>
>>
>>> More reasons: We are now, I think, committed to all in the app.  You
>>> said you thought we would need to go in that direction in time in any
>>> case.  We are all in the app in git now, and surely will be for 2.1.3.
>>> jc10 is helping to make sure that all in the app does actually work.
>> OK but it's about my testing priorities. I think for the next couple of
>> days mine should be on any new 1567 fixes Paul (or you?) come
>> up with, and looking at Peter's LAME issue.
> Fine with that.  Having Peter's testing of jc10 is giving me good
> confidence in the latest commits, and also that I am building and
> signing correctly.  The latest commits will now be in nightlies anyway,
> so will get tested.
>
>> With others testing your latest jc's I didn't think there was anything
>> in them that I really needed to test, especially if we are able to
>> fix 1567 another way.
>>
>> So let me know if there is anything here I really should try.
> What Peter and others are doing is enough.  It will for example pick up
> any major issue with signing.
>
>>
>>> A specific problem of the 'better fix' based on symlinks is that on
>>> affected systems, the one time in 16 that they don't work the first time
>>> is not addressed.
>> I totally agree. For that reason symlinks is not actually in my
>> "better fix" category, unless Paul does a single symlink to
>> to the configuration folder and somehow makes the link
>> still get created even if the bug triggers first time.
>>
>> Are we sure there is no way to ship a single symlink with
>> Audacity, or at least have the DMG create it when dragging
>> Audacity from the DMG to its target location?
> I think both are unlikely.  If they were possible they would likely be
> fragile.
>
>
>>   > My understanding is that Portable Settings and jc10
>>> does in fact address that.  At the moment Portable Settings is closer to
>>> being a releasable solution than the solutions we are hoping for.
>> That depends on the weight put on preserving user settings,
>> where we have different opinions.
>>
>>
>>>> Can you explain more about this version please. Are you saying
>>>> that in this version, we still have an optional Portable Settings
>>>> feature where users can have different settings, and that
>>>> upgraders won't lose their settings? .
>>> in jc10 Portable Settings are the default.
>>> This (currently) makes audacity effectively single user, and upgraders
>>> lose settings.
>>>
>>> Users who want to be multi user need to delete portable settings, and
>>> after doing that on systems that have the 1567 problem they probably
>>> still need the xattr solution.  At least we can give user instructions
>>> to do this, while the majority of users, who do not need to be multi
>>> user, are protected from the 1567 problem without taking any extra steps
>>> (which they might not read).
>> What about a single user who wants to turn on/off a different set
>> of settings, which is possible with the Portable Settings feature in
>> 2.1.2. Is that feature lost in jc10?
> How do they turn the settings on or off in 2.1.2?

Turn off by renaming the "Portable Settings" folder to something else.

Rename back to "Portable Settings" to turn back on.


>>>> I think we could be quite close to a proper fix for 1567 that
>>>> does not involve messing with Portable Settings or symlinks.
>>>> There must be some significance in false starting Audacity
>>>> curing the bug.
>>> I'm glad of that, but less optimistic.
>> Can you be specific why you are less optimistic?
> Because writing audacity.cfg just once on exit does not help.
> Frequent rewriting / flush seemed to me the most promising lead as to
> the root cause.  It is the kind of thing where antivirus/gatekeeper
> might want to check every single write and say 'too much, too quick, I
> give up' and so block access in some way.

Startup being "too fast" could be the problem - we might not have
the sleep in the correct place where we tried it before.

Unless it is something else - e.g. Gatekeeper becomes "lenient"
if the app did not start correctly - a strange theory to me.


>>> At the moment the Portable Settings solution is the closest we have to a
>>> solution.
>>> If we want to we can improve it to help upgraders by copying the old
>>> config in, if there was no config already in portable settings.
>> We mean all three .cfg files, as I understand it. Yes loss of user
>> settings is my main problem with the "Portable Settings" fix. It
>> will be P1 for 2.1.4-alpha and it's veering on P1 now IMO, if left
>> unameliorated. It makes all the difference to me if we "ameliorate"
>> it.
>>
>> Copy or move, though? I understood you were concerned about
>> leaving behind .cfg files in the original configuration folder.
> I'm vacillating.
> Copy is almost 100% likely to not have the 1567 bug.
> Move has the advantage of being less confusing if the user ever deletes
> the "User Settings" audacity.cfg.  The settings from long ago don't
> suddenly reappear in use.

I would try move first if we go that route.


>>> Even on 1567 affected machines that can be expected to work 1/16 of
>>> the times on the first go, and if it does fail, the default config is no disaster -
>>> certainly a lesser disaster than 1567.
>>> It we want to, we can probably improve it to make it multi user using
>>> wxGetUserId() in the name/path of the config file.  For example we could
>>> have a folder 'User Settings' which is just like Portable settings, but
>>> uses the wxGetUserId(0 trick to keep configs separate.
>> So with that, and moving in the old .cfg files into the app, isn't that
>> very similar to my proposal I refer to at the start of this message?
>>
>> And couldn't we then retain the original purpose of Portable
>> Settings? The fix does not require a "Portable Settings" folder
>> as such.
> Indeed.  But if we can't get 'Portable Settings' to work properly, then
> we have no hope of getting 'User Settings' to work as described above.
> So fixing and checking 'Portable Settings' shipped on with Audacity is a
> necessary precursor to working on and shipping 'User Settings'
> defaulting on with Audacity.

OK.

>> It *does* (unless we stop it triggering some other way) require
>> the .cfg files to be somewhere inside the app (or there to be a
>> symlink in the app to the .cfg files, but I don't see that as a good
>> way forward right now).
> So we hold out for a better solution for a little longer.
>
>
>
>
>>
>>>> I don't know about LAME until I look into this. It looks like
>>>> a P1 to me if we can't make it work for Peter.
>>> Unsigned LAME may be insoluble.  So if it is a P1, that is a major problem.
>> Let's see. FFmpeg is also unsigned. If there is no problem with
>> FFmpeg then it is not a signing problem.
> If ffmpeg is sysexeced and LAME is dynlib loaded then it does not give
> hope for LAME.

Both are dynamically loaded if using Libraries Preferences.


Gale


--James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Gale
Administrator
In reply to this post by James Crook
On 3 January 2017 at 13:07, James Crook <[hidden email]> wrote:

> I've just shared a jc10 signed alpha with relevant people.
>
> This fixes the 2 Nyquist problems.  Nyquist effects now appear and can
> be used, and there aren't redundant Nyquist files in the dmg.
>
> This works for me (El Capitan) as guest user, downloading as guest,
> installing using admin authorisation, and then running as guest.
>
> Because it is using Portable Settings, I expect it not to have the
> problem that Gale saw.
> I've fixed http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 but as
> this is currently just in my GitBranch, I'm not marking that
> Devel-fixmade yet.
>
> The changes can be seen here:
> https://github.com/JamesCrook/audacity/commits/master
>
> However I am going to tidy them up and push -f the cleanup to my repo
> before I commit the changes to main.  These changes mean we do have a
> working Portable Settings option that also avoids bug 1567.
>
> This can be converted to not using portable settings by deleting the
> Portable Settings Folder.  I've tried this for guest and did not need to
> authorise to do so.
>
>
> This is looking promising to me.  I'm expecting issues:
> - LAME (unavoidable?)
> - Downloading as one user and installer, and then using as a different user.

Testing on Sierra.

As a general comment about jc10, I often have to wait a minute or so
for Gatekeeper verification when launching Audacity (two separate
progress dialogues appear one after the other). This is so even if only
one user is logged in. I don't see that delay in HEAD.

Downloading jc10 as Admin user, installing it (still as admin) in /Applications,
then logging in as Standard user and launching Audacity only works first
time for me. First time, I get the expected Gatekeeper warning that
Audacity was downloaded from the internet, I OK on that, and Audacity
launches fine.

Next and every subsequent launch, Gatekeeper says that Audacity is
damaged and can't be opened.

If (still as Standard user) I delete the Portable Settings folder, giving
Admin's username and password, then launch Audacity, I see the
warning that Audacity is from the internet. I OK that, then Audacity
launches and writes as expected to
/Users/standard/Library/Application Support/Audacity.

However next and every subsequent launch, I still get that warning about
the internet.

If I now add back (still as Standard user) a "Portable Settings" folder to
the bundle's "Contents" folder, I am back to being able to launch Audacity
just once before Gatekeeper gives the "damaged" notice.

If I log out of Standard and back into Admin, Admin then also gets the
"damaged" notice when launching Audacity. If as Admin I delete
Standard's "Portable Settings" folder,  then I can launch Audacity first
time with the internet warning, and subsequently with no warning.

I noticed that Admin only has Read permission on the Portable Settings
folder created by Standard. I tested that scenario in HEAD from a
few days ago ( https://github.com/audacity/audacity/commit/51f91f3 ) .

As Admin I was not stopped by Gatekeeper from launching Audacity with
a "Portable Settings" folder created by Standard, but I received a circular
issue being asked repeatedly to choose the temp dir because Admin
can never update audacity.cfg in the Portable Settings folder. I am
guessing that is all as expected but I want to retest when I have had
a break and think some more if we can do better. Comments welcome.
Does it boil down to documenting that whoever creates Portable Settings
must do so with 777 permissions if other users are to use Audacity?

On very brief testing, Paul's sleeps on exit and init as coded make some
impact on bug 1567 on my machine, without entirely preventing it. I still
see about 1 in 8 failures if Audacity is launched outside /Applications, but
I can go up to 25 to 40 launches from /Applications before the bug
triggers.

So I would like to suggest we tweak sleeps further (do we need retry?)
and that we won't need the fix of Audacity as single-user with a forced
Portable Settings folder, or User-Settings as amelioration of that. If so,
does that automatically remove the "damaged" and excessive verification
time problems encountered above?



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Signed jc10 Portable Settings dmg

Paul Licameli


On Fri, Jan 6, 2017 at 5:23 PM, Gale Andrews <[hidden email]> wrote:
On 3 January 2017 at 13:07, James Crook <[hidden email]> wrote:
> I've just shared a jc10 signed alpha with relevant people.
>
> This fixes the 2 Nyquist problems.  Nyquist effects now appear and can
> be used, and there aren't redundant Nyquist files in the dmg.
>
> This works for me (El Capitan) as guest user, downloading as guest,
> installing using admin authorisation, and then running as guest.
>
> Because it is using Portable Settings, I expect it not to have the
> problem that Gale saw.
> I've fixed http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 but as
> this is currently just in my GitBranch, I'm not marking that
> Devel-fixmade yet.
>
> The changes can be seen here:
> https://github.com/JamesCrook/audacity/commits/master
>
> However I am going to tidy them up and push -f the cleanup to my repo
> before I commit the changes to main.  These changes mean we do have a
> working Portable Settings option that also avoids bug 1567.
>
> This can be converted to not using portable settings by deleting the
> Portable Settings Folder.  I've tried this for guest and did not need to
> authorise to do so.
>
>
> This is looking promising to me.  I'm expecting issues:
> - LAME (unavoidable?)
> - Downloading as one user and installer, and then using as a different user.

Testing on Sierra.

As a general comment about jc10, I often have to wait a minute or so
for Gatekeeper verification when launching Audacity (two separate
progress dialogues appear one after the other). This is so even if only
one user is logged in. I don't see that delay in HEAD.

Downloading jc10 as Admin user, installing it (still as admin) in /Applications,
then logging in as Standard user and launching Audacity only works first
time for me. First time, I get the expected Gatekeeper warning that
Audacity was downloaded from the internet, I OK on that, and Audacity
launches fine.

Next and every subsequent launch, Gatekeeper says that Audacity is
damaged and can't be opened.

If (still as Standard user) I delete the Portable Settings folder, giving
Admin's username and password, then launch Audacity, I see the
warning that Audacity is from the internet. I OK that, then Audacity
launches and writes as expected to
/Users/standard/Library/Application Support/Audacity.

However next and every subsequent launch, I still get that warning about
the internet.

If I now add back (still as Standard user) a "Portable Settings" folder to
the bundle's "Contents" folder, I am back to being able to launch Audacity
just once before Gatekeeper gives the "damaged" notice.

If I log out of Standard and back into Admin, Admin then also gets the
"damaged" notice when launching Audacity. If as Admin I delete
Standard's "Portable Settings" folder,  then I can launch Audacity first
time with the internet warning, and subsequently with no warning.

I noticed that Admin only has Read permission on the Portable Settings
folder created by Standard. I tested that scenario in HEAD from a
few days ago ( https://github.com/audacity/audacity/commit/51f91f3 ) .

As Admin I was not stopped by Gatekeeper from launching Audacity with
a "Portable Settings" folder created by Standard, but I received a circular
issue being asked repeatedly to choose the temp dir because Admin
can never update audacity.cfg in the Portable Settings folder. I am
guessing that is all as expected but I want to retest when I have had
a break and think some more if we can do better. Comments welcome.
Does it boil down to documenting that whoever creates Portable Settings
must do so with 777 permissions if other users are to use Audacity?

On very brief testing, Paul's sleeps on exit and init as coded make some
impact on bug 1567 on my machine, without entirely preventing it. I still
see about 1 in 8 failures if Audacity is launched outside /Applications, but
I can go up to 25 to 40 launches from /Applications before the bug
triggers.

So I would like to suggest we tweak sleeps further (do we need retry?)
and that we won't need the fix of Audacity as single-user with a forced
Portable Settings folder, or User-Settings as amelioration of that. If so,
does that automatically remove the "damaged" and excessive verification
time problems encountered above?

It is very good to hear at last that the sleeps appear to have an effect on the probability of the bug.

I inserted one sleep near startup, in AudacityApp::InitTempDir, and another at shut-down, in AudacityApp::OnExit.  In each, I made the duration 1000 msec.

Not yet known:  is the reduced frequency of the problem due to one sleep or the other, or is the combination necessary?

You can easily edit those two occurrences of the number 1000 to experiment with longer intervals.

If the sleep at exit is the important one, and if you must lengthen that from one to several seconds, even so this might be acceptable.  The slightly odd-looking consequence might be that the Audacity icon is slow to disappear from the dock, but because the single-instance checker has been destroyed, that should mean you are not barred from starting up another instance of Audacity before the first disappears.

Surely a longer sleep at exit would be more tolerable than at startup.

PRL

 



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

James Crook
In reply to this post by Gale
On 1/6/2017 10:23 PM, Gale Andrews wrote:

> Testing on Sierra.
>
> As a general comment about jc10, I often have to wait a minute or so
> for Gatekeeper verification when launching Audacity (two separate
> progress dialogues appear one after the other). This is so even if only
> one user is logged in. I don't see that delay in HEAD.
Well....  HEAD is not signed, so there is no need for gatekeeper to work
out if a signature is valid and from a known individual.  That entails a
query to an Apple server.

I never see any noticeable delay with Gatekeeper verification, i.e. I
never see progress dialogs for it.  I get the 'Downloaded from the
internet' message on first run almost immediately.  Audacity can bounce
in the dock for a little while (seconds) while starting up before any
dialog appears.  I've had it bounce a little frantically when it's
popped up a dialog behind some other, such as behind Safari, that I
haven't responded to.  It did that for the missing temp directory error
message.

I think the SLOW Gatekeeper verification could be significant.  It is
worth finding out if it is correlated with Sierra machines that have
your problem.

I changed the title of the thread as I think slow gatekeeper is a new topic.




--------------------
> Downloading jc10 as Admin user, installing it (still as admin) in /Applications,
> then logging in as Standard user and launching Audacity only works first
> time for me. First time, I get the expected Gatekeeper warning that
> Audacity was downloaded from the internet, I OK on that, and Audacity
> launches fine.
>
> Next and every subsequent launch, Gatekeeper says that Audacity is
> damaged and can't be opened.

> If (still as Standard user) I delete the Portable Settings folder, giving
> Admin's username and password, then launch Audacity, I see the
> warning that Audacity is from the internet. I OK that, then Audacity
> launches and writes as expected to
> /Users/standard/Library/Application Support/Audacity.
>
> However next and every subsequent launch, I still get that warning about
> the internet.
Sounds like the quarantine marker was created by admin, and standard
user elevating to approve it is unable to delete it.

So we need to give clear instructions that the user who downloads
Audacity must also be the one who first runs it an approves it (possibly
elevating to do so).

That is how MOST users will do it, but we should spell that out.



> If I now add back (still as Standard user) a "Portable Settings" folder to
> the bundle's "Contents" folder, I am back to being able to launch Audacity
> just once before Gatekeeper gives the "damaged" notice.
>
> If I log out of Standard and back into Admin, Admin then also gets the
> "damaged" notice when launching Audacity. If as Admin I delete
> Standard's "Portable Settings" folder,  then I can launch Audacity first
> time with the internet warning, and subsequently with no warning.
>
> I noticed that Admin only has Read permission on the Portable Settings
> folder created by Standard. I tested that scenario in HEAD from a
> few days ago ( https://github.com/audacity/audacity/commit/51f91f3 ) .
I think this still all boils down to the same rule about downloader must
do first run?

Ownership of files as well as the permission flags seem to matter.
That may apply to 'Portable Settings' folder, and seems to apply to
quarantine lock file (or whatever terminology they use for it).


> As Admin I was not stopped by Gatekeeper from launching Audacity with
> a "Portable Settings" folder created by Standard, but I received a circular
> issue being asked repeatedly to choose the temp dir because Admin
> can never update audacity.cfg in the Portable Settings folder. I am
> guessing that is all as expected but I want to retest when I have had
> a break and think some more if we can do better. Comments welcome.
> Does it boil down to documenting that whoever creates Portable Settings
> must do so with 777 permissions if other users are to use Audacity?
I've been building the dmg with a 'Portable Settings' 777'd directory.  
If a user creates it and wants others to use it, they HAVE to give it
permissions so that the others can.  I am sure that is not new to
2.1.3.  Not  a gatekeeper issue, but rather a permissions issue.


--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

Gale
Administrator
James Crook wrote
On 1/6/2017 10:23 PM, Gale Andrews wrote:

> Testing on Sierra.
>
> As a general comment about jc10, I often have to wait a minute or so
> for Gatekeeper verification when launching Audacity (two separate
> progress dialogues appear one after the other). This is so even if only
> one user is logged in. I don't see that delay in HEAD.
Well....  HEAD is not signed, so there is no need for gatekeeper to work
out if a signature is valid and from a known individual.  That entails a
query to an Apple server.

I never see any noticeable delay with Gatekeeper verification, i.e. I
never see progress dialogs for it.  I get the 'Downloaded from the
internet' message on first run almost immediately.  Audacity can bounce
in the dock for a little while (seconds) while starting up before any
dialog appears.  I've had it bounce a little frantically when it's
popped up a dialog behind some other, such as behind Safari, that I
haven't responded to.  It did that for the missing temp directory error
message.

I think the SLOW Gatekeeper verification could be significant.  It is
worth finding out if it is correlated with Sierra machines that have
your problem.
So Cliff, others on Sierra who don't have bug 1567, can you download
some apps that are Developer-ID signed but not from the App Store
and see how long Gatekeeper takes to verify? Two you can try are VLC
and Brackets.  

I find those two take about 40 seconds to verify if Admin installs and
runs them and over a minute if Admin installs them then Standard User
runs them AND again over a minute if Admin subsequently runs them.
This is comparable to the Audacity timings.      

James Crook wrote
I changed the title of the thread as I think slow gatekeeper is a new topic.

Gale wrote:
> Downloading jc10 as Admin user, installing it (still as admin) in /Applications,
> then logging in as Standard user and launching Audacity only works first
> time for me. First time, I get the expected Gatekeeper warning that
> Audacity was downloaded from the internet, I OK on that, and Audacity
> launches fine.
>
> Next and every subsequent launch, Gatekeeper says that Audacity is
> damaged and can't be opened.

> If (still as Standard user) I delete the Portable Settings folder, giving
> Admin's username and password, then launch Audacity, I see the
> warning that Audacity is from the internet. I OK that, then Audacity
> launches and writes as expected to
> /Users/standard/Library/Application Support/Audacity.
>
> However next and every subsequent launch, I still get that warning about
> the internet.
Sounds like the quarantine marker was created by admin, and standard
user elevating to approve it is unable to delete it.

So we need to give clear instructions that the user who downloads
Audacity must also be the one who first runs it an approves it (possibly
elevating to do so).

That is how MOST users will do it, but we should spell that out.
Testing the same way with VLC and Brackets downloaded from outside the
App Store (install as Admin, run as Standard) I don't get "damaged" on
second run as Standard, so I think this is not "normal".

Also jc4 does the same, so it isn't anything specific to Portable Settings.

Does anyone else get "damaged" on second run?

Also are you still sure it's right that I see:

mac gale$ spctl --assess -v /Applications/Brackets.app  
/Applications/Brackets.app: accepted
source=Developer ID

Gales-Mac-mini:~ gale$ spctl --assess -v /Applications/VLC.app
/Applications/VLC.app: accepted
source=Developer ID

but (with jc10):

Gales-Mac-mini:~ gale$ spctl --assess -v /Applications/Audacity.app
/Applications/Audacity.app: a sealed resource is missing or invalid
 

James Crook wrote
Gale wrote:
> If I now add back (still as Standard user) a "Portable Settings" folder to
> the bundle's "Contents" folder, I am back to being able to launch Audacity
> just once before Gatekeeper gives the "damaged" notice.
>
> If I log out of Standard and back into Admin, Admin then also gets the
> "damaged" notice when launching Audacity. If as Admin I delete
> Standard's "Portable Settings" folder,  then I can launch Audacity first
> time with the internet warning, and subsequently with no warning.
>
> I noticed that Admin only has Read permission on the Portable Settings
> folder created by Standard. I tested that scenario in HEAD from a
> few days ago ( https://github.com/audacity/audacity/commit/51f91f3 ) .
I think this still all boils down to the same rule about downloader must
do first run?
Well, I am questioning that in itself is a valid rule.


James Crook wrote
Ownership of files as well as the permission flags seem to matter.
That may apply to 'Portable Settings' folder, and seems to apply to
quarantine lock file (or whatever terminology they use for it).

Gale wrote:
> As Admin I was not stopped by Gatekeeper from launching Audacity with
> a "Portable Settings" folder created by Standard, but I received a circular
> issue being asked repeatedly to choose the temp dir because Admin
> can never update audacity.cfg in the Portable Settings folder. I am
> guessing that is all as expected but I want to retest when I have had
> a break and think some more if we can do better. Comments welcome.
> Does it boil down to documenting that whoever creates Portable Settings
> must do so with 777 permissions if other users are to use Audacity?
I've been building the dmg with a 'Portable Settings' 777'd directory.  
If a user creates it and wants others to use it, they HAVE to give it
permissions so that the others can.  I am sure that is not new to
2.1.3.  Not  a gatekeeper issue, but rather a permissions issue.
I agree on that - we just never considered it before.  

And it seems the endless loop where you can never change the
Audacity temp dir and so can never launch Audacity only happens if
audacity.cfg points to a temp dir that the user has no write permission
on *and* the user has no permission to write to audacity.cfg.

So that's all correct. It looks to me that any user can right-click over
Portable Settings > Get Info, give the Admin name and password,
then changing all three "Names" they see (assuming a single user
setup) to "Read&Write", that gives the desired 777 permissions:
   
Gales-Mac-mini:mac gale$ stat -f '%A %a %N' /Applications/Audacity.app/Contents/Portable\ Settings
777 1484276045 /Applications/Audacity.app/Contents/Portable Settings    


Gale
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

Cliff Scott

On Jan 12, 2017, at 9:22 PM, Gale <[hidden email]> wrote:


I think the SLOW Gatekeeper verification could be significant.  It is 
worth finding out if it is correlated with Sierra machines that have 
your problem.

So Cliff, others on Sierra who don't have bug 1567, can you download 
some apps that are Developer-ID signed but not from the App Store 
and see how long Gatekeeper takes to verify? Two you can try are VLC
and Brackets.   

I find those two take about 40 seconds to verify if Admin installs and 
runs them and over a minute if Admin installs them then Standard User
runs them AND again over a minute if Admin subsequently runs them. 
This is comparable to the Audacity timings.      

So I'm looking to see how long it takes to startup the first time?

I already am using VLC, but I can trash what I have and install new. Will be interesting if that makes any difference.

Re: Brackets, I'm not familiar with that one. A search came up with a text editor. Is that the one you are referring to? Link: brackets.io?

Cliff


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

Gale
Administrator
Cliff Scott wrote
> On Jan 12, 2017, at 9:22 PM, Gale <[hidden email]> wrote:
>
>>
>> I think the SLOW Gatekeeper verification could be significant.  It is
>> worth finding out if it is correlated with Sierra machines that have
>> your problem.
>
> So Cliff, others on Sierra who don't have bug 1567, can you download
> some apps that are Developer-ID signed but not from the App Store
> and see how long Gatekeeper takes to verify? Two you can try are VLC
> and Brackets.  
>
> I find those two take about 40 seconds to verify if Admin installs and
> runs them and over a minute if Admin installs them then Standard User
> runs them AND again over a minute if Admin subsequently runs them.
> This is comparable to the Audacity timings.      

So I'm looking to see how long it takes to startup the first time?
Thanks, Cliff. You're looking to see after launching the downloaded app first
time, how long it takes before you see the Gatekeeper warning that the
app is downloaded from the internet. That 40 seconds or more I mention
above is how long I wait before I see the internet warning. During the wait,
I see two separate Gatekeeper dialogs "Verifying...".


Cliff Scott wrote
 
I already am using VLC, but I can trash what I have and install new. Will be interesting if that makes any difference.

Re: Brackets, I'm not familiar with that one. A search came up with a text editor. Is that the one you are referring to? Link: http://brackets.io/   
Yes that is the one.

TwistedWave from https://twistedwave.com/mac.html could also be tested.
It is presumably Developer ID-signed because it is also in the AppStore.    

Also it would be good if you could test, with Developer ID-signed apps that
have no spctl error, the case where the user running the app is not the user
who installed it.  To do that, install as Admin but then switch to Standard user
and launch as that user.  Is the app reported damaged on second launch?
Do you see that "damaged" problem yourself with jc10, as I do?  

Note if you already installed and ran jc10 or some other app as the same
user, it's best to download it again before testing. Ideally, download from
somewhere else if the app has a list of download mirrors, or if you have a
server you can upload to and download from, though I don't think that is
actually crucial.

Thanks,

 
Gale

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

Cliff Scott
Gale,

See below.

> On Jan 13, 2017, at 6:48 PM, Gale <[hidden email]> wrote:
>
> Cliff Scott wrote
>>> On Jan 12, 2017, at 9:22 PM, Gale &lt;
>
>> gale@
>
>> &gt; wrote:
>>>
>>>>
>>>> I think the SLOW Gatekeeper verification could be significant.  It is
>>>> worth finding out if it is correlated with Sierra machines that have
>>>> your problem.
>>>
>>> So Cliff, others on Sierra who don't have bug 1567, can you download
>>> some apps that are Developer-ID signed but not from the App Store
>>> and see how long Gatekeeper takes to verify? Two you can try are VLC
>>> and Brackets.  
>>>
>>> I find those two take about 40 seconds to verify if Admin installs and
>>> runs them and over a minute if Admin installs them then Standard User
>>> runs them AND again over a minute if Admin subsequently runs them.
>>> This is comparable to the Audacity timings.      
>>
>> So I'm looking to see how long it takes to startup the first time?
>
> Thanks, Cliff. You're looking to see after launching the downloaded app
> first
> time, how long it takes before you see the Gatekeeper warning that the
> app is downloaded from the internet. That 40 seconds or more I mention
> above is how long I wait before I see the internet warning. During the wait,
> I see two separate Gatekeeper dialogs "Verifying...".
>

Both VLC and Brackets take about 5-6 seconds, Twistedwave about 2 seconds. Depending on the app I usually see about those same times when I've installed on El Capitan and now on Sierra. When I install LibreOffice it takes longer, but it is a very large program. Haven't timed it, but guessing from memory 10-15 seconds max and maybe less. 40 seconds is VERY strange. I don't think your machine could be that much slower than mine. I'm running a MacBook Pro with 2.3Ghz i7 CPU, SSD and 16GB memory.

>
>
> Cliff Scott wrote
>>
>> I already am using VLC, but I can trash what I have and install new. Will
>> be interesting if that makes any difference.
>>
>> Re: Brackets, I'm not familiar with that one. A search came up with a text
>> editor. Is that the one you are referring to? Link: http://brackets.io/   
>
> Yes that is the one.
>
> TwistedWave from https://twistedwave.com/mac.html could also be tested.
> It is presumably Developer ID-signed because it is also in the AppStore.    
>
> Also it would be good if you could test, with Developer ID-signed apps that
> have no spctl error, the case where the user running the app is not the user
> who installed it.  To do that, install as Admin but then switch to Standard
> user
> and launch as that user.  Is the app reported damaged on second launch?
> Do you see that "damaged" problem yourself with jc10, as I do?  
>
> Note if you already installed and ran jc10 or some other app as the same
> user, it's best to download it again before testing. Ideally, download from
> somewhere else if the app has a list of download mirrors, or if you have a
> server you can upload to and download from, though I don't think that is
> actually crucial.
>

I've only seen one app that had the damaged warning in all the time I've used a MAC, muCommander (unsigned). A java based file handling utility. I saw the problem El Capitan as well as Sierra. It installs in a folder as Audacity used to. Gatekeeper would yell when trying to open if I pulled the app out of the folder to run it. Leaving the app in the folder and executing from within there worked on El Capitan and by playing with it I finally got it out of the folder and it would still run, but on Sierra I had to make an Alias to get it to run. When I upgraded my El Capitan to Sierra I installed Sierra from scratch then used the Migration utility to move data/apps from El Capitan. When I did that I didn't have to use the Alias any more and also it is not within its original folder anymore.

Ran as Standard user and no issues with any of the apps. For Twistedwave I downloaded and installed as Admin, but opened it in Standard User for the first time and no problem.

Audacity jc10 fresh install no issues as admin or as standard user. It finds the Effects and libraries just fine in Standard User. Didn't do it a bunch of times, but several. I can go back and pound on it if you wish.

Wish I could be of more help.

Cliff


> Thanks,
>
>
> Gale
>
>
>
>
>
> --
> View this message in context: http://audacity.238276.n2.nabble.com/Signed-jc10-Portable-Settings-dmg-tp7577672p7577782.html
> Sent from the audacity-quality mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper (was Signed jc10 Portable Settings dmg)

Gale
Administrator
Cliff Scott wrote
Gale,

See below.

> On Jan 13, 2017, at 6:48 PM, Gale <[hidden email]> wrote:
>
> Cliff Scott wrote
>>> On Jan 12, 2017, at 9:22 PM, Gale <
>
>> gale@
>
>> > wrote:
>>>
>>>>
>>>> I think the SLOW Gatekeeper verification could be significant.  It is
>>>> worth finding out if it is correlated with Sierra machines that have
>>>> your problem.
>>>
>>> So Cliff, others on Sierra who don't have bug 1567, can you download
>>> some apps that are Developer-ID signed but not from the App Store
>>> and see how long Gatekeeper takes to verify? Two you can try are VLC
>>> and Brackets.  
>>>
>>> I find those two take about 40 seconds to verify if Admin installs and
>>> runs them and over a minute if Admin installs them then Standard User
>>> runs them AND again over a minute if Admin subsequently runs them.
>>> This is comparable to the Audacity timings.      
>>
>> So I'm looking to see how long it takes to startup the first time?
>
> Thanks, Cliff. You're looking to see after launching the downloaded app
> first
> time, how long it takes before you see the Gatekeeper warning that the
> app is downloaded from the internet. That 40 seconds or more I mention
> above is how long I wait before I see the internet warning. During the wait,
> I see two separate Gatekeeper dialogs "Verifying...".
>

Both VLC and Brackets take about 5-6 seconds, Twistedwave about 2 seconds. Depending on the app I usually see about those same times when I've installed on El Capitan and now on Sierra. When I install LibreOffice it takes longer, but it is a very large program. Haven't timed it, but guessing from memory 10-15 seconds max and maybe less. 40 seconds is VERY strange. I don't think your machine could be that much slower than mine. I'm running a MacBook Pro with 2.3Ghz i7 CPU, SSD and 16GB memory.
It's only a HDD Mac Mini from 2012 with 4 GB memory. But 10.10 Yosemite
on the same machine pops up the internet warning at once, as did Sierra
when first released. So we might assume it to be part of the same Gatekeeper
issue that affects some Macs from 10.12.1 onwards.  


Cliff Scott wrote
> Cliff Scott wrote
>>
>> I already am using VLC, but I can trash what I have and install new. Will
>> be interesting if that makes any difference.
>>
>> Re: Brackets, I'm not familiar with that one. A search came up with a text
>> editor. Is that the one you are referring to? Link: http://brackets.io/   
>
> Yes that is the one.
>
> TwistedWave from https://twistedwave.com/mac.html could also be tested.
> It is presumably Developer ID-signed because it is also in the AppStore.    
>
> Also it would be good if you could test, with Developer ID-signed apps that
> have no spctl error, the case where the user running the app is not the user
> who installed it.  To do that, install as Admin but then switch to Standard
> user
> and launch as that user.  Is the app reported damaged on second launch?
> Do you see that "damaged" problem yourself with jc10, as I do?  
>
> Note if you already installed and ran jc10 or some other app as the same
> user, it's best to download it again before testing. Ideally, download from
> somewhere else if the app has a list of download mirrors, or if you have a
> server you can upload to and download from, though I don't think that is
> actually crucial.
>

I've only seen one app that had the damaged warning in all the time I've used a MAC, muCommander (unsigned). A java based file handling utility. I saw the problem El Capitan as well as Sierra. It installs in a folder as Audacity used to. Gatekeeper would yell when trying to open if I pulled the app out of the folder to run it. Leaving the app in the folder and executing from within there worked on El Capitan and by playing with it I finally got it out of the folder and it would still run, but on Sierra I had to make an Alias to get it to run. When I upgraded my El Capitan to Sierra I installed Sierra from scratch then used the Migration utility to move data/apps from El Capitan. When I did that I didn't have to use the Alias any more and also it is not within its original folder anymore.

Ran as Standard user and no issues with any of the apps. For Twistedwave I downloaded and installed as Admin, but opened it in Standard User for the first time and no problem.

Audacity jc10 fresh install no issues as admin or as standard user. It finds the Effects and libraries just fine in Standard User. Didn't do it a bunch of times, but several. I can go back and pound on it if you wish.

Wish I could be of more help.

Cliff
Thanks for testing. I don't believe you'll see bug 1567 on your machine so
don't worry about it. Perhaps your machine is simply "too fast".

I am not quite clear though, when you fresh downloaded jc10 and installed
it in /Applications, was that as Admin, and did you then switch to Standard
user, launch Audacity once, quit then relaunch? That would result in "damaged"
for me, and Audacity is the only app that does that to me if installed as Admin
and run as Standard.  

I don't think fixing bug 1567 will directly fix that "damaged" issue. It happens
to me on 10.12.0, which doesn't exhibit bug 1567. I think we may have to
track this as an issue, so we need to know how widely it occurs.


Gale


> View this message in context: http://audacity.238276.n2.nabble.com/Signed-jc10-Portable-Settings-dmg-tp7577672p7577782.html
> Sent from the audacity-quality mailing list archive at Nabble.com.
>
12
Loading...