On Sat, Feb 11, 2012 at 10:33 PM, John H Palmieri
wrote:
>
>
> On Saturday, February 11, 2012 8:39:32 PM UTC-8, Michael Orlitzky wrote:
>>
>> I've started this:
>>
>> http://wiki.sagemath.org/PiecewiseSymbolicSEP
>>
>> It's basically a brain dump at this point, but I can go back and clean
>> up
On Saturday, February 11, 2012 8:39:32 PM UTC-8, Michael Orlitzky wrote:
>
> I've started this:
>
>http://wiki.sagemath.org/PiecewiseSymbolicSEP
>
> It's basically a brain dump at this point, but I can go back and clean
> up specific ideas now with less overhead.
>
> I've also added a link a
I've started this:
http://wiki.sagemath.org/PiecewiseSymbolicSEP
It's basically a brain dump at this point, but I can go back and clean
up specific ideas now with less overhead.
I've also added a link and a few paragraphs to the GSoC proposal.
--
To post to this group, send an email to sag
This does not work cleanly with Sage because the css and js refer to
each other and the paths aren't just simple relative paths. You need
to run mod_proxy_html and rewrite css, js and some of the html pages
on the fly. At least that was my experience when trying to have ssl
in front. I never tri
Le dimanche 12 février, Jeroen Demeyer a écrit:
> On 2012-02-11 22:21, Julien Puydt wrote:
> > Le samedi 11 février, Jeroen Demeyer a écrit:
> >> On 2012-02-11 22:05, Michael Orlitzky wrote:
> >>> It could even work out of the box. There shouldn't be a problem
> >>> distributing apache/nginx linked
On 2012-02-12 00:21, Volker Braun wrote:
> On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
>
> You are
> just replacing the non-GPL openSSL by the non-GPL apache. But I am not
> a lawyer, so I won't bother discussing this further.
>
>
> Apache licence v2 is co
On 02/11/2012 06:10 PM, Jeroen Demeyer wrote:
I think it pretty much *is* the same situation license-wise. You are
just replacing the non-GPL openSSL by the non-GPL apache.
Precisely. We would have to link to OpenSSL though, whereas we
communicate with apache over a TCP/IP connection.
--
T
On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
> You are
> just replacing the non-GPL openSSL by the non-GPL apache. But I am not
> a lawyer, so I won't bother discussing this further.
>
Apache licence v2 is compatible with GPL v3, so its very different (and not
a proble
On 2012-02-11 22:21, Julien Puydt wrote:
> Le samedi 11 février, Jeroen Demeyer a écrit:
>> On 2012-02-11 22:05, Michael Orlitzky wrote:
>>> It could even work out of the box. There shouldn't be a problem
>>> distributing apache/nginx linked against OpenSSL in the sage
>>> tarball.
>> Why not direc
On 02/11/2012 04:37 PM, Jonathan wrote:
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or th
On 2/11/12 3:10 PM, John H Palmieri wrote:
I say install it now. First, it's an optional spkg, and second, Simon's
work is pretty trustworthy, in my experience.
Okay, done. Sagenb.org is now upgraded to 4.8.
Thanks,
Jason
--
To post to this group, send an email to sage-devel@googlegroups.
Le dimanche 12 février, Keshav Kini a écrit:
> Yes, but Michael said "distributing apache/nginx linked against
> OpenSSL in the sage tarball", which is what Jeroen was responding to.
Putting them in the same archive isn't a problem, or distributions
would have problem.
The licences cover derived
On 2/11/12 3:41 PM, Jonathan wrote:
On Feb 11, 3:18 pm, Jason Grout wrote:
That sounds reasonable. I *think* OpenSSL is also a requirement for
OpenID, so they'd lose that as well.
So exactly what error happens when you try to install sagenb on a system
with the headers? I assume we need t
On 02/11/2012 04:39 PM, Jason Grout wrote:
The GPL extends to cover all code shipped together, IIRC. So it is
different, in my understanding.
That's fine. I don't think any of us are lawyers, thank god, so like I
said in my response to Jeroen we could make it a separate tarball and
still ac
On Feb 11, 3:18 pm, Jason Grout wrote:
>
> That sounds reasonable. I *think* OpenSSL is also a requirement for
> OpenID, so they'd lose that as well.
>
> So exactly what error happens when you try to install sagenb on a system
> with the headers? I assume we need to work around that, and then
On 2/11/12 3:36 PM, Michael Orlitzky wrote:
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionalit
On 02/11/2012 04:12 PM, Jeroen Demeyer wrote:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or the proxy has to
know a lot about the backen
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for th
On Sun, Feb 12, 2012 at 05:21, Julien Puydt wrote:
> Le samedi 11 février, Jeroen Demeyer a écrit:
>> On 2012-02-11 22:05, Michael Orlitzky wrote:
>> > It could even work out of the box. There shouldn't be a problem
>> > distributing apache/nginx linked against OpenSSL in the sage
>> > tarball.
>>
On Saturday, February 11, 2012 12:17:42 PM UTC-8, Dr. David Kirkby wrote:
>
> Google Earth, Mathematica and VirtualBox all have their installers built
> with
> makeself on Linux.
>
VirtualBox thankfully offers rpm/deb downloads.
Google Earth usually doesn't work for me since they ship half of al
Le samedi 11 février, Jeroen Demeyer a écrit:
> On 2012-02-11 22:05, Michael Orlitzky wrote:
> > It could even work out of the box. There shouldn't be a problem
> > distributing apache/nginx linked against OpenSSL in the sage
> > tarball.
> Why not directly link to OpenSSL then? If you require peo
On 2/11/12 3:14 PM, Volker Braun wrote:
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
So you are suggesting that the openssl support be automatically
removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already does,
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
>
> So you are suggesting that the openssl support be automatically
> removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already does, the _ssl module isn't built
if the headers
On Sun, Feb 12, 2012 at 05:05, Jeroen Demeyer wrote:
> So I guess COPYING.txt should be updated then...
Yes, IMO it should. See http://trac.sagemath.org/sage_trac/ticket/12447 .
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googl
On 2012-02-11 22:05, Michael Orlitzky wrote:
> It could even work out of the box. There shouldn't be a problem
> distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
OpenSSL for apache/nginx, you might as well sk
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even wor
On Saturday, February 11, 2012 11:34:21 AM UTC-8, jason wrote:
>
> On 2/11/12 1:27 PM, Justin C. Walker wrote:
> > Hi, Jason,
> >
> > On Feb 11, 2012, at 06:08 , Jason Grout wrote:
> >
> >> I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying
> to install the p_group_cohomology
On 2012-02-11 21:59, Keshav Kini wrote:
> On Sun, Feb 12, 2012 at 04:54, Jason Grout
> wrote:
>>> I will say it more strongly: Sage *is* violating the GPL by distributing
>>> GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
>>>
>>
>> Sage is changing the license for packages? I thoug
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even work out of the box. There shouldn't be a proble
On 2/11/12 2:59 PM, Keshav Kini wrote:
The complete Sage distribution is GPLv3+. The core Sage library
(written in Python and Cython) is GPLv2+. However, many of the
components of Sage are GPLv3+.
I suppose if we are really shipping GPLv3-*only* components, then the
distribution isn't re
On Sun, Feb 12, 2012 at 04:54, Jason Grout wrote:
>> I will say it more strongly: Sage *is* violating the GPL by distributing
>> GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
>>
>
> Sage is changing the license for packages? I thought the Sage distribution
> was GPLv3 because of GP
On 2/11/12 2:51 PM, Jeroen Demeyer wrote:
On 2012-02-11 17:54, Dr. David Kirkby wrote:
I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
Sage is changing
On 2012-02-11 17:54, Dr. David Kirkby wrote:
> I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
--
To post to this group, send an email to sage-devel@googlegr
On Sun, Feb 12, 2012 at 04:27, Michael Orlitzky wrote:
> Rather than build SSL support into the application servers, everyone
> deployed apache or nginx as an SSL proxy in front of them. Could this work
> for the sage notebook?
>
> The notebook would always run on e.g. localhost:8080 unencrypted,
On 02/11/2012 03:12 PM, Volker Braun wrote:
If you want to compile the flask notebook then I think we should
recommend installing openssl-dev but not require it. So on machines
without ssl it'll just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl li
On Feb 11, 2:12 pm, Volker Braun wrote:
> If you want to compile the flask notebook then I think we should recommend
> installing openssl-dev but not require it. So on machines without ssl it'll
> just build without ssl support, easy.
So you are suggesting that the openssl support be automatica
On 02/11/12 08:04 PM, Volker Braun wrote:
Those are all great features to have. But they should be implemented in a
Sage launcher app that I recently proposed.
I did not see that.
I never liked executable installers. Everything that is wrong about
software distribution on Windows in the end b
If you want to compile the flask notebook then I think we should recommend
installing openssl-dev but not require it. So on machines without ssl it'll
just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl libraries. Its
fine (by most legal opinions)
Those are all great features to have. But they should be implemented in a
Sage launcher app that I recently proposed. The launcher app could also
help direct you to the best download for your machine and prompt you for
possible updates.
I never liked executable installers. Everything that is w
On 02/11/12 02:57 PM, Jason Grout wrote:
So I'd support adding openssl-dev as a requirement of Sage.
That probably means a lot more users would need to be root to install Sage,
since if the development headers are not present, they would have a bit of a
problem.
I believe also OpenSSL does
On 2/11/12 1:27 PM, Justin C. Walker wrote:
Hi, Jason,
On Feb 11, 2012, at 06:08 , Jason Grout wrote:
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying to
install the p_group_cohomology package. If you want this package installed on
sagenb.org, please help fix this prob
Hi, Jason,
On Feb 11, 2012, at 06:08 , Jason Grout wrote:
> I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying to
> install the p_group_cohomology package. If you want this package installed
> on sagenb.org, please help fix this problem. The error message is below.
Simon'
On 2/11/12 1:07 PM, Oscar Lazo wrote:
Hello, I've been working in implementing Airy functions in sage, and
since mpmath allows calcultating any derivative or integral of Airy
functions I wanted to implement the generalized symbolic case, but I am
very puzzled by this error:
from sage.symbolic.fu
On 10 February 2012 21:20, David Roe wrote:
> Sounds like a good idea.
> David
Thank you. Seems you are the only one to comment, so I guess it wont happen
any time soon (if at all).
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, se
Hello, I've been working in implementing Airy functions in sage, and
since mpmath allows calcultating any derivative or integral of Airy
functions I wanted to implement the generalized symbolic case, but I am
very puzzled by this error:
from sage.symbolic.function import BuiltinFunction
class
On Sun, Feb 12, 2012 at 01:55, Jason Grout wrote:
> IIRC, the question is not so much distributing our source that just has an
> import statement, but distributing binaries that we've compiled.
Right, of course... if we're talking about distributing binaries then
what I said goes out the window.
On 2/11/12 11:50 AM, Jonathan wrote:
Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
That makes the OpenSSL license GPL-incompatible. See
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Thanks,
Jason
--
On 2/11/12 11:47 AM, Keshav Kini wrote:
IANAL but I find it hard to believe that simply having
non-GPL-compatible software as a dependency disqualifies us from
releasing Sage under the GPL. If that were true, surely it would be
impossible to license Windows programs under the GPL, as in order to
Alex is correct. I stand corrected. The header files that are a
problem are part of libssl-dev. I did a quick read of their copyright
license. Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
although their secondary li
IANAL but I find it hard to believe that simply having non-GPL-compatible
software as a dependency disqualifies us from releasing Sage under the GPL.
If that were true, surely it would be impossible to license Windows
programs under the GPL, as in order to run them you must first install
Micros
On 2/11/12 10:54 AM, Dr. David Kirkby wrote:
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to bo
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At le
On Sat, Feb 11, 2012 at 9:57 AM, Jason Grout
wrote:
> So I'd support adding openssl-dev as a requirement of Sage. What systems
> does it come default on? I don't recall having a problem on OSX, for
> example.
On Debian (and presumably Ubuntu as well), the correct package name
appears to be lib
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At least on my Ubuntu system the
openssl pac
On 11 February 2012 07:36, Julien Puydt wrote:
> Le vendredi 10 février, John Cremona a écrit:
>> Specifically: in the Makefile the option --as-needed is passed from
>> gcc to ld
>
> That switch is written as-is in the Makefile? Or does it come from
> elsewhere?
>i
The Makefiles in the four subdi
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At least on my Ubuntu system the
openssl package is standard, but openssl-dev is n
Can I just clarify: the automatic download is in the script used to
create the spkg's src directory for a new version? People might
otherwise think that the download was part of building the spkg, which
is not allowed.
I may well adapt that spkg-make script for eclib, obtaining the src
from goog
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying
to install the p_group_cohomology package. If you want this package
installed on sagenb.org, please help fix this problem. The error
message is below.
Thanks,
Jason
In file included from
/sagenb/sage_install/sage-4.8-
PARI-2.5.1 has been released. We should upgrade PARI in Sage to this
latest version. It also happens that this is needed for the OS X 10.7
port, even though this wasn't the motivation for doing the upgrade of PARI.
The sources in the PARI spkg are automatically downloaded. Since PARI
recently cha
60 matches
Mail list logo
