[sage-devel] A 404 in the Download Source page

[TB]

Dear sagemath.org website admins,

In http://www.sagemath.org/download-source.html the README.txt link 
leads to a 404 page. The correct link might be 
https://git.sagemath.org/sage.git/tree/README.md

Same for the changelog link (but versions prior to 7.4 works).


Best regards,

TB

--
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] Re: A 404 in the Download Source page

[Harald Schilly]

I've made this ticket:
https://github.com/sagemath/website/issues/97

and yes, the changelog is simply missing because the script generating it
is lost.

-- h


On Mon, Nov 21, 2016 at 9:56 AM, TB  wrote:

> Dear sagemath.org website admins,
>
> In http://www.sagemath.org/download-source.html the README.txt link leads
> to a 404 page. The correct link might be https://git.sagemath.org/sage.
> git/tree/README.md
> Same for the changelog link (but versions prior to 7.4 works).
>
>
> Best regards,
>
> TB
>

-- 
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] OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Dear list,

The fact that we can't ship openSSL (see uncountable theads in sage-devel 
and others) seems to pose more and more difficulties. See for example this 
thread  
on sage-support, and especially Dima's answer 
, as 
well as this annoying ticket , 
discussed in this saga 
 . 

Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
files as a prerequisite to building Sage ? This would require of the user 
to install OpenSSL systemwide, thus making it "system software" and 
satisfying the strange licensing requirements that bother us.

One could even do that indirectly, by requiring a systemwide libcurl 
supporting https : this would de facto enforce the systemwide installation 
of OpenSSL (or a reasonable facsimile). That's what I was trying to do in this 
proposal ... (IIRC, the 
problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
problem. But I'll have to check : if this is true, we can require OpenSSL 
and ship libcurl which will then compile cleanly).

Comments ? Especially wrt Macs, which seem to be further encumbered by 
Apple's dirty tricks...

Should we have a vote ?

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

[sage-devel] Would it be correct to check for a (sufficient) systemwide installation before compiling a package ?

[Emmanuel Charpentier]

Dear list,

We currently ship a number of packages that might duplicate the 
functionality of systemwide installed libraries. My case in point : xz, 
which provides support for lzma-compressed archives and a command-line tool.

What I think is that, in such cases, unless we require a very specific 
version (or Sage-specific patches), we might do the following in 
spkg-install :

Test for the existence of a systemwide eqivalent (executable and/or 
library) ;
If positive, test for needed characteristics (version, support of 
specific features);
If positive :
Display a message telling that Sage will use the systemwide 
version
Set InstallNeeded=False
else
Display a message telling that Sage will build its specific version
Set InstallNeeded=Trie
Unpack the source
If InstallNeeded :
build and install the package
If test suite required
run the test suite (from the unpacked source tree)

Unless I'm mistaken, this can be done all from the spkg-install script ; 
this would mark the package as installed (if the test suite runs OK), 
whether or not an actual install has been done.

What do you think ?

--
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] Would it be correct to check for a (sufficient) systemwide installation before compiling a package ?

[Jeroen Demeyer]

On 2016-11-21 12:37, Emmanuel Charpentier wrote:

What do you think ?


I think we should simply NOT install the package at all instead of 
faking an install in spkg-install. We currently do for gcc and git using 
some logic in the top-level ./configure.


--
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] Would it be correct to check for a (sufficient) systemwide installation before compiling a package ?

[Emmanuel Charpentier]

Le lundi 21 novembre 2016 14:28:11 UTC+1, Jeroen Demeyer a écrit :
>
> On 2016-11-21 12:37, Emmanuel Charpentier wrote: 
> > What do you think ? 
>
> I think we should simply NOT install the package at all instead of 
> faking an install in spkg-install. We currently do for gcc and git

 
OK so far
 

> using 
> some logic in the top-level ./configure.


Aha ! Here's the rub ! You need to do this on toplevel configuration for 
each and every  such package.

This is needed for gcc, which is pretty central to any installation, and 
possibly for git (similar, but weaker, reasons).

My point is that we should be able to do this for more mundane packages 
(possibly optional), without having to tinker with the toplevel config 
file. This is practical :

   - if the package does not need "in situ" Sage-specific patching, *and*
   - has no version-specific issues.

Such a "mundane" package may need a wrapper, which can be installed 
separately in a separate section of the spkg-install script.

(BTW : we need also to create a way to "uninstall" a Sage package more 
steamlined than 'make distclean && make". No ideas yet about this one...).

HTH,

--
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] Checking out old branches

[Erik Bray]

On Fri, Nov 18, 2016 at 8:18 AM, William Stein  wrote:
>
> Ideas:
>
>
> What about changing Cython to optionally use sha1 or md5 hashes instead of
> timestamps?

I've had this thought as well--it would be fairly straightforward to
output a list of hashes for all Cython sources and compare those when
deciding whether or not a file needs to be rebuilt.

