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/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 :
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/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
<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
<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/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+...@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/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+...@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.
