The question is, if you have homebrew installed, can you build Sage from source? That is, extract the source tarball, type 'make' in the sage directory, and have it complete successfully. I think the motivation behind the question is, in the past, the presence of fink or macports prevented Sage from building correctly, so it is natural to wonder what happens with homebrew.
John On Tuesday, January 24, 2017 at 1:51:41 PM UTC-8, Kosta wrote: > > I'm not sure exactly what you mean; I am able to *install* sage via > homebrew - what it does is effectively download the .dmg archive and unpack > it in an appropriate location. There is no homebrew package for building > sage from source, however. I can (probably) make one if necessary, however. > > On Thu, 19 Jan 2017 at 18:52 Dima Pasechnik <dim...@gmail.com > <javascript:>> wrote: > >> Are you able to build Sage under/in homebrew? >> >> >> On Thursday, January 19, 2017 at 3:01:49 PM UTC, Kosta wrote: >> >>> Right now (pre-ticket) if you try to build sage on OSX Sierra and above, >>> it will be built without >>> OpenSSL support. I'm not sure what happens if you download a prebuilt >>> package but somehow I assumed >>> that if you don't have OpenSSL installed, then you can't use OpenSSL >>> (otherwise I don't understand >>> the whole discussion re GPL/OpenSSL). My comment regarding installing >>> sage via homebrew is with this >>> in mind, since right now it simply automatically installs the prebuilt >>> package. >>> >>> The ticket addresses the building issue - it looks for the headers in a >>> user specified location (in an environment variable) if it is defined, and >>> otherwise in the location that homebrew installs to. >>> >>> -- >>> Konstantin Kliakhandler >>> http://slumpy.org >>> )°) )°( (°( >>> >>> On 18 January 2017 at 20:56, Dima Pasechnik <dim...@gmail.com> wrote: >>> >>>> >>>> >>>> On Wednesday, January 18, 2017 at 1:20:20 PM UTC, Emmanuel Charpentier >>>> wrote: >>>>> >>>>> I'm not sure to understand the ticket. Does that means that OS X Sage >>>>> will depend on Apple's SSL library ? Or depend on a systemwide OpenSSL ? >>>>> Or >>>>> am I mistaken entirely ? >>>>> >>>>> Apple still sneakily ships OpenSSL headers in XCode, for some sort of >>>> upgrading tools, I guess. >>>> The location is unstable, though, it chnages from one version of XCode >>>> to another :-) >>>> >>>> Using homebrew to build Sage on OSX isn't well-explored, IMHO. It might >>>> work, given some effort is made. >>>> >>>> >>>> >>>>> -- >>>>> Emmanuel Charpentier >>>>> >>>>> Le lundi 16 janvier 2017 21:07:40 UTC+1, Kosta a écrit : >>>>>> >>>>>> Regarding OSX, take a look at ticket 21944 >>>>>> <https://trac.sagemath.org/ticket/21944> [basically a way to either >>>>>> specify where to find the openssl headers or to use the homebrew headers >>>>>> if >>>>>> available]. >>>>>> >>>>>> The homebrew package can be made to depend on the openssl package. >>>>>> Finally, regarding packaged .app - I don't know. I think it would be >>>>>> reasonable to prompt the user about this issue if the dynamic library is >>>>>> not found. I may be wrong, but I think that in recent years homebrew has >>>>>> become the de-facto package manager and in older OS versions openssl was >>>>>> present, so it would be fairly reasonable to just prompt the user to >>>>>> install homebrew and then install via homebrew. >>>>>> >>>>>> Cheers, >>>>>> Kosta >>>>>> >>>>>> -- >>>>>> Konstantin Kliakhandler >>>>>> http://slumpy.org >>>>>> )°) )°( (°( >>>>>> >>>>>> On 15 January 2017 at 15:51, Emmanuel Charpentier < >>>>>> emanuel.c...@gmail.com> wrote: >>>>>> >>>>>>> A first step <https://trac.sagemath.org/ticket/22058> towards a >>>>>>> solution awaits your comments and review. >>>>>>> >>>>>>> Plan : >>>>>>> >>>>>>> 1. Document OpenSSL dependency, mention the possibility of >>>>>>> compiling againts GnuTLS (with drawbacks) >>>>>>> 2. Get OpenSSL development libs on the machines producing Unix >>>>>>> binary tarballs/packages. >>>>>>> 3. (To be discussed) : create a standard "SSL" package serving >>>>>>> as a backup, allowing compilation on OpenSSL-less machines. As done >>>>>>> for >>>>>>> git, this package should do nothing if OpenSSL is installed >>>>>>> systemwide. >>>>>>> 4. Complete curl as a standard package, which would allow : >>>>>>> 5. Upgrade R. Pffeeeewww... >>>>>>> >>>>>>> Unsolved problem : What about Macs (I don't have a Mac and can't >>>>>>> contribute). >>>>>>> >>>>>>> To be discussed : Cygwin (advoce from Erik Bray keenly awaited...). >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> -- >>>>>>> Emmanuel Charpentier >>>>>>> >>>>>>> Le dimanche 1 janvier 2017 02:55:42 UTC+1, Emmanuel Charpentier a >>>>>>> écrit : >>>>>>>> >>>>>>>> Dear list, >>>>>>>> >>>>>>>> We have three separate, but interacting, difficulties with SSL/TLS >>>>>>>> support in Sage. I'll summarize the results of the efforts of several >>>>>>>> people who tracked them, and propose a couple of solutions. >>>>>>>> >>>>>>>> *I) Python now (discreetly) depends on Open SSL.* >>>>>>>> >>>>>>>> Their license page <https://docs.python.org/3/license.html> states >>>>>>>> : >>>>>>>> >>>>>>>>> The modules hashlib >>>>>>>>> <https://docs.python.org/3/library/hashlib-blake2.html#module-hashlib>, >>>>>>>>> >>>>>>>>> posix <https://docs.python.org/3/library/posix.html#module-posix>, >>>>>>>>> ssl <https://docs.python.org/3/library/ssl.html#module-ssl>, crypt >>>>>>>>> <https://docs.python.org/3/library/crypt.html#module-crypt> use >>>>>>>>> the OpenSSL library for added performance if made available by >>>>>>>>> the operating system. Additionally, the Windows and Mac OS X >>>>>>>>> installers for >>>>>>>>> Python may include a copy of the OpenSSL libraries, so we include a >>>>>>>>> copy of >>>>>>>>> the OpenSSL license here: >>>>>>>>> >>>>>>>> followed by the bizarre OpenSSL license. For our purpose, the >>>>>>>> important statement is *"use the OpenSSL library for added >>>>>>>> performance if made available by the operating system."*. >>>>>>>> >>>>>>>> "Added performance, my a^htired foot : Thierry has checked the >>>>>>>> possibilities of an OpenSSL-less Sage, and I have further checked >>>>>>>> other >>>>>>>> possibilities. Our trials conclusively demonstrate that Gnu TLS can't >>>>>>>> be >>>>>>>> substituted to OpenSSL for at least the following reasons : >>>>>>>> >>>>>>>> - Sage's pip is non-functionnal when compiled against Gnu TLS >>>>>>>> - Ditto for Sage's git >>>>>>>> - I understand (but have not checked) that Python's hashlib >>>>>>>> module, which depends on openssl, is used in Sage. >>>>>>>> >>>>>>>> >>>>>>>> However, contrary to my expectations, R 3.3.2 *can* be compiled in >>>>>>>> Sage against a curl library using Gnu TLS and keep a functional HTTPS >>>>>>>> access to R repositories. >>>>>>>> >>>>>>>> Consequences : >>>>>>>> >>>>>>>> - Sage *can*be built and run without OpenSSL support, (as long >>>>>>>> as R is < 3.3 or some SSL support is available for R >= 3.3), but >>>>>>>> this >>>>>>>> system will have severe limitations (among others, no access to pip >>>>>>>> resources, questionable support for Sage's git). >>>>>>>> - OpenSSL can be retrofitted in such a system by installing the >>>>>>>> openssl package, but this retrofit becomes effective after >>>>>>>> recompilation of >>>>>>>> python2 (at least). >>>>>>>> >>>>>>>> This latter "solution" is, at best, a contraption (even if >>>>>>>> something in this direction has been proposed >>>>>>>> <https://groups.google.com/d/msg/sage-devel/iwrF8_kGLzM/aze9lJi8nm8J> >>>>>>>> back in 2012 to solve the very same problem). Therefore : >>>>>>>> >>>>>>>> - we *must at minimum* advertise this problem in the REAME.md >>>>>>>> file and recommend checking the presence of OpenSSL, and recommend >>>>>>>> the >>>>>>>> installation of openssl development files for Sage compilation. In >>>>>>>> this >>>>>>>> case, we would have to : >>>>>>>> - provide a standard package providing some HTTPS-capable >>>>>>>> SSL support. Ideally, this package should be able to check for >>>>>>>> the presence >>>>>>>> of suitable systemwide libraries, and in this case, do nothing ; >>>>>>>> - use this SSL support to provide an HTP-enabled curl for >>>>>>>> R>=3.3 (with again, the possibility of usinf a systemwide curl >>>>>>>> library). >>>>>>>> - We *should* acknowledge our *de facto* dependence on a >>>>>>>> systemwide OpenSSL (in terms close to those used by the Python >>>>>>>> license). In >>>>>>>> this case, we would have to provide a standard curl package, with >>>>>>>> the same >>>>>>>> provisions as before. >>>>>>>> >>>>>>>> The first solution, used on a system without OpenSSL, will create a >>>>>>>> crippled Sage. Furthermore, it needs writing two standard packages, >>>>>>>> installing widely-diffused utilities (it seems awfully difficult to >>>>>>>> install >>>>>>>> a Debian system *sans* OpenSSL : even a freshly installed "base >>>>>>>> system + common utilities" has openssl, on which Debian's reportbug >>>>>>>> and >>>>>>>> various utilities depend). >>>>>>>> >>>>>>>> I would rather acknowledge our dependence on OpenSSL, recommend its >>>>>>>> installation and advertise the limitations of an OpenSSL-less Sage, >>>>>>>> leaving >>>>>>>> this possibility open to prudes... >>>>>>>> >>>>>>>> *II) OpenSSL has broken a lot of software.* >>>>>>>> >>>>>>>> OpenSSL 1.1.0 has broken a lot of OpenSSL-using software *at the >>>>>>>> source level* (older binaries still can use the libraries, but the >>>>>>>> macro mechanisms used in source are not compatible with those used in >>>>>>>> OpenSSL 1.0.x, and compilations fail). >>>>>>>> >>>>>>>> This has happened in "our" Python ; our now-current 2.7.12 version >>>>>>>> does not compile against OpenSSL 1.1. A patch against this version, >>>>>>>> allowing compilation against OpenSSL 1.1 has been released after the >>>>>>>> version we used in Trac#19735 >>>>>>>> <https://trac.sagemath.org/ticket/19735>. I tried >>>>>>>> <https://trac.sagemath.org/ticket/22089> to port it in our current >>>>>>>> version, and failed miserably (someone with more experience than me >>>>>>>> should >>>>>>>> have wielded this chainsaw...). >>>>>>>> >>>>>>>> BTW, this has also happened to "our" git, which was easier to >>>>>>>> upgrade (see Trac#22058 <https://trac.sagemath.org/ticket/22058>, >>>>>>>> which needs review, BTW). >>>>>>>> >>>>>>>> This *is* a problem for us because OpenSSL 1.1 has now reached the >>>>>>>> stage of diffusion in commonly-used distributions (Debian testing, >>>>>>>> which >>>>>>>> means the next Ubuntu, etc...). It has been said that this move was >>>>>>>> (unduly) hastened by a nearing "freeze" in Debian testing ; true or >>>>>>>> not, >>>>>>>> the move has happened, and I don't fight the weather... >>>>>>>> (Interestingly, >>>>>>>> cygwin still is at openSSL-devel-1.0.2j). >>>>>>>> >>>>>>>> I think that our best bet is the upgrade proposed in Trac#22037 >>>>>>>> <https://trac.sagemath.org/ticket/22037>, whose development seems >>>>>>>> to have stopped dead in its tracks after sagemath has hit Debian >>>>>>>> unstable... This is especially important if we adopt the idea of >>>>>>>> openly >>>>>>>> depending on OpenSSL as a solution to I). >>>>>>>> >>>>>>>> *III) OpenSSL is problematic on Macintoshes.* >>>>>>>> >>>>>>>> (This is by hearsay : I do not have access to a Mac, and don't >>>>>>>> really understand the problem ; I'm tryin to summarize what I've read). >>>>>>>> >>>>>>>> Apple seems to have its own SSL implementation, and specific >>>>>>>> procedures for updating its collection of root certificates. This >>>>>>>> makes >>>>>>>> installing a Sage-specific SSL library problematic, and makes >>>>>>>> necessary a >>>>>>>> specific procedure fot root certificates maintenance. >>>>>>>> >>>>>>>> 1) I do not know if Apple's ssl implementation is sufficient for >>>>>>>> a) Sage and related utilities (Sage's pip, Saage's git, etc...) >>>>>>>> b) Curl (needed bty R>=3.3, see above). >>>>>>>> >>>>>>>> 2) It seems also difficult to develop an utility making Apple's >>>>>>>> root certificates usable by Sage. >>>>>>>> >>>>>>>> *Qiscussion and questions* >>>>>>>> >>>>>>>> In view of these difficulties, what should be done ? >>>>>>>> >>>>>>>> I think that our first priority should be to get a Python that will >>>>>>>> compile against OpenSSL>=1.1, which will become ubiquitous sooner or >>>>>>>> later >>>>>>>> (ant I think it will be sooner...). That means completing >>>>>>>> Trac#22037 <https://trac.sagemath.org/ticket/22037> as soon as >>>>>>>> possible. >>>>>>>> >>>>>>>> In parallel, we should document the SSL problem right at the >>>>>>>> startof teh README.md and in the developer's documentation (README.md >>>>>>>> and >>>>>>>> the Developer's Guide). I will propose a patch to these effect of >>>>>>>> these >>>>>>>> docs. >>>>>>>> >>>>>>>> The SSL-using parts of Sage should be reviewed, for answers to >>>>>>>> three questions : >>>>>>>> >>>>>>>> - do they compile against OpenSSL>1.1 on Linux (and other >>>>>>>> Unices) ? >>>>>>>> - do they compile efficiently (i. e. with full functionality) >>>>>>>> against Apple's SSL library ? >>>>>>>> - will they compile against a future OpenSSL>=1.1 on cygwin ? >>>>>>>> >>>>>>>> >>>>>>>> Platform-specific adaptations should be considered for both Macs >>>>>>>> and Windows. >>>>>>>> >>>>>>>> Questions : >>>>>>>> >>>>>>>> - Should we openly depend on OpenSSL ? If so, how to express it >>>>>>>> ? >>>>>>>> >>>>>>>> I'd vote for that, and for warning of the penalties involved by the >>>>>>>> non-use of OpenSSL, probably in terms close to those of the Python >>>>>>>> license. >>>>>>>> >>>>>>>> - Do we need a standard SSL package ? >>>>>>>> >>>>>>>> This is necessary to allow for R>3.3 if we do NOT openly depend on >>>>>>>> OpenSSL. That's the only way to allow to upgrade to R>3.3, which has >>>>>>>> become >>>>>>>> urgent... >>>>>>>> >>>>>>>> - How can we help completing Trac#22037 ? >>>>>>>> <https://trac.sagemath.org/ticket/22037> >>>>>>>> >>>>>>>> and, last but not least : >>>>>>>> >>>>>>>> - how can we help with the platform-specific aspects of this >>>>>>>> thorny problem ? >>>>>>>> >>>>>>>> Your advice, please ? >>>>>>>> >>>>>>>> HTH, >>>>>>>> >>>>>>>> -- >>>>>>>> Emmanuel Charpentier >>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to a topic in >>>>>>> the Google Groups "sage-devel" group. >>>>>>> To unsubscribe from this topic, visit >>>>>>> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe >>>>>>> . >>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>> sage-devel+...@googlegroups.com. >>>>>>> To post to this group, send email to sage-...@googlegroups.com. >>>>>>> Visit this group at https://groups.google.com/group/sage-devel. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "sage-devel" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> sage-devel+...@googlegroups.com. >>>> To post to this group, send email to sage-...@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/sage-devel. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "sage-devel" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> sage-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to sage-...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > > Konstantin Kliakhandler > Sent on the go > -- 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.