> On Thu, Nov 17, 2016 at 11:12 PM David Roe  wrote:
>>
>> If I checkout an old branch (say, from one or two versions of Sage ago),
>> it essentially forces a rebuild of all of Sage, even if I think better of it
>> and checkout develop immediately.  The rebuild is a consequence of the fact
>> that Cython builds based on timestamp and all of the files have been
>> touched.
>>
>> I'd like to solicit ideas to make this less painful.  Here's one, based on
>> a conversation with Julian Rüth.
>>
>> Create a new git trac subcommand to replace `git trac checkout 1234`, say
>> `git trac old 1234`.  This would fetch the branch, check it out into a
>> completely separate folder within ($SAGE_ROOT/merge_tree or something),
>> merge in develop.  If the merge is successful, create a new branch and pull
>> the changes in.  This ends up with only a few files changing if you started
>> at develop.  If the merge is not successful, report to the user and ask them
>> to fix the merge in
>> $SAGE_ROOT/merge_tree.  There would then be some way to resume and pull in
>> the changes.
>>
>> There are some details to fill in, but I think that an approach like this
>> can work.  It does mean having another 100MB working tree floating around
>> just for merging into, and also stepping a bit further away from normal git
>> practices.
>>
>> Any other ideas?
>> David
>>
>> --
>> 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.
>
> --
> Sent from my massive iPhone 6 plus.
>
> --
> 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.

-- 
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] OpenSSL as a new systemwide Sage dependency ?

[Erik Bray]

On Mon, Nov 21, 2016 at 12:21 PM, Emmanuel Charpentier
 wrote:
> Dear list,
>
> The fact that we can't ship openSSL (see uncountable theads in sage-devel
> and others) seems to pose more and more difficulties. See for example this
> thread on sage-support, and especially Dima's answer, as well as this
> annoying ticket, discussed in this saga .
>
> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development
> files as a prerequisite to building Sage ? This would require of the user to
> install OpenSSL systemwide, thus making it "system software" and satisfying
> the strange licensing requirements that bother us.
>
> One could even do that indirectly, by requiring a systemwide libcurl
> supporting https : this would de facto enforce the systemwide installation
> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in
> this proposal... (IIRC, the problem with libcurl is also bound to OpenSSL :
> libcurl itself is not a problem. But I'll have to check : if this is true,
> we can require OpenSSL and ship libcurl which will then compile cleanly).
>
> Comments ? Especially wrt Macs, which seem to be further encumbered by
> Apple's dirty tricks...
>
> Should we have a vote ?

I'm inclined to agree.  Add to that all (or at least most) of Sage's
other dependencies as well ;)

-- 
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] Would it be correct to check for a (sufficient) systemwide installation before compiling a package ?

[Erik Bray]

On Mon, Nov 21, 2016 at 2:52 PM, Emmanuel Charpentier
 wrote:
> Le lundi 21 novembre 2016 14:28:11 UTC+1, Jeroen Demeyer a écrit :
>>
>> On 2016-11-21 12:37, Emmanuel Charpentier wrote:
>> > What do you think ?
>>
>> I think we should simply NOT install the package at all instead of
>> faking an install in spkg-install. We currently do for gcc and git
>
>
> OK so far
>
>>
>> using
>> some logic in the top-level ./configure.
>
>
> Aha ! Here's the rub ! You need to do this on toplevel configuration for
> each and every  such package.
>
> This is needed for gcc, which is pretty central to any installation, and
> possibly for git (similar, but weaker, reasons).
>
> My point is that we should be able to do this for more mundane packages
> (possibly optional), without having to tinker with the toplevel config file.
> This is practical :
>
> if the package does not need "in situ" Sage-specific patching, and
> has no version-specific issues.
>
> Such a "mundane" package may need a wrapper, which can be installed
> separately in a separate section of the spkg-install script.

I think there's room for both here, where necessary.  I think the top
level `./configure` should be checking what packages are already
available from the system, and there has already been movement,
thankfully, toward doing that (albeit slowly).

In some cases it may be necessary / useful to install some kind of
wrapper into the sage environment around the system-installed
dependency.  But that may not always be necessary either.  Would have
to look at specific examples to be any more specific.

