[sage-devel] Re: add curl as a standard package

[Volker Braun]

One issue with curl is that you sooner or later will need the root 
certificates to use it, namely when you start downloading from a https 
site. E.g. in hashstack I recently added the root certs:

https://github.com/hashdist/hashstack/issues/969

This issue already faces us with openssl but since we actually don't use it 
much we could avoid it so far. But when replacing curl in the PATH we are 
going to run into that issue.

I would be happy with adding curl (and up-to-date root certificates) to the 
list of system requirements for building Sage and avoid that can of worms.

PS: and no, you can't use the OS-provided certs, since Apple had to cook 
their own sauce once more.


On Monday, October 24, 2016 at 6:09:24 AM UTC-4, Emmanuel Charpentier wrote:
>
> It looks like curl , which was formerly installed 
> by R installation, must now be installed 
> 
>  
> in order to install R.
>
> One can note that a problem will rarely exists, since most Sage users have 
> curl installed in their system. However, a user having only sage installed 
> (e. g. Sage's virtual machine for Windows) will see it...
>
> If we want to keep R a standard package, we have to either
>
>- patch R and add curl's installation (heavy : the R core Team threw 
>the towel on it),
>- add curl to Sage's prerequisites (lighter to us, but still heavy to 
>the users), 
>- or make it a standard package, on which R must depend.
>
>
> The latter solution has my reference(much simpler).
>
> What is yours ?
>
> --
> Emmanuel Charpentier
>

-- 
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.

Re: [sage-devel] add curl as a standard package

[John H Palmieri]

I have no opinion on whether this approach is on the whole a good idea, but 
I will point out that "which curl" is not as portable as "command -v curl". 
We had an issue a while ago with "which" not behaving properly on some 
platform -- maybe on Solaris "which blah" had a return status of 0 even if 
"blah" was not present? I forget. Anyway, if nothing else, try "command -v 
..." instead of "which ...". (And would it be even better to try to run 
curl to make sure it functions properly, instead of just seeing if it's 
present?)

  John


On Tuesday, October 25, 2016 at 2:52:34 PM UTC-7, Emmanuel Charpentier 
wrote:
>
> This is now Trac#21767 . The 
> unconditional installation works okay on top of 7.5beta0.
>
> The conditional installation can probably be obtained with this bash 
> snippet, at the top of spkg-install :
>
> ## Installation de curl...
>
> ## Look for a systemwide installation
>
> LibExists=no
> if $(pkg-config --exists libcurl) ; then
> LibExists=yes
> echo A systemwide version of libcurl exists. Testing it.
> else
> echo "No systemwide curl installation (or not using pkg-config)."
> fi
>
> ## Systemwide installation version check
>
> VersOK=no
> if test $LibExists = yes ; then
> if ! test "7.28.0" ">" $(pkg-config --modversion libcurl) ; then
> echo Systemwide installation of libcurl is enough to support R.
> VersOK=yes
> else 
> echo Systemwide version of libcurl too old to support our R.
> fi
> fi
>
> ## Checking for a systemwide executable
>
> ExecOK=no
> if test $VersOK = yes ; then
> if test X$(which curl)X = XX ; then
> echo No systemwide curl executable in PATH.
> else
> echo Systemwide curl executable found.
> ExecOK=yes
> fi
> fi
>
> if test $ExecOK = yes ; then
> echo No local installation required.
> exit 0
> else
> echo Starting curl installation...
> fi
>
> The same tachnique can probably been used for xz. pcre will need a 
> supplemental step (checking configuration).
>
> What do you think ?
>
> --
> Emmanuel Charpentier
>
> Le mardi 25 octobre 2016 11:15:56 UTC+2, Jean-Pierre Flori a écrit :
>>
>>
>>
>> On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori 
>> wrote:
>>>
>>>
>>>
>>> On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote:



 On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier 
 wrote:
