Ah, I misunderstood the question. AFAICT homebrew does not adversely affect
the sage built. In particular, I was able to successfully build it several
times with 7.5.betaX 7.5.rcX and 7.5, on two separate machines (on which I
also have HB installed).
--
Konstantin Kliakhandler
http://slumpy.org
)°) )°( (°(
On 25 January 2017 at 00:42, John H Palmieri <jhpalmier...@gmail.com> wrote:
> 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> 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/uns
>>>>>>>> ubscribe.
>>>>>>>> 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/to
>>>>> pic/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/to
>>> pic/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.
>>>
>> --
>>
>>
>> Konstantin Kliakhandler
>> Sent on the go
>>
> --
> 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/to
> pic/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.
>
--
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.