> (BTW : we need also to create a way to "uninstall" a Sage package more
> steamlined than 'make distclean && make". No ideas yet about this one...).

Yes.  I think work like https://trac.sagemath.org/ticket/21469 is an
important prerequisite to that, as well as some of the other configure
cleanup.  Ideally, package installation would proceed more like
building packages for distros like Debian, where instead of installing
directly into $SAGE_LOCAL, packages would be first installed into an
alternate root, and then copied from there into $SAGE_LOCAL.  This
gives an opportunity to enumerate every file/directory installed by
that package and create a manifest that can be used for later
uninstallation.

-- 
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: What is the correct way to patch packages that use autotools?

[Erik Bray]

On Mon, Nov 21, 2016 at 4:09 PM, Erik Bray  wrote:
> On Thu, Nov 17, 2016 at 5:28 PM, Jean-Pierre Flori  wrote:
>>
>>
>> On Thursday, November 17, 2016 at 5:27:15 PM UTC+1, Erik Bray wrote:
>>>
>>> Hmm, okay.  I am using my system's autoreconf.  For the sage autotools
>>> is that just an optional package I need to install?
>>
>> Yes.
>
> Okay, well, it turns out Singular requires automake 1.15 which is
> *not* included yet in the Sage autotools spkg.  So now the question
> becomes: How do I update the package to include automake 1.15?

(Answering my own question: By updating the version-list file and
re-running spkg-src to make a new upstream tarball I think I can do
this.  So I'll ask back here if I have any further questions.
Meanwhile, assuming that works, should I make a ticket to update this
package?)

-- 
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: What is the correct way to patch packages that use autotools?

[Erik Bray]

On Thu, Nov 17, 2016 at 5:28 PM, Jean-Pierre Flori  wrote:
>
>
> On Thursday, November 17, 2016 at 5:27:15 PM UTC+1, Erik Bray wrote:
>>
>> Hmm, okay.  I am using my system's autoreconf.  For the sage autotools
>> is that just an optional package I need to install?
>
> Yes.

Okay, well, it turns out Singular requires automake 1.15 which is
*not* included yet in the Sage autotools spkg.  So now the question
becomes: How do I update the package to include automake 1.15?

-- 
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] OpenSSL as a new systemwide Sage dependency ?

[Thierry]

Hi,

On Mon, Nov 21, 2016 at 03:21:31AM -0800, Emmanuel Charpentier wrote:
> Dear list,
> 
> The fact that we can't ship openSSL (see uncountable theads in sage-devel 
> and others) seems to pose more and more difficulties. See for example this 
> thread  
> on sage-support, and especially Dima's answer 
> , as 
> well as this annoying ticket , 
> discussed in this saga 
>  . 


Note that Dima's answer is somehow misleading, since downloading openssl
from the Sage mirrors does not require SSL.

Hence the following is still possible, without having openssl-dev as a
system prerequisite:

- check that openssl-dev (or equivalent) is installed system-wide
- if not:
  - warn the user and suggest/recommend her to install it
  - as an alternative, propose to download and install openssl from the 
Sage mirrors via http
- build Sage

Ciao,
Thierry



> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> files as a prerequisite to building Sage ? This would require of the user 
> to install OpenSSL systemwide, thus making it "system software" and 
> satisfying the strange licensing requirements that bother us.
> 
> One could even do that indirectly, by requiring a systemwide libcurl 
> supporting https : this would de facto enforce the systemwide installation 
> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in 
> this 
> proposal ... (IIRC, the 
> problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> problem. But I'll have to check : if this is true, we can require OpenSSL 
> and ship libcurl which will then compile cleanly).
> 
> Comments ? Especially wrt Macs, which seem to be further encumbered by 
> Apple's dirty tricks...
> 
> Should we have a vote ?
> 
> --
> 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.

-- 
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] OpenSSL as a new systemwide Sage dependency ?

[Jeroen Demeyer]

Should we really add OpenSSL as a dependency to fix a few very specific 
issues?


I'm not saying that I'm against the proposal, but we should really weigh 
the pros against the cons. The main "con" is: adding an extra dependency 
which might make it even harder for ordinary users to compile Sage from 
source.


99% of Sage users will probably never need OpenSSL within Sage. If you 
break something for 2% of users while fixing something for 1% of users, 
that is a net loss of 1%.


Jeroen.

--
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] Re: OpenSSL as a new systemwide Sage dependency ?

[Dima Pasechnik]

On Monday, November 21, 2016 at 11:21:31 AM UTC, Emmanuel Charpentier wrote:
>
> Dear list,
>
> The fact that we can't ship openSSL (see uncountable theads in sage-devel 
> and others) seems to pose more and more difficulties. See for example this 
> thread  
> on sage-support, and especially Dima's answer 
> , 
> as well as this annoying ticket , 
> discussed in this saga 
>  . 
>
> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> files as a prerequisite to building Sage ? This would require of the user 
> to install OpenSSL systemwide, thus making it "system software" and 
> satisfying the strange licensing requirements that bother us.
>

Try installing OpenSSL on an OSX 10.12 Mac using just XCode!
You might be in for a surprise.
 

>
> One could even do that indirectly, by requiring a systemwide libcurl 
> supporting https : this would de facto enforce the systemwide installation 
> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in 
> this 
> proposal ... (IIRC, 
> the problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> problem. But I'll have to check : if this is true, we can require OpenSSL 
> and ship libcurl which will then compile cleanly).
>
> Comments ? Especially wrt Macs, which seem to be further encumbered by 
> Apple's dirty tricks...
>
> Should we have a vote ?
>
> --
> 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] Re: OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Le 21 nov. 2016 18:26, "Dima Pasechnik"  a écrit :
>
>
>
> On Monday, November 21, 2016 at 11:21:31 AM UTC, Emmanuel Charpentier
wrote:
>>
>> Dear list,
>>
>> The fact that we can't ship openSSL (see uncountable theads in
sage-devel and others) seems to pose more and more difficulties. See for
example this thread on sage-support, and especially Dima's answer, as well
as this annoying ticket, discussed in this saga .
>>
>> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development
files as a prerequisite to building Sage ? This would require of the user
to install OpenSSL systemwide, thus making it "system software" and
satisfying the strange licensing requirements that bother us.
>
>
> Try installing OpenSSL on an OSX 10.12 Mac using just XCode!
> You might be in for a surprise.

