octave license is incompatible with openssl

octave license is incompatible with openssl

[Alex Vong]

Hi guixes,

First, congratulations to Ricardo Wurmus as new maintainer and the new
0.11 release is good (it passed all tests)!

I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
far as I know, gplv3 is incompatible with openssl license
(https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

How should we fix this?


Cheers,
Alex

Re: octave license is incompatible with openssl

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

I would not be at all suprised if there were more incompatibilities like
this.  Ought we not have  a lint rule that checks this?

J'

On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
     Hi guixes,
     
     First, congratulations to Ricardo Wurmus as new maintainer and the new
     0.11 release is good (it passed all tests)!
     
     I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
     far as I know, gplv3 is incompatible with openssl license
     (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
     
     How should we fix this?
     
     
     Cheers,
     Alex

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: octave license is incompatible with openssl

[ng0]

John Darrington <john@darrington.wattle.id.au> writes:

> I would not be at all suprised if there were more incompatibilities like
> this.  Ought we not have  a lint rule that checks this?
>
> J'
>
> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>      Hi guixes,
>      
>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>      0.11 release is good (it passed all tests)!
>      
>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>      far as I know, gplv3 is incompatible with openssl license
>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>      
>      How should we fix this?
>      
>      
>      Cheers,
>      Alex
>
> -- 
> Avoid eavesdropping.  Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>

Isn't this an upstream problem? I don't know octave but is openssl
required? Can it be replaced by something different?

Does this require upstream action/reporting?
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: octave license is incompatible with openssl

[Ricardo Wurmus]

Alex Vong <alexvong1995@gmail.com> writes:

> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
> far as I know, gplv3 is incompatible with openssl license
> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

Looks like you’re right.  Other projects add a special openSSL linking
exception, but Octave does not seem to account for this.

> How should we fix this?

It seems that the use of openssl in Octave is optional, so we could
probably just remove it.  From a cursory look it appears that it is used
for not much more than the MD5 algorithm.  Would you like to submit a
patch that removes openssl from the inputs?

It would be good to ask the Octave project if it would be possible to
replace OpenSSL with, say, GnuTLS.

~~ Ricardo

Re: octave license is incompatible with openssl

[Alex Vong]

John Darrington <john@darrington.wattle.id.au> writes:

> I would not be at all suprised if there were more incompatibilities like
> this.  Ought we not have  a lint rule that checks this?
>
Indeed, in the short term, we could lint for special case, such that
openssl appears as an input for an GPLv[123](+) package.


In the long term, we could have the following in guix. Since licenses
are scheme values. I was thinking we can have procedure like:

  (compatible? l1 l2)

which is a reflexive and symmetric relation. Also, we might be able to
build compound licenses by:

  (dual-license lics ...)

and

  (intersect-license lics ...)

The 3 procedures should satisfy the following "laws":

  (compatible? l1 (dual-license lics ...))

if and only if

  (any (cut compatible? l1  <>) lics)

Similarly,

  (compatible? l1 (intersect-license lics ...))

if and only if

  (every (cut compatible? l1  <>) lics)


How do everyone think?

Cheers,
Alex

> J'
>
> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>      Hi guixes,
>      
>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>      0.11 release is good (it passed all tests)!
>      
>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>      far as I know, gplv3 is incompatible with openssl license
>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>      
>      How should we fix this?
>      
>      
>      Cheers,
>      Alex

Re: octave license is incompatible with openssl

[Alex Vong]

ng0 <ng0@we.make.ritual.n0.is> writes:

> John Darrington <john@darrington.wattle.id.au> writes:
>
>> I would not be at all suprised if there were more incompatibilities like
>> this.  Ought we not have  a lint rule that checks this?
>>
>> J'
>>
>> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>>      Hi guixes,
>>      
>>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>>      0.11 release is good (it passed all tests)!
>>      
>>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>>      far as I know, gplv3 is incompatible with openssl license
>>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>>      
>>      How should we fix this?
>>      
>>      
>>      Cheers,
>>      Alex
>>
>> -- 
>> Avoid eavesdropping.  Send strong encryted email.
>> PGP Public key ID: 1024D/2DE827B3 
>> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
>> See http://sks-keyservers.net or any PGP keyserver for public key.
>>
>
> Isn't this an upstream problem? I don't know octave but is openssl
> required? Can it be replaced by something different?
>
> Does this require upstream action/reporting?

I remember reading that octave devs are aware of the problem, but it is
difficult to change the license since octave has no copyright assignment
(like guix), Note that this is from my memory, so I could have got it
wrong.

Re: octave license is incompatible with openssl

[Mathieu Lirzin]

Alex Vong <alexvong1995@gmail.com> writes:

> John Darrington <john@darrington.wattle.id.au> writes:
>
>> I would not be at all suprised if there were more incompatibilities like
>> this.  Ought we not have  a lint rule that checks this?
>>
> Indeed, in the short term, we could lint for special case, such that
> openssl appears as an input for an GPLv[123](+) package.
>
>
> In the long term, we could have the following in guix. Since licenses
> are scheme values. I was thinking we can have procedure like:
>
>   (compatible? l1 l2)
>
> which is a reflexive and symmetric relation. Also, we might be able to
> build compound licenses by:
>
>   (dual-license lics ...)
>
> and
>
>   (intersect-license lics ...)
>
> The 3 procedures should satisfy the following "laws":
>
>   (compatible? l1 (dual-license lics ...))
>
> if and only if
>
>   (any (cut compatible? l1  <>) lics)
>
> Similarly,
>
>   (compatible? l1 (intersect-license lics ...))
>
> if and only if
>
>   (every (cut compatible? l1  <>) lics)
>
>
> How do everyone think?
>

I like the idea!

-- 
Mathieu Lirzin

Re: octave license is incompatible with openssl

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>> far as I know, gplv3 is incompatible with openssl license
>> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>
> Looks like you’re right.  Other projects add a special openSSL linking
> exception, but Octave does not seem to account for this.
>
>> How should we fix this?
>
> It seems that the use of openssl in Octave is optional, so we could
> probably just remove it.  From a cursory look it appears that it is used
> for not much more than the MD5 algorithm.  Would you like to submit a
> patch that removes openssl from the inputs?
>
Here it is. It takes a long time to track down that curl is pulling the
openssl depedency. I also upgrade octave to 4.0.3 and change to use
'tar.xz'.

> It would be good to ask the Octave project if it would be possible to
> replace OpenSSL with, say, GnuTLS.
>
I agree, should we CC/forward this discussion to octave-devel list?

> ~~ Ricardo

Cheers,
Alex


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-octave-Update-to-4.0.3.patch --]
[-- Type: text/x-diff, Size: 1923 bytes --]

From f813b22539c6cefd49471f7df3adc4b02ebcd76c Mon Sep 17 00:00:00 2001
From: Alex Vong <alexvong1995@gmail.com>
Date: Sat, 6 Aug 2016 08:52:34 +0800
Subject: [PATCH] gnu: octave: Update to 4.0.3.

  * gnu/packages/maths.scm (octave): Update to 4.0.3.
  [source]: Change to '.tar.xz'.
  [inputs]: Remove dependencies on openssl and curl.
---
 gnu/packages/maths.scm | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index fcea0bc..149c533 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -692,16 +692,19 @@ can solve two kinds of problems:
 (define-public octave
   (package
     (name "octave")
-    (version "4.0.2")
+    (version "4.0.3")
     (source
      (origin
       (method url-fetch)
       (uri (string-append "mirror://gnu/octave/octave-"
-                          version ".tar.gz"))
+                          version ".tar.xz"))
       (sha256
        (base32
-        "1hdxap3j88rpqjimnfhinym6z73wdi5dfa6fv85c13r1dk9qzk9r"))))
+        "11day29k4yfvxh4101x5yf26ld992x5n6qvmhjjk6mzsd26fqayw"))))
     (build-system gnu-build-system)
