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 <dimp...@gmail.com> 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+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. > -- 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.