Oh.

How is that done currently  ?

I was aware os the existence of some Apple's shenanigans, but not to this
extend...

>> One could even do that indirectly, by requiring a systemwide libcurl
supporting https : this would de facto enforce the systemwide installation
of OpenSSL (or a reasonable facsimile). That's what I was trying to do in
this proposal... (IIRC, the problem with libcurl is also bound to OpenSSL :
libcurl itself is not a problem. But I'll have to check : if this is true,
we can require OpenSSL and ship libcurl which will then compile cleanly).
>>
>> Comments ? Especially wrt Macs, which seem to be further encumbered by
Apple's dirty tricks...
>>
>> Should we have a vote ?
>>
>> --
>> 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/92OdoUbBDbE/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.

Re: [sage-devel] OpenSSL as a new systemwide Sage dependency ?

[Dima Pasechnik]

On Monday, November 21, 2016 at 4:09:41 PM UTC, Thierry 
(sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> On Mon, Nov 21, 2016 at 03:21:31AM -0800, Emmanuel Charpentier wrote: 
> > Dear list, 
> > 
> > The fact that we can't ship openSSL (see uncountable theads in 
> sage-devel 
> > and others) seems to pose more and more difficulties. See for example 
> this 
> > thread  
>
> > on sage-support, and especially Dima's answer 
> > , 
> as 
> > well as this annoying ticket , 
> > discussed in this saga 
> >  . 
>
>
> Note that Dima's answer is somehow misleading, since downloading openssl 
> from the Sage mirrors does not require SSL.  


I was referring to the fact that https://github.com/sagemath/binary-pkg
does not work on OSX 10.12, due to this SSL blues.

Unless I misunderstand, we currently aren't able to build distributable 
Sage binaries on OSX 10.12.

 
 

> Hence the following is still possible, without having openssl-dev as a 
> system prerequisite: 
>
> - check that openssl-dev (or equivalent) is installed system-wide 
> - if not: 
>   - warn the user and suggest/recommend her to install it 
>   - as an alternative, propose to download and install openssl from the 
> Sage mirrors via http 
> - build Sage 
>
> Ciao, 
> Thierry 
>
>
>
> > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> > files as a prerequisite to building Sage ? This would require of the 
> user 
> > to install OpenSSL systemwide, thus making it "system software" and 
> > satisfying the strange licensing requirements that bother us. 
> > 
> > One could even do that indirectly, by requiring a systemwide libcurl 
> > supporting https : this would de facto enforce the systemwide 
> installation 
> > of OpenSSL (or a reasonable facsimile). That's what I was trying to do 
> in this 
> > proposal ... (IIRC, 
> the 
> > problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> > problem. But I'll have to check : if this is true, we can require 
> OpenSSL 
> > and ship libcurl which will then compile cleanly). 
> > 
> > Comments ? Especially wrt Macs, which seem to be further encumbered by 
> > Apple's dirty tricks... 
> > 
> > Should we have a vote ? 
> > 
> > -- 
> > 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+...@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 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] OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Le lundi 21 novembre 2016 à 09:34 -0800, Dima Pasechnik a écrit :
> On Monday, November 21, 2016 at 4:09:41 PM UTC, Thierry (sage-googles
> ucks@xxx) wrote:
> > Hi,
> > 
> > 
> > 
> > On Mon, Nov 21, 2016 at 03:21:31AM -0800, Emmanuel Charpentier
> > wrote:
> > 
> > > Dear list,
> > 
> > > 
> > 
> > > The fact that we can't ship openSSL (see uncountable theads in
> > sage-devel 
> > 
> > > and others) seems to pose more and more difficulties. See for
> > example this 
> > 
> > > thread  > uGT2ViM> 
> > 
> > > on sage-support, and especially Dima's answer 
> > 
> > >  > KAwAJ>, as 
> > 
> > > well as this annoying ticket  > 767>, 
> > 
> > > discussed in this saga 
> > 
> > > 
> > . 
> > 
> > 
> > 
> > 
> > 
> > Note that Dima's answer is somehow misleading, since downloading
> > openssl
> > 
> > from the Sage mirrors does not require SSL.  
> 
> I was referring to the fact that https://github.com/sagemath/binary-p
> kg
> does not work on OSX 10.12, due to this SSL blues.
> 
> Unless I misunderstand, we currently aren't able to build
> distributable Sage binaries on OSX 10.12.