+    ;; Ideally, curl should be in the list of inputs to enable ftp support.
+    ;; It isn't because it causes octave to link against openssl which isn't allowed
+    ;; as octave's license has no openssl exception at the moment.
     (inputs
      `(("lapack" ,lapack)
        ("readline" ,readline)
@@ -709,7 +712,6 @@ can solve two kinds of problems:
        ("fftw" ,fftw)
        ("fftwf" ,fftwf)
        ("arpack" ,arpack-ng)
-       ("curl" ,curl)
        ("pcre" ,pcre)
        ("cyrus-sasl" ,cyrus-sasl)
        ("fltk" ,fltk)
@@ -719,7 +721,6 @@ can solve two kinds of problems:
        ("libxft" ,libxft)
        ("mesa" ,mesa)
        ("glu" ,glu)
-       ("openssl" ,openssl)
        ("zlib" ,zlib)))
     (native-inputs
      `(("gfortran" ,gfortran)
-- 
2.9.2

Re: octave license is incompatible with openssl

[Leo Famulari]

On Sat, Aug 06, 2016 at 09:52:39AM +0800, Alex Vong wrote:
> Ricardo Wurmus <rekado@elephly.net> writes:
> 
> > Alex Vong <alexvong1995@gmail.com> writes:
> >
> >> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
> >> far as I know, gplv3 is incompatible with openssl license
> >> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
> >
> > Looks like you’re right.  Other projects add a special openSSL linking
> > exception, but Octave does not seem to account for this.
> >
> >> How should we fix this?
> >
> > It seems that the use of openssl in Octave is optional, so we could
> > probably just remove it.  From a cursory look it appears that it is used
> > for not much more than the MD5 algorithm.  Would you like to submit a
> > patch that removes openssl from the inputs?
> >
> Here it is. It takes a long time to track down that curl is pulling the
> openssl depedency. I also upgrade octave to 4.0.3 and change to use
> 'tar.xz'.
> 
> > It would be good to ask the Octave project if it would be possible to
> > replace OpenSSL with, say, GnuTLS.
> >
> I agree, should we CC/forward this discussion to octave-devel list?

Yes, I think we should work with them to resolve this issue.

Re: octave license is incompatible with openssl

[Alex Vong]

Hi octave devs,

During a look of the octave package in guix (a functional package
manager, part of gnu), we notice octave have an optional dependency on
openssl.

However, since the license of octave (gpl3+) is incompatible
with that of openssl
(https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
resulting binary after linking is not re-distributable.

So, we drop the optional dependency to avoid the problem.

Is there any plan to fix this problem? There are some solutions we think
of: 1. add openssl linking exception to the license 2. provide support
for linking with gnutls as an alternative. In any case, I think we
should warn the user about it.

What are your ideas? (the messages below include the whole discussion on
the guix-devel mailing list)

Thanks,
Alex

Leo Famulari <leo@famulari.name> writes:

> On Sat, Aug 06, 2016 at 09:52:39AM +0800, Alex Vong wrote:
>> Ricardo Wurmus <rekado@elephly.net> writes:
>> 
>> > Alex Vong <alexvong1995@gmail.com> writes:
>> >
>> >> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>> >> far as I know, gplv3 is incompatible with openssl license
>> >> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>> >
>> > Looks like you’re right.  Other projects add a special openSSL linking
>> > exception, but Octave does not seem to account for this.
>> >
>> >> How should we fix this?
>> >
>> > It seems that the use of openssl in Octave is optional, so we could
>> > probably just remove it.  From a cursory look it appears that it is used
>> > for not much more than the MD5 algorithm.  Would you like to submit a
>> > patch that removes openssl from the inputs?
>> >
>> Here it is. It takes a long time to track down that curl is pulling the
>> openssl depedency. I also upgrade octave to 4.0.3 and change to use
>> 'tar.xz'.
>> 
>> > It would be good to ask the Octave project if it would be possible to
>> > replace OpenSSL with, say, GnuTLS.
>> >
>> I agree, should we CC/forward this discussion to octave-devel list?
>
> Yes, I think we should work with them to resolve this issue.

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

Re: octave license is incompatible with openssl

[Mike Miller]

On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
> Hi octave devs,
> 
> During a look of the octave package in guix (a functional package
> manager, part of gnu), we notice octave have an optional dependency on
> openssl.
> 
> However, since the license of octave (gpl3+) is incompatible
> with that of openssl
> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
> resulting binary after linking is not re-distributable.

Agreed.

> So, we drop the optional dependency to avoid the problem.

Precisely what is the optional dependency that is dropped?

Octave does not directly link with OpenSSL nor use any OpenSSL
functions. The Octave package on Debian builds with all optional
dependencies enabled, and the resulting binary is linked with GnuTLS.

> Is there any plan to fix this problem? There are some solutions we think
> of: 1. add openssl linking exception to the license 2. provide support
> for linking with gnutls as an alternative. In any case, I think we
> should warn the user about it.
> 
> What are your ideas? (the messages below include the whole discussion on
> the guix-devel mailing list)

The Octave Guix package may be indirectly linking with OpenSSL through a
direct dependency such as libcurl. I would recommend that you use a
libcurl that is built against GnuTLS as we do on Debian.

AFAICS, nothing needs to be fixed in Octave.

HTH,

-- 
mike

Re: octave license is incompatible with openssl

[Ricardo Wurmus]

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>> So, we drop the optional dependency to avoid the problem.
>
> Precisely what is the optional dependency that is dropped?
>
> Octave does not directly link with OpenSSL nor use any OpenSSL
> functions. The Octave package on Debian builds with all optional
> dependencies enabled, and the resulting binary is linked with GnuTLS.

The “openssl” package (along with “cyrus-sasl”) was added as a new input
to our “octave” package in commit
b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
4.0.0 to 4.0.2.

I don’t know why this was done.  Maybe Kei could shed some light on
this.

~~ Ricardo

Re: octave license is incompatible with openssl

[kei]

On 2016-08-09 14:30, Ricardo Wurmus wrote:
> Mike Miller <mtmiller@octave.org> writes:
> 
>> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>>> So, we drop the optional dependency to avoid the problem.
>> 
>> Precisely what is the optional dependency that is dropped?
>> 
>> Octave does not directly link with OpenSSL nor use any OpenSSL
>> functions. The Octave package on Debian builds with all optional
>> dependencies enabled, and the resulting binary is linked with GnuTLS.
> 
> The “openssl” package (along with “cyrus-sasl”) was added as a new 
> input
> to our “octave” package in commit
> b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
> 4.0.0 to 4.0.2.
> 
> I don’t know why this was done.  Maybe Kei could shed some light on
> this.
> 
> ~~ Ricardo

When I tried to build Octave 4.0.2, the build complained about missing 
SSL
and SASL libraries. Adding gnutls as a dependency (Debian users are 
advised
to use libcurl4-gnutls-dev) did not fix the issue, so I added OpenSSL to
stop the issue. It seems to me that Octave 4.0.2 (and 4.0.3, the most 
recent
version) depends on SSL for curl usage, as curl allows Octave users to 
issue
a "pkg install -forge [package_name]" command to install packages from 
the
Octave Forge repo. I didn't know that the licenses were incompatible, so 
now
we have to name (or correctly package) the Guix equivalent of 
libcurl4-gnutls-dev.

Re: octave license is incompatible with openssl

[Mark H Weaver]

Mike Miller <mtmiller@octave.org> writes:
> I would recommend that you use a libcurl that is built against GnuTLS
> as we do on Debian.

Our libcurl is already built against GnuTLS.

     Mark

Re: octave license is incompatible with openssl

[Mark H Weaver]

kei@openmailbox.org writes:

> On 2016-08-09 14:30, Ricardo Wurmus wrote:
>> Mike Miller <mtmiller@octave.org> writes:
>>
>>> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>>>> So, we drop the optional dependency to avoid the problem.
>>>
>>> Precisely what is the optional dependency that is dropped?
>>>
>>> Octave does not directly link with OpenSSL nor use any OpenSSL
>>> functions. The Octave package on Debian builds with all optional
>>> dependencies enabled, and the resulting binary is linked with GnuTLS.
>>
>> The “openssl” package (along with “cyrus-sasl”) was added as a new
>> input
>> to our “octave” package in commit
>> b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
>> 4.0.0 to 4.0.2.
>>
>> I don’t know why this was done.  Maybe Kei could shed some light on
>> this.
>>
>> ~~ Ricardo
>
> When I tried to build Octave 4.0.2, the build complained about missing
> SSL and SASL libraries. Adding gnutls as a dependency (Debian users
> are advised to use libcurl4-gnutls-dev) did not fix the issue, so I
> added OpenSSL to stop the issue.

We should investigate the reason why it failed without OpenSSL.  I would
start by repeating the build attempt without OpenSSL, and looking at the
resulting config.log to see what went wrong.

> It seems to me that Octave 4.0.2 (and 4.0.3, the most recent version)
> depends on SSL for curl usage, as curl allows Octave users to issue a
> "pkg install -forge [package_name]" command to install packages from
> the Octave Forge repo. I didn't know that the licenses were
> incompatible, so now we have to name (or correctly package) the Guix
> equivalent of libcurl4-gnutls-dev.

'curl' is that package.  It is built against GnuTLS.

      Mark

Re: octave license is incompatible with openssl

[Alex Vong]

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>> Hi octave devs,
>> 
>> During a look of the octave package in guix (a functional package
>> manager, part of gnu), we notice octave have an optional dependency on
>> openssl.
>> 
>> However, since the license of octave (gpl3+) is incompatible
>> with that of openssl
>> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
>> resulting binary after linking is not re-distributable.
>
> Agreed.
>
>> So, we drop the optional dependency to avoid the problem.
>
> Precisely what is the optional dependency that is dropped?
>
> Octave does not directly link with OpenSSL nor use any OpenSSL
> functions. The Octave package on Debian builds with all optional
> dependencies enabled, and the resulting binary is linked with GnuTLS.
>
I thought it was an optional dependency because when I run
`./configure --help', it contains the following help:

  --with-openssl          use libcrypto hash routines. Valid ARGs are: 'yes',
                          'no', 'auto' => use if available, 'optional' => use
                          if available and warn if not available; default is
                          'no'


Perhaps someone unaware of the issue adds this? Should I open a bug
report on this?

>> Is there any plan to fix this problem? There are some solutions we think
>> of: 1. add openssl linking exception to the license 2. provide support
>> for linking with gnutls as an alternative. In any case, I think we
>> should warn the user about it.
>> 
>> What are your ideas? (the messages below include the whole discussion on
>> the guix-devel mailing list)
>
> The Octave Guix package may be indirectly linking with OpenSSL through a
> direct dependency such as libcurl. I would recommend that you use a
> libcurl that is built against GnuTLS as we do on Debian.
>
Indeed, the Debian package does not depend on openssl.

> AFAICS, nothing needs to be fixed in Octave.
>
> HTH,

Thanks,
Alex

Re: octave license is incompatible with openssl

[Mike Miller]

On Wed, Aug 10, 2016 at 00:28:04 -0400, Mark H Weaver wrote:
> We should investigate the reason why it failed without OpenSSL.  I would
> start by repeating the build attempt without OpenSSL, and looking at the
> resulting config.log to see what went wrong.

Sounds good to me. Let us know what you find out or if there is anything
we can do to help.

-- 
mike

Re: octave license is incompatible with openssl

[Mike Miller]

On Wed, Aug 10, 2016 at 14:43:57 +0800, Alex Vong wrote:
> I thought it was an optional dependency because when I run
> `./configure --help', it contains the following help:
> 
>   --with-openssl          use libcrypto hash routines. Valid ARGs are: 'yes',
>                           'no', 'auto' => use if available, 'optional' => use
>                           if available and warn if not available; default is
>                           'no'
> 
> 
> Perhaps someone unaware of the issue adds this? Should I open a bug
> report on this?

Thanks for pointing that out. I wasn't aware of this until now. This
configure option actually comes directly from the gnulib project. You'll
notice that the default is "no", which is exactly as it should be.

Octave provides some standard hash functions that are built on GPL
compatible functions provided by gnulib. As a side effect of enabling
these gnulib modules, gnulib automatically adds the `--with-openssl`
option to allow the user to specify that the OpenSSL libcrypto functions
should be used instead.

I couldn't find this described or documented anywhere, just had to go
digging through the configuration macros, e.g.

http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/gl-openssl.m4
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/sha1.m4

Cheers,

-- 
mike

Re: octave license is incompatible with openssl

[Mark H Weaver]

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:28:04 -0400, Mark H Weaver wrote:
>> We should investigate the reason why it failed without OpenSSL.  I would
>> start by repeating the build attempt without OpenSSL, and looking at the
>> resulting config.log to see what went wrong.
>
> Sounds good to me. Let us know what you find out or if there is anything
> we can do to help.

The problem is that "-lssl -lcrypto" is apparently added to the command
line when linking liboctave.  There are no occurrences of "lssl" in the
failed octave build directory.  However, I *did* discover that
libcurl.la contains:

  dependency_libs=' [...] -lssl -lcrypto -lz'

despite the fact that our 'curl' package was built without OpenSSL.  I
guess this is the root of the problem, and that the bug is in 'curl'.

I'm not sure why this problem does not affect more packages.  Perhaps
most packages in Guix that use 'curl' either don't use libtool or
include OpenSSL as an input.  If they didn't already include OpenSSL, I
guess that maybe people "fixed" the problem by adding OpenSSL as an
input, as was done for Octave.

To be continued...

     Mark

Re: octave license is incompatible with openssl

[Alex Vong]

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 14:43:57 +0800, Alex Vong wrote:
>> I thought it was an optional dependency because when I run
>> `./configure --help', it contains the following help:
>> 
>>   --with-openssl          use libcrypto hash routines. Valid ARGs are: 'yes',
>>                           'no', 'auto' => use if available, 'optional' => use
>>                           if available and warn if not available; default is
>>                           'no'
>> 
>> 
>> Perhaps someone unaware of the issue adds this? Should I open a bug
>> report on this?
>
> Thanks for pointing that out. I wasn't aware of this until now. This
> configure option actually comes directly from the gnulib project. You'll
> notice that the default is "no", which is exactly as it should be.
>
> Octave provides some standard hash functions that are built on GPL
> compatible functions provided by gnulib. As a side effect of enabling
> these gnulib modules, gnulib automatically adds the `--with-openssl`
> option to allow the user to specify that the OpenSSL libcrypto functions
> should be used instead.
>
> I couldn't find this described or documented anywhere, just had to go
> digging through the configuration macros, e.g.
>
> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/gl-openssl.m4
> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/sha1.m4
>
> Cheers,

I see. Thanks for the explaination. As Mark has pointed out, the problem
seems to be in the curl package.

Finally, some unrelated stuff, I hope octave would have a byte code
interpreter soon. I would suggest to write it in rpython, it seems to be
the easiest way to have jit these days.

Cheers,
Alex

Re: octave license is incompatible with openssl

[Kei Kebreau]

Alex Vong <alexvong1995@gmail.com> writes:

> Mike Miller <mtmiller@octave.org> writes:
>
>> On Wed, Aug 10, 2016 at 14:43:57 +0800, Alex Vong wrote:
>>> I thought it was an optional dependency because when I run
>>> `./configure --help', it contains the following help:
>>> 
>>>   --with-openssl          use libcrypto hash routines. Valid ARGs are: 'yes',
>>>                           'no', 'auto' => use if available, 'optional' => use
>>>                           if available and warn if not available; default is
>>>                           'no'
>>> 
>>> 
>>> Perhaps someone unaware of the issue adds this? Should I open a bug
>>> report on this?
>>
>> Thanks for pointing that out. I wasn't aware of this until now. This
>> configure option actually comes directly from the gnulib project. You'll
>> notice that the default is "no", which is exactly as it should be.
>>
>> Octave provides some standard hash functions that are built on GPL
>> compatible functions provided by gnulib. As a side effect of enabling
>> these gnulib modules, gnulib automatically adds the `--with-openssl`
>> option to allow the user to specify that the OpenSSL libcrypto functions
>> should be used instead.
>>
>> I couldn't find this described or documented anywhere, just had to go
>> digging through the configuration macros, e.g.
>>
>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/gl-openssl.m4
>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/sha1.m4
>>
>> Cheers,
>
> I see. Thanks for the explaination. As Mark has pointed out, the problem
> seems to be in the curl package.
>
> Finally, some unrelated stuff, I hope octave would have a byte code
> interpreter soon. I would suggest to write it in rpython, it seems to be
> the easiest way to have jit these days.
>
> Cheers,
> Alex

IIRC, Octave has experimental JIT support using LLVM.

JIT compiling

[Jordi Gutiérrez Hermoso]

On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
> Finally, some unrelated stuff, I hope octave would have a byte code
> interpreter soon. I would suggest to write it in rpython, it seems
> to be the easiest way to have jit these days.

That is a faraway pipe dream. Can you help?

- Jordi G. H.

Re: JIT compiling

[Sergei Steshenko]

>________________________________
> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>To: Alex Vong <alexvong1995@gmail.com> 
>Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
>Sent: Friday, August 12, 2016 2:45 PM
>Subject: JIT compiling
> 
>
>On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>> Finally, some unrelated stuff, I hope octave would have a byte code
>> interpreter soon. I would suggest to write it in rpython, it seems
>> to be the easiest way to have jit these days.
>
>That is a faraway pipe dream. Can you help?
>
>- Jordi G. H.
>
>


Julia ( http://julialang.org/ ) quite developed since it's been discussed here. They claim to have close to "C" performance and JIT.

And MIT (no GPL bullshit) license.

--Sergei.

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

Re: JIT compiling

[Oliver Heimlich]

On 12.08.2016 17:08, Sergei Steshenko wrote:
>> ________________________________
>> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>> To: Alex Vong <alexvong1995@gmail.com> 
>> Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
>> Sent: Friday, August 12, 2016 2:45 PM
>> Subject: JIT compiling
>>
>>
>> On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>> Finally, some unrelated stuff, I hope octave would have a byte code
>>> interpreter soon. I would suggest to write it in rpython, it seems
>>> to be the easiest way to have jit these days.
>>
>> That is a faraway pipe dream. Can you help?
>>
>> - Jordi G. H.
>>
>>
> 
> 
> Julia ( http://julialang.org/ ) quite developed since it's been discussed here. They claim to have close to "C" performance and JIT.
> 

There is a good language introduction available as a talk from JuliaCon:
https://youtu.be/rAxzR7lMGDM

As far as I can see, Julia compiles the code if it can predict the types
of the variables. Otherwise, it is slow. This is explained in the first
part of the talk.

Best
Oliver


_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

Re: JIT compiling

[Sergei Steshenko]

----- Original Message -----
> From: Oliver Heimlich <oheim@posteo.de>
> To: Sergei Steshenko <sergstesh@yahoo.com>; Jordi Gutiérrez Hermoso <jordigh@octave.org>; Alex Vong <alexvong1995@gmail.com>
> Cc: Ricardo Wurmus <rekado@elephly.net>; "guix-devel@gnu.org" <guix-devel@gnu.org>; Leo Famulari <leo@famulari.name>; "help-octave@gnu.org" <help-octave@gnu.org>; Mike Miller <mtmiller@octave.org>
> Sent: Friday, August 12, 2016 7:06 PM
> Subject: Re: JIT compiling
> 
> On 12.08.2016 17:08, Sergei Steshenko wrote:
> 
>>>  ________________________________
>>>  From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>>>  To: Alex Vong <alexvong1995@gmail.com> 
>>>  Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo 
> Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller 
> <mtmiller@octave.org>
>>>  Sent: Friday, August 12, 2016 2:45 PM
>>>  Subject: JIT compiling
>>> 
>>> 
>>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>>  Finally, some unrelated stuff, I hope octave would have a byte code
>>>>  interpreter soon. I would suggest to write it in rpython, it seems
>>>>  to be the easiest way to have jit these days.
>>> 
>>>  That is a faraway pipe dream. Can you help?
>>> 
>>>  - Jordi G. H.
>>> 
>>> 
>> 
>> 
>>  Julia ( http://julialang.org/ ) quite developed since it's been 
> discussed here. They claim to have close to "C" performance and JIT.
>> 
> 
> There is a good language introduction available as a talk from JuliaCon:
> https://youtu.be/rAxzR7lMGDM
> 
> As far as I can see, Julia compiles the code if it can predict the types
> of the variables. Otherwise, it is slow. This is explained in the first
> part of the talk.
> 
> Best
> Oliver
> 


If the type can't be predicted, then runtime checks need to be made and the object might have to be recreated. E.g. if 12345678 is a number, it fits a 32 bit integer, and if it is a string, it will need 9 bytes in case of "C" representation.


So the limitation does not look to me like a Julia-specific one.

--Sergei.

Re: JIT compiling

[Alex Vong]

Sergei Steshenko <sergstesh@yahoo.com> writes:

> ----- Original Message -----
>> From: Oliver Heimlich <oheim@posteo.de>
>> To: Sergei Steshenko <sergstesh@yahoo.com>; Jordi Gutiérrez Hermoso
>> <jordigh@octave.org>; Alex Vong <alexvong1995@gmail.com>
>> Cc: Ricardo Wurmus <rekado@elephly.net>; "guix-devel@gnu.org"
>> <guix-devel@gnu.org>; Leo Famulari <leo@famulari.name>;
>> "help-octave@gnu.org" <help-octave@gnu.org>; Mike Miller
>> <mtmiller@octave.org>
>> Sent: Friday, August 12, 2016 7:06 PM
>> Subject: Re: JIT compiling
>> 
>> On 12.08.2016 17:08, Sergei Steshenko wrote:
>> 
>>>>  ________________________________
>>>>  From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>>>>  To: Alex Vong <alexvong1995@gmail.com> 
>>>>  Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo 
>> Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller 
>> <mtmiller@octave.org>
>>>>  Sent: Friday, August 12, 2016 2:45 PM
>>>>  Subject: JIT compiling
>>>> 
>>>> 
>>>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>>>  Finally, some unrelated stuff, I hope octave would have a byte code
>>>>>  interpreter soon. I would suggest to write it in rpython, it seems
>>>>>  to be the easiest way to have jit these days.
>>>> 
>>>>  That is a faraway pipe dream. Can you help?
>>>> 
>>>>  - Jordi G. H.
>>>> 
>>>> 
>>> 
>>> 
>>>  Julia ( http://julialang.org/ ) quite developed since it's been 
>> discussed here. They claim to have close to "C" performance and JIT.
>>> 
>> 
>> There is a good language introduction available as a talk from JuliaCon:
>> https://youtu.be/rAxzR7lMGDM
>> 
>> As far as I can see, Julia compiles the code if it can predict the types
>> of the variables. Otherwise, it is slow. This is explained in the first
>> part of the talk.
>> 
>> Best
>> Oliver
>> 
>
>
> If the type can't be predicted, then runtime checks need to be made
> and the object might have to be recreated. E.g. if 12345678 is a
> number, it fits a 32 bit integer, and if it is a string, it will need
> 9 bytes in case of "C" representation.
>
I think in the case of jit, many of the checks can be removed by making
certain assumptions and inserts guards to check those assumptions. If
the assumptions turn out to be false, then the compiled code will be
trashed and available for jitting again.
>
> So the limitation does not look to me like a Julia-specific one.
>
> --Sergei.

Re: JIT compiling

[Alex Vong]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>> Finally, some unrelated stuff, I hope octave would have a byte code
>> interpreter soon. I would suggest to write it in rpython, it seems
>> to be the easiest way to have jit these days.
>
> That is a faraway pipe dream. Can you help?
>
I think I will be too un-experienced to help, but I am interested in
it. I've always dreamt octave having good anoymous and nested function
support. I think the first step is to prase octave correctly. Is there a
reference on it other than the libinterp code itself?

> - Jordi G. H.

Cheers,
Alex

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

Re: octave license is incompatible with openssl

[Alex Vong]

Kei Kebreau <kei@openmailbox.org> writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Mike Miller <mtmiller@octave.org> writes:
>>
>>> On Wed, Aug 10, 2016 at 14:43:57 +0800, Alex Vong wrote:
>>>> I thought it was an optional dependency because when I run
>>>> `./configure --help', it contains the following help:
>>>> 
>>>>   --with-openssl          use libcrypto hash routines. Valid ARGs are: 'yes',
>>>>                           'no', 'auto' => use if available, 'optional' => use
>>>>                           if available and warn if not available; default is
>>>>                           'no'
>>>> 
>>>> 
>>>> Perhaps someone unaware of the issue adds this? Should I open a bug
>>>> report on this?
>>>
>>> Thanks for pointing that out. I wasn't aware of this until now. This
>>> configure option actually comes directly from the gnulib project. You'll
>>> notice that the default is "no", which is exactly as it should be.
>>>
>>> Octave provides some standard hash functions that are built on GPL
>>> compatible functions provided by gnulib. As a side effect of enabling
>>> these gnulib modules, gnulib automatically adds the `--with-openssl`
>>> option to allow the user to specify that the OpenSSL libcrypto functions
>>> should be used instead.
>>>
>>> I couldn't find this described or documented anywhere, just had to go
>>> digging through the configuration macros, e.g.
>>>
>>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/gl-openssl.m4
>>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/sha1.m4
>>>
>>> Cheers,
>>
>> I see. Thanks for the explaination. As Mark has pointed out, the problem
>> seems to be in the curl package.
>>
>> Finally, some unrelated stuff, I hope octave would have a byte code
>> interpreter soon. I would suggest to write it in rpython, it seems to be
>> the easiest way to have jit these days.
>>
>> Cheers,
>> Alex
>
> IIRC, Octave has experimental JIT support using LLVM.

Yes, I am aware that octave has an experimental llvm jit, but I heard
that llvm is a quick moving target and the api is not as stable as you
would like. Much energy needed to be devoted to simply keep in sync with
upstream.

Also, writing in restricted python seems more pleasant than c++. The jit
is auto-generated in the sense that you only need to mark when the loop
starts and when the loop stops. Finally, there is even a paper
(understandable to hobbyists) on implementing racket using
rpython[0]. These all looks promising to me.

The really downside is that the translation time is super long (time
takes to build the interpreter), because expensive static analysis needs
to be performed to remove malloc, assertions, inline function
calls... to make the interpreter itself fast enough (not the code it
generates I guess).

[0]: http://homes.soic.indiana.edu/samth/pycket-draft.pdf

Re: JIT compiling

[Sergei Steshenko]

----- Original Message -----
> From: Alex Vong <alexvong1995@gmail.com>
> To: Jordi Gutiérrez Hermoso <jordigh@octave.org>
> Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
> Sent: Saturday, August 13, 2016 3:12 PM
> Subject: Re: JIT compiling
> 
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>  Finally, some unrelated stuff, I hope octave would have a byte code
>>>  interpreter soon. I would suggest to write it in rpython, it seems
>>>  to be the easiest way to have jit these days.
>> 
>>  That is a faraway pipe dream. Can you help?
>> 
> I think I will be too un-experienced to help, but I am interested in
> it. I've always dreamt octave having good anoymous and nested function
> support. I think the first step is to prase octave correctly. Is there a
> reference on it other than the libinterp code itself?
> 
>>  - Jordi G. H.
> 
> Cheers,
> 
> Alex
> 
> _______________________________________________
> Help-octave mailing list
> Help-octave@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-octave

> 


"I've always dreamt octave having good anoymous and nested function

support" - then switch to Perl -> PDL (http://pdl.perl.org/) or OCaml (if you want type strictness and near "C" performance).

...

When Julia language was first discussed here, I suggested to write an Octave -> Julia translator, but I think it will NEVER be done for ideological (fanatic support of false/fake GPL freedom) reasons.


The rationale was to get the best of the two worlds - speed of Julia and packages available for Octave - in addition to what already exists for Julia.

--Sergei.

Re: JIT compiling

[Francesco Potortì]

>When Julia language was first discussed here, I suggested to write an
>Octave -> Julia translator, but I think it will NEVER be done for
>ideological (fanatic support of false/fake GPL freedom) reasons.

Sergei,

you had stopped for a while insulting the Octave developers and the free
software community.  That was a good thing.  However, this is your
second message in few days that brings back your old habits.  You can do
better.  Please do.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it


_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

Re: JIT compiling

[Jordi Gutiérrez Hermoso]

Hi, Sergei. Haven't spoken in a while.

On Sun, 2016-08-14 at 08:07 +0000, Sergei Steshenko wrote:

> When Julia language was first discussed here, I suggested to write
> an Octave -> Julia translator, but I think it will NEVER be done for
> ideological (fanatic support of false/fake GPL freedom) reasons.

The complete Julia package is GPL'ed because Julia uses popular GPL
libraries such as FFTW, Suitesparse, and readline. We're on good terms
with the Julia developers and they do not have a problem with the GPL.

The reason the Octave -> Julia translator hasn't happened is because
it's not a problem that's significantly different than compiling
Octave into any other language that has a type declarations.

- Jordi G. H.