>
> Okay. I I have followed you correctly, we have two (mutually 
> incompatible) options :
>
>
>- (Dima's option) : package curl, pcre and xz as standard 
>packages, and make R depend on them (unconditionnally).
>- (Jean-Pierre option) : add tjem to Sage's core, but build them 
>if and only if they are not installed systemwide (= useable at Sage's 
>compile time) ; do this before trying to build R.
>
> The first option is extremely simple and failsafe. The cost is about 
> 15 MB (sum of all installed files in a temporary "prefix" directory, 
> without shaving anything) and about 3 minutes of compilation time (no 
> parallelism used). We might shave 4,9 MB of docs (local/share/(doc|man). 
> Binaries are  about 0.9MB. The total potential cots (sum of sizes of the 
> three build directories) is 89 MB (= potential cost if the three build 
> directories ate kept after building i. e. for debugging purposes).
>

 I don't really follow you: note that gcc is also a standard package, 
 but it only really gets installed if the system gcc is 
 not good enough. That is to say, if curl, pcre, and xz are available 
 system-wide, Sage should not try to install them,
 no megabytes used...

>>> I don't think the real issue is megabytes, but rather making sage more 
>>> modular and easier to ship into distributions (other than sage-the-distrib).
>>>  
>>>
  

>
> The second one requires hacking the main Sage configuration. I do not 
> feel currently quite at ease with this one, but I'm just reading the 
> relevant docs. I have no idea of the potential costs, save for what can 
> be 
> deduced from the costs of Dima's options.
>
> The first option is compatible with the "batteries included" 
> philosophy flaunted by Sage. are the potential 10-15 MB savings worth of 
> hacking the main Sage config file ?
>
 You can already add them as standard packages and then we can work on 
>>> making them installed only if not available system-wide.
>>> These two steps can be done sequentially though it would be better to 
>>> get the two of them at the same time.
>>>
>> If you open a tcket with the first step, I'll do the second one, and 
>> Jeroen or someone else can review it. 
>>
>

-- 
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 

Re: [sage-devel] add curl as a standard package

[Emmanuel Charpentier]

This is now Trac#21767 . The 
unconditional installation works okay on top of 7.5beta0.

The conditional installation can probably be obtained with this bash 
snippet, at the top of spkg-install :

## Installation de curl...

## Look for a systemwide installation

LibExists=no
if $(pkg-config --exists libcurl) ; then
LibExists=yes
echo A systemwide version of libcurl exists. Testing it.
else
echo "No systemwide curl installation (or not using pkg-config)."
fi

## Systemwide installation version check

VersOK=no
if test $LibExists = yes ; then
if ! test "7.28.0" ">" $(pkg-config --modversion libcurl) ; then
echo Systemwide installation of libcurl is enough to support R.
VersOK=yes
else 
echo Systemwide version of libcurl too old to support our R.
fi
fi

## Checking for a systemwide executable

ExecOK=no
if test $VersOK = yes ; then
if test X$(which curl)X = XX ; then
echo No systemwide curl executable in PATH.
else
echo Systemwide curl executable found.
ExecOK=yes
fi
fi

if test $ExecOK = yes ; then
echo No local installation required.
exit 0
else
echo Starting curl installation...
fi

The same tachnique can probably been used for xz. pcre will need a 
supplemental step (checking configuration).

What do you think ?

--
Emmanuel Charpentier

Le mardi 25 octobre 2016 11:15:56 UTC+2, Jean-Pierre Flori a écrit :
>
>
>
> On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote:
>>>
>>>
>>>
>>> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier 
>>> wrote:

 Okay. I I have followed you correctly, we have two (mutually 
 incompatible) options :


- (Dima's option) : package curl, pcre and xz as standard packages, 
and make R depend on them (unconditionnally).
- (Jean-Pierre option) : add tjem to Sage's core, but build them if 
and only if they are not installed systemwide (= useable at Sage's 
 compile 
time) ; do this before trying to build R.

 The first option is extremely simple and failsafe. The cost is about 15 
 MB (sum of all installed files in a temporary "prefix" directory, without 
 shaving anything) and about 3 minutes of compilation time (no parallelism 
 used). We might shave 4,9 MB of docs (local/share/(doc|man). Binaries are  
 about 0.9MB. The total potential cots (sum of sizes of the three build 
 directories) is 89 MB (= potential cost if the three build directories ate 
 kept after building i. e. for debugging purposes).

>>>
>>> I don't really follow you: note that gcc is also a standard package, but 
>>> it only really gets installed if the system gcc is 
>>> not good enough. That is to say, if curl, pcre, and xz are available 
>>> system-wide, Sage should not try to install them,
>>> no megabytes used...
>>>
>> I don't think the real issue is megabytes, but rather making sage more 
>> modular and easier to ship into distributions (other than sage-the-distrib).
>>  
>>
>>>  
>>>

 The second one requires hacking the main Sage configuration. I do not 
 feel currently quite at ease with this one, but I'm just reading the 
 relevant docs. I have no idea of the potential costs, save for what can be 
 deduced from the costs of Dima's options.

 The first option is compatible with the "batteries included" philosophy 
 flaunted by Sage. are the potential 10-15 MB savings worth of hacking the 
 main Sage config file ?

>>> You can already add them as standard packages and then we can work on 
>> making them installed only if not available system-wide.
>> These two steps can be done sequentially though it would be better to get 
>> the two of them at the same time.
>>
> If you open a tcket with the first step, I'll do the second one, and 
> Jeroen or someone else can review it. 
>

-- 
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.

[sage-devel] Sage and JMM 2017 -- Atlanta GA

[William Stein]

Hi,

I'll have a Sage booth at JMM 2017.  Some people who want to help can
get free registration (email me).

At least me, Harald Schilly, John Jeng, and Kevin Lui will be helping
with the Sage booth.

I'll be at JMM/Atlanta, Jan 4 - 10, 2017.  Harald Schilly, John Jeng
and I will also be staying a few extra days for a SageMathCloud coding
sprints.

 - William

-- 
William (http://wstein.org)

-- 
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.

Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

[Jori Mäntysalo]

On Tue, 25 Oct 2016, Jori Mantysalo wrote:


 https://jupyterhub.readthedocs.io/en/latest/getting-started.html


Got it installed and shown up in my browser. Good start. It rejected login 
with wrong password, and with right password gave "Spawner failed to start 
[status=1]". So next I guess I should somehow register Sage as a "kernel"(?) 
for jupyterhub.


More progress. After

pip3 install jupyter
cd /usr/local/share/jupyter
ln -s /opt/sage-7.4/local/share/jupyter/kernels
ln -s /opt/sage-7.4/local/share/jupyter/nbextensions/

it almost work. Now when I modified

/opt/sage-7.4/local/share/jupyter/kernels/sagemath/kernel.json

by adding

"env": {"SAGE_ROOT": "/opt/sage-7.4/"}

to the dict I got this to work!

I used jupyterhub --no-ssl --port=80

Next move to https, then try ldap, and then combine ldap and local 
accounts. And last look for worksheet sharing.


Thanks for help!

--
Jori Mäntysalo

Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

[Jori Mäntysalo]

On Mon, 24 Oct 2016, Volker Braun wrote:


I have a setup helper for jupyterhup at 

https://github.com/vbraun/run-jupyter-hub


Thanks. Stopped with ffi.h missing, now installed libffi-dev and trying 
again...


On Tue, 25 Oct 2016, Luca De Feo wrote:


Can you give me some kind of Hello world! -example of Jupyter?


I am not sure you realize that JupyterHub is not shipped with Sage.


That explains quite much. No, I did not realize that.


If you want to try out JupyterHub, you will have to install it
separately, and link the Sage kernel to it. I find the JupyterHub docs
pretty well written and easy to follow for a Hello world test

 https://jupyterhub.readthedocs.io/en/latest/getting-started.html


Got it installed and shown up in my browser. Good start. It rejected login 
with wrong password, and with right password gave "Spawner failed to start 
[status=1]". So next I guess I should somehow register Sage as a 
"kernel"(?) for jupyterhub.


  * * *

I tested on Ubuntu 16.04 LTS. I did

apt-get install npm nodejs-legacy
apt-get install python3-pip

npm install -g configurable-http-proxy

export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
dpkg-reconfigure locales

pip3 install jupyterhub

Noticed that it used IPv6, got a headache when googling, found the 
instruction to put GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" on 
/etc/default/grub, said update-grub and got the login prompt.


--
Jori Mäntysalo

Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

[Luca De Feo]

> Can you give me some kind of Hello world! -example of Jupyter? ./sage
> --notebook=jupyter will open a server to port  --- how to change the
> port or, more general, is there some help file? First I would like to see a
> way to have two local user using Sage and not seeing each other files.

I am not sure you realize that JupyterHub is not shipped with Sage.
Running ./sage --notebook=jupyter will run the Jupyter server, NOT
JupyterHub. This is a single-user setting: the Jupyter server runs as
your user, and can acces any file your user can access (the file
explorer is rooted in your working dir, but you can go anywhere in the
file system using Python).

JupyterHub is a different beast: it is a server that waits for
connections and spawns Jupyter servers under different userids. So
this is similar to running ./sage --notebook=jupyter as two different
users in their respective homedirs.

If you want to try out JupyterHub, you will have to install it
separately, and link the Sage kernel to it. I find the JupyterHub docs
pretty well written and easy to follow for a Hello world test

  https://jupyterhub.readthedocs.io/en/latest/getting-started.html

You can test them in a virtualenv for an easy throwaway setup.
Volker's scripts may be another good starting point, although I
haven't tested them. Alternatively, there is a docker container here :

  https://hub.docker.com/r/jupyterhub/jupyterhub/

which is also good for testing.

I agree with Dima that a tutorial for setting up JupyterHub in a
SageNB-like way would be much welcome. I have the feeling that the
Jupyter/JupyterHub/SageMath integration is still a bit of a moving
target ATM, but we should try to write this sooner than later.

Luca

-- 
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.

Re: [sage-devel] add curl as a standard package

[Jean-Pierre Flori]

On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote:
>>
>>
>>
>> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier wrote:
>>>
>>> Okay. I I have followed you correctly, we have two (mutually 
>>> incompatible) options :
>>>
>>>
>>>- (Dima's option) : package curl, pcre and xz as standard packages, 
>>>and make R depend on them (unconditionnally).
>>>- (Jean-Pierre option) : add tjem to Sage's core, but build them if 
>>>and only if they are not installed systemwide (= useable at Sage's 
>>> compile 
>>>time) ; do this before trying to build R.
>>>
>>> The first option is extremely simple and failsafe. The cost is about 15 
>>> MB (sum of all installed files in a temporary "prefix" directory, without 
>>> shaving anything) and about 3 minutes of compilation time (no parallelism 
>>> used). We might shave 4,9 MB of docs (local/share/(doc|man). Binaries are  
>>> about 0.9MB. The total potential cots (sum of sizes of the three build 
>>> directories) is 89 MB (= potential cost if the three build directories ate 
>>> kept after building i. e. for debugging purposes).
>>>
>>
>> I don't really follow you: note that gcc is also a standard package, but 
>> it only really gets installed if the system gcc is 
>> not good enough. That is to say, if curl, pcre, and xz are available 
>> system-wide, Sage should not try to install them,
>> no megabytes used...
>>
> I don't think the real issue is megabytes, but rather making sage more 
> modular and easier to ship into distributions (other than sage-the-distrib).
>  
>
>>  
>>
>>>
>>> The second one requires hacking the main Sage configuration. I do not 
>>> feel currently quite at ease with this one, but I'm just reading the 
>>> relevant docs. I have no idea of the potential costs, save for what can be 
>>> deduced from the costs of Dima's options.
>>>
>>> The first option is compatible with the "batteries included" philosophy 
>>> flaunted by Sage. are the potential 10-15 MB savings worth of hacking the 
>>> main Sage config file ?
>>>
>> You can already add them as standard packages and then we can work on 
> making them installed only if not available system-wide.
> These two steps can be done sequentially though it would be better to get 
> the two of them at the same time.
>
If you open a tcket with the first step, I'll do the second one, and Jeroen 
or someone else can review it. 

-- 
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.

Re: [sage-devel] add curl as a standard package

[Jean-Pierre Flori]

On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote:
>
>
>
> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier wrote:
>>
>> Okay. I I have followed you correctly, we have two (mutually 
>> incompatible) options :
>>
>>
>>- (Dima's option) : package curl, pcre and xz as standard packages, 
>>and make R depend on them (unconditionnally).
>>- (Jean-Pierre option) : add tjem to Sage's core, but build them if 
>>and only if they are not installed systemwide (= useable at Sage's 
>> compile 
>>time) ; do this before trying to build R.
>>
>> The first option is extremely simple and failsafe. The cost is about 15 
>> MB (sum of all installed files in a temporary "prefix" directory, without 
>> shaving anything) and about 3 minutes of compilation time (no parallelism 
>> used). We might shave 4,9 MB of docs (local/share/(doc|man). Binaries are  
>> about 0.9MB. The total potential cots (sum of sizes of the three build 
>> directories) is 89 MB (= potential cost if the three build directories ate 
>> kept after building i. e. for debugging purposes).
>>
>
> I don't really follow you: note that gcc is also a standard package, but 
> it only really gets installed if the system gcc is 
> not good enough. That is to say, if curl, pcre, and xz are available 
> system-wide, Sage should not try to install them,
> no megabytes used...
>
I don't think the real issue is megabytes, but rather making sage more 
modular and easier to ship into distributions (other than sage-the-distrib).
 

>  
>
>>
>> The second one requires hacking the main Sage configuration. I do not 
>> feel currently quite at ease with this one, but I'm just reading the 
>> relevant docs. I have no idea of the potential costs, save for what can be 
>> deduced from the costs of Dima's options.
>>
>> The first option is compatible with the "batteries included" philosophy 
>> flaunted by Sage. are the potential 10-15 MB savings worth of hacking the 
>> main Sage config file ?
>>
> You can already add them as standard packages and then we can work on 
making them installed only if not available system-wide.
These two steps can be done sequentially though it would be better to get 
the two of them at the same time.

-- 
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.