OK. That's different. If I read you correctly, you mean that a binary
packaging of Sage won't run on a Mac that hasn't somehow received
OpenSSL's baptism ? Hence two questions :
1) Can OpenSSL be installed on a "virgin" Mac ? If so, how ?2) Can a
Max where OpenSSL has been installed run a Sage binary package ?
If the answer to those questions are both "yes", this describes a
situation very close to what I suggest to endorse by depending
officially on OpenSSL.
--Emmanuel Charpentier 
> > Hence the following is still possible, without having openssl-dev
> > as a
> > 
> > system prerequisite:
> > 
> > 
> > 
> > - check that openssl-dev (or equivalent) is installed system-wide
> > 
> > - if not:
> > 
> >   - warn the user and suggest/recommend her to install it
> > 
> >   - as an alternative, propose to download and install openssl from
> > the 
> > 
> >     Sage mirrors via http
> > 
> > - build Sage
> > 
> > 
> > 
> > Ciao,
> > 
> > Thierry
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s
> > development 
> > 
> > > files as a prerequisite to building Sage ? This would require of
> > the user 
> > 
> > > to install OpenSSL systemwide, thus making it "system software"
> > and 
> > 
> > > satisfying the strange licensing requirements that bother us.
> > 
> > > 
> > 
> > > One could even do that indirectly, by requiring a systemwide
> > libcurl 
> > 
> > > supporting https : this would de facto enforce the systemwide
> > installation 
> > 
> > > of OpenSSL (or a reasonable facsimile). That's what I was trying
> > to do in this 
> > 
> > > proposal ...
> > (IIRC, the 
> > 
> > > problem with libcurl is also bound to OpenSSL : libcurl itself is
> > not a 
> > 
> > > problem. But I'll have to check : if this is true, we can require
> > OpenSSL 
> > 
> > > and ship libcurl which will then compile cleanly).
> > 
> > > 
> > 
> > > Comments ? Especially wrt Macs, which seem to be further
> > encumbered by 
> > 
> > > Apple's dirty tricks...
> > 
> > > 
> > 
> > > Should we have a vote ?
> > 
> > > 
> > 
> > > --
> > 
> > > 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+...@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/top
> ic/sage-devel/92OdoUbBDbE/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to s
> age-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.

Re: [sage-devel] OpenSSL as a new systemwide Sage dependency ?

[Dima Pasechnik]

On Monday, November 21, 2016 at 5:50:29 PM UTC, Emmanuel Charpentier wrote:
>
> Le lundi 21 novembre 2016 à 09:34 -0800, Dima Pasechnik a écrit :
>
>
>
> On Monday, November 21, 2016 at 4:09:41 PM UTC, Thierry 
> (sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> On Mon, Nov 21, 2016 at 03:21:31AM -0800, Emmanuel Charpentier wrote: 
> > Dear list, 
> > 
> > The fact that we can't ship openSSL (see uncountable theads in 
> sage-devel 
> > and others) seems to pose more and more difficulties. See for example 
> this 
> > thread  
>
> > on sage-support, and especially Dima's answer 
> > , 
> as 
> > well as this annoying ticket , 
> > discussed in this saga 
> >  . 
>
>
> Note that Dima's answer is somehow misleading, since downloading openssl 
> from the Sage mirrors does not require SSL.  
>
>
> I was referring to the fact that https://github.com/sagemath/binary-pkg
> does not work on OSX 10.12, due to this SSL blues.
>
> Unless I misunderstand, we currently aren't able to build distributable 
> Sage binaries on OSX 10.12.
>
>
> OK. That's different. If I read you correctly, you mean that a binary 
> packaging of Sage won't run on a Mac
>

no, I said that one *cannot build* such a distro on OSX 10.12. It still 
works on OSX 10.11.

 

> that hasn't somehow received OpenSSL's baptism ? Hence two questions :
>
> 1) Can OpenSSL be installed on a "virgin" Mac ? If so, how ?
> 2) Can a Max where OpenSSL has been installed run a Sage binary package ?
>
> If the answer to those questions are both "yes", this describes a 
> situation very close to what I suggest to endorse by depending officially 
> on OpenSSL.
>
> --
> Emmanuel Charpentier
>  
>
> Hence the following is still possible, without having openssl-dev as a 
> system prerequisite: 
>
> - check that openssl-dev (or equivalent) is installed system-wide 
> - if not: 
>   - warn the user and suggest/recommend her to install it 
>   - as an alternative, propose to download and install openssl from the 
> Sage mirrors via http 
> - build Sage 
>
> Ciao, 
> Thierry 
>
>
>
> > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> > files as a prerequisite to building Sage ? This would require of the 
> user 
> > to install OpenSSL systemwide, thus making it "system software" and 
> > satisfying the strange licensing requirements that bother us. 
> > 
> > One could even do that indirectly, by requiring a systemwide libcurl 
> > supporting https : this would de facto enforce the systemwide 
> installation 
> > of OpenSSL (or a reasonable facsimile). That's what I was trying to do 
> in this 
> > proposal ... (IIRC, 
> the 
> > problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> > problem. But I'll have to check : if this is true, we can require 
> OpenSSL 
> > and ship libcurl which will then compile cleanly). 
> > 
> > Comments ? Especially wrt Macs, which seem to be further encumbered by 
> > Apple's dirty tricks... 
> > 
> > Should we have a vote ? 
> > 
> > -- 
> > 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+...@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/topic/sage-devel/92OdoUbBDbE/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 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] OpenSSL as a new systemwide Sage dependency ?

