On Wed, 20 Mar 2019 14:08 Ivan Andrus, <darthand...@gmail.com> wrote:
> On Mar 19, 2019, at 4:01 AM, dimp...@gmail.com wrote: > > > Hi Ivan, > thanks for looking into this. > On Mon, Mar 18, 2019 at 06:25:53PM -0700, Ivan Andrus wrote: > > I haven't worked on Sage for quite a while, but it was brought to my > attention (thanks Karl-Dieter), that the Mac application no longer works > on > Mojave. I believe this has to do with the fact that the application isn't > signed by a registered developer. I say this because starting it from the > command line (e.g. $ /Applications/SageMath-8.5.app/Contents/MacOS/Sage) > starts > up instantly and, as near as I can tell, perfectly. However, when I > double > click in the Finder, it gets stuck (for a very long time--maybe 10 > minutes) > in _LSResolveAllQuarantineItems(...) in [NSWorkspace > openFile:withApplication:andDeactivate:]. Ten minutes may not be forever, > but it's certainly longer than we should require people to wait, > especially > given that it's every time they launch the app. > > This explains that weird delays people mentioned which using the app, > another "clever" OSX joke... > > I can think of a few options that might be able to solve the problem: > > 1. We could start signing the code. However, I don't think signing it > will be possible since one of the first things that happens when running > sage is that it changes the paths embedded in certain executables (at > least > that's what I remember). Changing anything in the application (code or > resources [1]) would invalidate the signing, so I think that's out. > > > it's a technological problem here: as LD_LIBRARY_PATH using was no > longer possible on OSX (and it's a hassle anyway), Volker's > https://github.com/sagemath/binary-pkg > builds a distribution with paths being templates, that are replaced > with actual paths once the installation is known. > > What would be the correct way to achieve this on OSX? > Simply assume that Sage must be installed in /Applications/SageMath > and build the distibution with the whole absolute paths known in > advance -- surely this could be signed then, no? > Or there is something more clever? > > > That's an option I hadn't thought of. It seems pretty restrictive to me, > but probably most people install it there anyway. > My admittedly limited experience with Mac OS apps is that they are restricted to installing to a fixed location on a volume, at most one can choose the volume to install to. E.g. python.org python installers install on the boot volume in /Applications/. I think advanced users who need more than one copy of Sage can just use a non-app installer. > > 2. We may be able to replace our use of [NSWorkspace > openFile:withApplication:andDeactivate:] with something else, perhaps > using > system(). I haven't tried this, so I have no idea if it will work. > 3. We could move to a two-item approach in which we provide the app > *without* sage embedded inside it (so it's very small and could be > signed, or not), and then we provide the sage distribution separately > (could be in the same dmg file, just not embedded). For a long time, the > application has had the ability to use to any sage installation. > However, > it might be difficult to automatically point people to the latest > installation (i.e. they would have to go into the app preferences and > change it themselves). We could offer some sort of installer that would > copy the sage distribution and make that change for the current user. > Perhaps sysadmins could just create a symlink to the latest or > something. > I'm not sure what problems we've seen people have in this area. Also, > you > would probably lose the ability to run multiple versions of the app to > quickly switch back and forth. > 4. Create an AppleScript (or Terminal) launcher that just runs a > variation of the script below [2] rather than starting the app directly. > This seems to work fine, but is somewhat annoying to need a different > launcher. This can hopefully work as a stop-gap for those who have this > problem right now. > > In my opinion #3 is the most promising. How bad is #3 from a user > experience perspective? I used to always run it that way, so it's not a > problem for me, but I've been out of the loop for a while, and my > experience might not be typical. What problems do people foresee with > integrating any of these with the build system? Right now I'm not able to > build sage. I haven't dug into why, but I can if need be. Unfortunately, > I don't know how much time I'll be able to devote to working on this so > any > help would be appreciated. > > > Another still not completely resolved, issue is openssl. The current > Python.org' Python OSX installer papers over it in a laughable (IMHO) > way: https://bugs.python.org/issue36344 > (TLDR: they package fully functional pip, with all certs etc. as > well as openssl, broken by not having cert.pem in the right place, and > "fix" this by calling a special script that calls pip to install > cert.pem into the right place, even though this cert is already there in > the installer, in pip, to be precise!) > Perhaps it's meant to satisfy a (not very smart) lawyer, I don't know... > > If you have ideas about the latter, it would be good, too. > > > Gaa. Openssl is indeed a mess. I'm not sure what to do about that. > > -Ivan > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
