That may be true, but IMHO this is already a specific issue of
incompatibility with a specific package, rather than a systemic
incompatibility with HB itself (e.g. as would be the case if HB relied on
said version of gfortran). I see it as no different than a situation where
the user installed gfortran manually somehow and it interfered with Sage's.
Also, if there will be a build-from-source variant in HB (which I am happy
to write if there is the demand), it can easily mark what packages it is
incompatible with.
--
Konstantin Kliakhandler
http://slumpy.org
)°) )°( (°(
On 25 January 2017 at 00:50, François Bissey <
francois.bis...@canterbury.ac.nz> wrote:
> It depend what compilers are exposed. Last time someone filled
> a bug, gfortran from brew was interfering with the gfortran sage
> installs. https://trac.sagemath.org/ticket/22112
>
> Francois
>
> On 25/01/17 11:46, Konstantin Kliakhandler wrote:
>
>> 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
>> <mailto: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/lic
>> ense.html>
>> states :
>>
>> The modules |hashlib|
>> <https://docs.python.org/3/lib
>> rary/hashlib-blake2.html#module-hashlib>,
>> |posix|
>> <https://docs.python.org/3/lib
>> rary/posix.html#module-posix>,
>> |ssl|
>> <https://docs.python.org/3/lib
>> rary/ssl.html#module-ssl>,
>> |crypt|
>> <https://docs.python.org/3/lib
>> rary/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/m
>> sg/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 :
>> o 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 ;
>> o 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/tic
>> ket/19735>.
>> I tried
>> <https://trac.sagemath.org/tic
>> ket/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/tic
>> ket/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/tic
>> ket/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/tic
>> ket/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/tic
>> ket/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/to
>> pic/sage-devel/jdLfIKQ1M18/unsubscribe
>> <https://groups.google.com/d/t
>> opic/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/grou
>> p/sage-devel
>> <https://groups.google.com/gro
>> up/sage-devel>.
>> For more options, visit
>> https://groups.google.com/d/optout
>> <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
>> <https://groups.google.com/d/t
>> opic/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
>> <https://groups.google.com/group/sage-devel>.
>> For more options, visit
>> https://groups.google.com/d/optout
>> <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/uns
>> ubscribe
>> <https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/un
>> subscribe>.
>> 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
>> <https://groups.google.com/group/sage-devel>.
>> For more options, visit https://groups.google.com/d/optout
>> <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/topic/sage-devel/jdLfIKQ1M18/unsubscribe
>> <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
>> <mailto:sage-devel+unsubscr...@googlegroups.com>.
>> To post to this group, send email to sage-devel@googlegroups.com
>> <mailto:sage-devel@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/sage-devel
>> <https://groups.google.com/group/sage-devel>.
>> For more options, visit https://groups.google.com/d/optout
>> <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
>> <mailto:sage-devel+unsubscr...@googlegroups.com>.
>> To post to this group, send email to sage-devel@googlegroups.com
>> <mailto: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 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.