[Samuel Lelievre]

Emmanuel Charpentier:

> Dima Pasechnik:
>
> > I was referring to the fact that
> > https://github.com/sagemath/binary-pkg
> > does not work on OSX 10.12, due to this SSL blues.
> >
> > Unless I misunderstand, we currently aren't able
> > to build distributable Sage binaries on OSX 10.12.
>
> OK. That's different. If I read you correctly, you mean that
> a binary packaging of Sage won't run on a Mac that hasn't
> somehow received OpenSSL's baptism ?

To clarify, "binary-pkg" is Volker Braun's replacement
for the former "sage -bdist", ie the engine to produce
a binary distribution from an existing source install.

In other words, say you have built Sage from source on
architecture X, and you want to produce binaries for all
your friends that are also using architecture X, then
that's what you run.

-- 
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] Re: OpenSSL as a new systemwide Sage dependency ?

[Volker Braun]

Actually OSX is foobar'ed even then, Apple's ancient openssl just doesn't 
support TLSv1.2. Some sites are already requiring that:

osx:~ vbraun$ openssl s_client -connect www.kernel.org:443
CONNECTED(0003)
write:errno=54



On Monday, November 21, 2016 at 12:21:31 PM UTC+1, Emmanuel Charpentier 
wrote:
>
> Dear list,
>
> The fact that we can't ship openSSL (see uncountable theads in sage-devel 
> and others) seems to pose more and more difficulties. See for example this 
> thread  
> on sage-support, and especially Dima's answer 
> , 
> as well as this annoying ticket , 
> discussed in this saga 
>  . 
>
> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> files as a prerequisite to building Sage ? This would require of the user 
> to install OpenSSL systemwide, thus making it "system software" and 
> satisfying the strange licensing requirements that bother us.
>
> One could even do that indirectly, by requiring a systemwide libcurl 
> supporting https : this would de facto enforce the systemwide installation 
> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in 
> this 
> proposal ... (IIRC, 
> the problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> problem. But I'll have to check : if this is true, we can require OpenSSL 
> and ship libcurl which will then compile cleanly).
>
> Comments ? Especially wrt Macs, which seem to be further encumbered by 
> Apple's dirty tricks...
>
> Should we have a vote ?
>
> --
> 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] OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Le lundi 21 novembre 2016 à 10:15 -0800, Samuel Lelievre a écrit :
> Emmanuel Charpentier:
> 
> > Dima Pasechnik:
> >
> > > I was referring to the fact that
> > > https://github.com/sagemath/binary-pkg
> > > does not work on OSX 10.12, due to this SSL blues.
> > >
> > > Unless I misunderstand, we currently aren't able
> > > to build distributable Sage binaries on OSX 10.12.
> >
> > OK. That's different. If I read you correctly, you mean that
> > a binary packaging of Sage won't run on a Mac that hasn't
> > somehow received OpenSSL's baptism ?
> 
> To clarify, "binary-pkg" is Volker Braun's replacement
> for the former "sage -bdist", ie the engine to produce
> a binary distribution from an existing source install.
> 
> In other words, say you have built Sage from source on
> architecture X, and you want to produce binaries for all
> your friends that are also using architecture X, then
> that's what you run.

What my dentist's very little mind understands so far :1) OpenSSL *can*
be installed on a Max OSX 10.122) Sage *can* be built successfully on
OSX 10.123) sage-pkg *cannot* create a redistributable binary So far,
tha'ts but half a problem (we still don't have binary packages for
cygwin either...). More serious it Volker's observation (other mail in
this thread) that 4) OpenSSL on Mac OSX currently currently doesn't
support TLS V1.2if I understand correctly what he means.
What are the known ways to get a correctly-functionning libcurl on Mac
OSX 10.12 ?
--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/top
> ic/sage-devel/92OdoUbBDbE/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to s
> age-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.

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Le lundi 21 novembre 2016 à 10:17 -0800, Volker Braun a écrit :
> Actually OSX is foobar'ed even then, Apple's ancient openssl just
> doesn't support TLSv1.2. Some sites are already requiring that:
> osx:~ vbraun$ openssl s_client -connect www.kernel.org:443
> CONNECTED(0003)
> write:errno=54

Mmm  According to https://www.openssl.org/, OpenSSL latest version is
1.1.0c (dated Noc 10, 2016), which, according to
http://mac.softpedia.com/get/Security/OpenSSL.shtml, compiles on a Mac.
Does this compilation present special difficulties ?
--Emmanuel Charpentier
> > Dear list,
> > 
> > The fact that we can't ship openSSL (see uncountable theads in
> > sage-devel and others) seems to pose more and more difficulties.
> > See for example this thread on sage-support, and especially Dima's
> > answer, as well as this annoying ticket, discussed in this saga . 
> > 
> > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s
> > development files as a prerequisite to building Sage ? This would
> > require of the user to install OpenSSL systemwide, thus making it
> > "system software" and satisfying the strange licensing requirements
> > that bother us.
> > 
> > One could even do that indirectly, by requiring a systemwide
> > libcurl supporting https : this would de facto enforce the
> > systemwide installation of OpenSSL (or a reasonable facsimile).
> > That's what I was trying to do in  this proposal... (IIRC, the
> > problem with libcurl is also bound to OpenSSL : libcurl itself is
> > not a problem. But I'll have to check : if this is true, we can
> > require OpenSSL and ship libcurl which will then compile cleanly).
> > 
> > Comments ? Especially wrt Macs, which seem to be further encumbered
> > by Apple's dirty tricks...
> > 
> > Should we have a vote ?
> > 
> > --
> > 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/top
> ic/sage-devel/92OdoUbBDbE/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to s
> age-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.

[sage-devel] Implements change_ring() for BooleanPolynomialRing (#21817) -- Needs Review

[Rusydi H. Makarim]

Hi,

This patch (#21817 ) implements a
dedicated change_ring() for BooleanPolynomialRing. Previous change_ring()
uses the one implemented in MPolynomialRing_generic as the parent of
BooleanPolynomialRing. This makes change_ring() always return a
multivariate polynomial ring. But I argue that a proper behaviour of
change_ring() in BooleanPolynomialRing is to return a BooleanPolynomialRing
whenever a base_ring is not given in the argument and return multivariate
polynomial ring otherwise.

Regards,
-- 
Rusydi H. Makarim

PhD Student
Mathematisch Instituut , Universiteit Leiden
 and
Cryptology Group , Centrum
Wiskunde & Informatica (CWI) 
Amsterdam, the Netherlands
Email : maka...@cwi.nl, r.h.maka...@math.leidenuniv.nl
Web : http://pub.math.leidenuniv.nl/~makarimrh/


-- 
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: OpenSSL as a new systemwide Sage dependency ?

[Dima Pasechnik]

On Monday, November 21, 2016 at 7:10:49 PM UTC, Emmanuel Charpentier wrote:
>
> Le lundi 21 novembre 2016 à 10:17 -0800, Volker Braun a écrit :
>
> Actually OSX is foobar'ed even then, Apple's ancient openssl just doesn't 
> support TLSv1.2. Some sites are already requiring that:
>
> osx:~ vbraun$ openssl s_client -connect www.kernel.org:443
> CONNECTED(0003)
> write:errno=54
>
>
>
> Mmm According to https://www.openssl.org/, OpenSSL latest version is 
> 1.1.0c (dated Noc 10, 2016), which, according to 
> http://mac.softpedia.com/get/Security/OpenSSL.shtml 
> ,
>  
> compiles on a Mac.
>
> Does this compilation present special difficulties ?
>

in fact, it seems to work; last time I tried it at sage -sh prompt, with 
Sage's gcc, and it didn't do what I needed.

I'm trying the whole binary-pkg thing now, with openssl built by Xcode and 
installed in /usr/local
(not sure whether the build has used extra things I have installed, like 
extra Perl packages---
yes, OpenSSL 1.1.* has its own, Perl-based, configure system...)

Anyhow, I'm stuck at the same place - that git cannot be built, see
https://github.com/sagemath/binary-pkg/issues/8




> --
> Emmanuel Charpentier
>
> Dear list,
>
> The fact that we can't ship openSSL (see uncountable theads in sage-devel 
> and others) seems to pose more and more difficulties. See for example this 
> thread  
> on sage-support, and especially Dima's answer 
> , 
> as well as this annoying ticket , 
> discussed in this saga 
>  . 
>
> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
> files as a prerequisite to building Sage ? This would require of the user 
> to install OpenSSL systemwide, thus making it "system software" and 
> satisfying the strange licensing requirements that bother us.
>
> One could even do that indirectly, by requiring a systemwide libcurl 
> supporting https : this would de facto enforce the systemwide installation 
> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in 
> this 
> proposal ... (IIRC, 
> the problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
> problem. But I'll have to check : if this is true, we can require OpenSSL 
> and ship libcurl which will then compile cleanly).
>
> Comments ? Especially wrt Macs, which seem to be further encumbered by 
> Apple's dirty tricks...
>
> Should we have a vote ?
>
> --
> 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/92OdoUbBDbE/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 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] Re: OpenSSL as a new systemwide Sage dependency ?

[Dima Pasechnik]

On Monday, November 21, 2016 at 5:26:12 PM UTC, Dima Pasechnik wrote:
>
>
>
> On Monday, November 21, 2016 at 11:21:31 AM UTC, Emmanuel Charpentier 
> wrote:
>>
>> Dear list,
>>
>> The fact that we can't ship openSSL (see uncountable theads in sage-devel 
>> and others) seems to pose more and more difficulties. See for example this 
>> thread  
>> on sage-support, and especially Dima's answer 
>> , 
>> as well as this annoying ticket , 
>> discussed in this saga 
>>  . 
>>
>> Could'nt we add OpenSSL as a prerequisite to Sage, and it"s development 
>> files as a prerequisite to building Sage ? This would require of the user 
>> to install OpenSSL systemwide, thus making it "system software" and 
>> satisfying the strange licensing requirements that bother us.
>>
>
> Try installing OpenSSL on an OSX 10.12 Mac using just XCode!
> You might be in for a surprise.
>

I take it back - it works; you might still have to keep telling your 
building system where to find headers and libraries, 
like ./configure --with-openssl=/usr/local (etc)

This is not quite "systemwide", if you ask me.
That is, I suppose we would need to have a --with-openssl= parameter in the 
toplevel Sage configure taking care of this.

Dima



 

>  
>
>>
>> One could even do that indirectly, by requiring a systemwide libcurl 
>> supporting https : this would de facto enforce the systemwide installation 
>> of OpenSSL (or a reasonable facsimile). That's what I was trying to do in 
>> this 
>> proposal ... (IIRC, 
>> the problem with libcurl is also bound to OpenSSL : libcurl itself is not a 
>> problem. But I'll have to check : if this is true, we can require OpenSSL 
>> and ship libcurl which will then compile cleanly).
>>
>> Comments ? Especially wrt Macs, which seem to be further encumbered by 
>> Apple's dirty tricks...
>>
>> Should we have a vote ?
>>
>> --
>> 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.

[sage-devel] Error building openblas-0.2.19

[Christian Stump]

I just compiled sage-7.5.beta3 on a brand-new computer (also tried 7.4 with 
the same outcome) and openblas-0.2.19 failed to build with the attached 
error message (apparently different from previous problems with a missing 
library):

Makefile:123: *** OpenBLAS: Detecting CPU failed. Please set TARGET 
explicitly, e.g. make TARGET=your_cpu_target. Please read README for the 
detail..  Stop.

Any ideas how I can get it running? Thanks!

-- 
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.
Found local metadata for openblas-0.2.19
Using cached file /home/stumpc5/Programs/sage/upstream/OpenBLAS-0.2.19.tar.gz
openblas-0.2.19

Setting up build directory for openblas-0.2.19
Finished extraction

Host system:
Linux associahedron 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) 

patching file utest/Makefile
Building OpenBLAS: make 
make[3]: Entering directory 
'/home/stumpc5/Programs/sage/local/var/tmp/sage/build/openblas-0.2.19/src'
getarch_2nd.c: In function 'main':
getarch_2nd.c:12:35: error: 'SGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function)
 printf("SGEMM_UNROLL_M=%d\n", SGEMM_DEFAULT_UNROLL_M);
   ^~
getarch_2nd.c:12:35: note: each undeclared identifier is reported only once for 
each function it appears in
getarch_2nd.c:13:35: error: 'SGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function)
 printf("SGEMM_UNROLL_N=%d\n", SGEMM_DEFAULT_UNROLL_N);
   ^~
getarch_2nd.c:14:35: error: 'DGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function)
 printf("DGEMM_UNROLL_M=%d\n", DGEMM_DEFAULT_UNROLL_M);
   ^~
getarch_2nd.c:15:35: error: 'DGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function)
 printf("DGEMM_UNROLL_N=%d\n", DGEMM_DEFAULT_UNROLL_N);
   ^~
getarch_2nd.c:19:35: error: 'CGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function)
 printf("CGEMM_UNROLL_M=%d\n", CGEMM_DEFAULT_UNROLL_M);
   ^~
getarch_2nd.c:20:35: error: 'CGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function)
 printf("CGEMM_UNROLL_N=%d\n", CGEMM_DEFAULT_UNROLL_N);
   ^~
getarch_2nd.c:21:35: error: 'ZGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function)
 printf("ZGEMM_UNROLL_M=%d\n", ZGEMM_DEFAULT_UNROLL_M);
   ^~
getarch_2nd.c:22:35: error: 'ZGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function)
 printf("ZGEMM_UNROLL_N=%d\n", ZGEMM_DEFAULT_UNROLL_N);
   ^~
getarch_2nd.c:69:50: error: 'SGEMM_DEFAULT_Q' undeclared (first use in this 
function)
 printf("#d

[sage-devel] Re: Error building openblas-0.2.19

['Martin R' via sage-devel]

You will probably need a variation of the following:

https://groups.google.com/d/msg/sage-release/3QJoAgg9bgo/5uvnTLV1AwAJ

Martin

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