Discussion:
[Maxima-discuss] Announcing version 5.40.0
Viktor T. Toth
2017-05-30 17:46:19 UTC
Permalink
Dear Maxima users:

I just finished uploading RPMs for Maxima 5.40.0 to the package repository. Sources are also uploaded.

On my system, this version passed all tests with six different LISP systems, with the exception of two obscure date format related issues in CMUCL, which are known.

Please don't hesitate to let me know if there are any issues with the RPMs, especially as I had to go through some hoops to address complaints by rpmbuild about recently added folders.


Viktor
Raymond Toy
2017-05-30 19:20:36 UTC
Permalink
Viktor> Dear Maxima users:

Viktor> I just finished uploading RPMs for Maxima 5.40.0 to the
Viktor> package repository. Sources are also uploaded.

Viktor> On my system, this version passed all tests with six
Viktor> different LISP systems, with the exception of two obscure
Viktor> date format related issues in CMUCL, which are known.

Awesome! While I don't use the rpms or anything, it's great to see a
new release being made.

--
Ray
Wolfgang Dautermann
2017-05-30 22:38:03 UTC
Permalink
Post by Viktor T. Toth
I just finished uploading RPMs for Maxima 5.40.0 to the package
repository. Sources are also uploaded.
Great, thanks for your work, Viktor.
My crosscompiled Windows installers will be published probably tomorrow
(I don't know how busy I will be tomorrow, maybe on the 1st of june).
Post by Viktor T. Toth
On my system, this version passed all tests with six different LISP
systems, with the exception of two obscure date format related issues
in CMUCL, which are known.
I am just curious: Which LISPs did you test? (on which OS? Linux?)

My nightly tests (8 different LISPs on Linux (Ubuntu 16.04.2 LTS)) shows
no unexpected errors with: clisp, sbcl, gcl, cmucl, ccl64
It shows errors with: ecl, acl, abcl
https://wolfgang.dautermann.at/maxima/nightlybuild/logfile-summary.txt
(https://wolfgang.dautermann.at/maxima/nightlybuild/ for the detailed
results)

Best regards, Wolfgang
Viktor T. Toth
2017-05-31 03:07:07 UTC
Permalink
Post by Wolfgang Dautermann
I am just curious: Which LISPs did you test? (on which OS? Linux?)
SBCL, GCL, CMUCL, ECL, CCL (32-bit; ccl64 gives several errors here) and CLISP, on 64-bit CentOS 7.3.

The only two errors I got were two CMUCL (20b) date-formatting errors of pathological (1899, 1900) dates in the testsuite.


Viktor
Raymond Toy
2017-05-31 14:45:01 UTC
Permalink
Viktor> The only two errors I got were two CMUCL (20b)
Viktor> date-formatting errors of pathological (1899, 1900) dates
Viktor> in the testsuite.

CMUCL 20b? or 21b? 20b was released in 2010; 21b in 2016.

I would be surprised if 20b would pass all the tests except for those
two. 21b won't fix the date issues (but the latest snapshot will).

--
Ray
Viktor T. Toth
2017-05-31 15:40:19 UTC
Permalink
Nope, 20b. I guess I installed it last year just before 21b came out. (Or maybe there wasn't -- yet? -- a CentOS 7 compatible RPM, and I just couldn't be bothered installing from source.)

But it does pass all tests other than those two.

$ maxima --lisp cmucl
Maxima branch_5_40_base_3_g912247d http://maxima.sourceforge.net
using Lisp CMU Common Lisp 20b Fedora release 1.fc15 (20B Unicode)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite();
[...]
Running tests in rtest11:
[...]
227/229 tests passed

The following 2 problems failed: (144 160)
[...]
Error summary:
Errors found in /usr/local/share/maxima/branch_5_40_base_3_g912247d/tests/rtest11.mac, problems:
(144 160)
2 tests failed out of 11,185 total tests.


Viktor
-----Original Message-----
Sent: Wednesday, May 31, 2017 10:45 AM
Subject: Re: [Maxima-discuss] Announcing version 5.40.0
Viktor> The only two errors I got were two CMUCL (20b)
Viktor> date-formatting errors of pathological (1899, 1900) dates
Viktor> in the testsuite.
CMUCL 20b? or 21b? 20b was released in 2010; 21b in 2016.
I would be surprised if 20b would pass all the tests except for those
two. 21b won't fix the date issues (but the latest snapshot will).
--
Ray
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Raymond Toy
2017-05-31 20:46:35 UTC
Permalink
Viktor> Nope, 20b. I guess I installed it last year just before 21b came out. (Or maybe there wasn't -- yet? -- a CentOS 7 compatible RPM, and I just couldn't be bothered installing from source.)

Cmucl has funny numbering: 20b, 20c, 20d, 20e, 20f, 21a, 21b. You're
way behind. But no matter; for maxima, it seems that works just fine.

I don't expect you to install from source either. (Although, you could
just grab the prebuild binaries, but I don't expect you to do that
either unless you really, really want to.)

Viktor> But it does pass all tests other than those two.

Nice that it does. I am still surprised, though.

Thanks for the info,

--
Ray
Robert Dodier
2017-06-01 04:12:09 UTC
Permalink
Post by Viktor T. Toth
$ maxima --lisp cmucl
Maxima branch_5_40_base_3_g912247d http://maxima.sourceforge.net
using Lisp CMU Common Lisp 20b Fedora release 1.fc15 (20B Unicode)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite();
[...]
[...]
227/229 tests passed
The following 2 problems failed: (144 160)
I don't understand why these are reported -- rtest11 tests 144 and 160
are marked as expected failures for CMUCL in tests/testsuite.lisp.

Is it possible that #+(or gcl cmucl ccl64) doesn't have the expected
effect? What does :lisp *features* output? Does *features* contain CMU
and not CMUCL, something like that?

Incidentally I see I'm working with CMUCL 20d, which seems to date to
2012. It has both CMU and CMUCL in *features*.

best

Robert Dodier
Raymond Toy
2017-06-01 14:29:40 UTC
Permalink
Post by Viktor T. Toth
$ maxima --lisp cmucl
Maxima branch_5_40_base_3_g912247d http://maxima.sourceforge.net
using Lisp CMU Common Lisp 20b Fedora release 1.fc15 (20B Unicode)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite();
[...]
[...]
227/229 tests passed
The following 2 problems failed: (144 160)
Robert> I don't understand why these are reported -- rtest11 tests 144 and 160
Robert> are marked as expected failures for CMUCL in tests/testsuite.lisp.

Robert> Is it possible that #+(or gcl cmucl ccl64) doesn't have the expected
Robert> effect? What does :lisp *features* output? Does *features* contain CMU

Ah, that's exactly it. The feature should be :cmu, not :cmucl. (The
latter was added a little while ago.)

--
Ray
Robert Dodier
2017-06-02 05:44:59 UTC
Permalink
Post by Raymond Toy
Ah, that's exactly it. The feature should be :cmu, not :cmucl. (The
latter was added a little while ago.)
OK, maybe someone will look for any #+ / #- conditional code and put in
cmu wherever cmucl is found ....

best

Robert Dodier
Viktor T. Toth
2017-06-06 02:53:06 UTC
Permalink
Robert,

Forgive the late reply.

Yes, my CMUCL reports this:

* *features*

(:GERDS-PCL :PCL-STRUCTURES :PORTABLE-COMMONLOOPS :PCL :CMU20 :CMU20B :PYTHON
:CONSERVATIVE-FLOAT-TYPE :MODULAR-ARITH :MP :X86 :SSE2 :LINKAGE-TABLE
:RELATIVE-PACKAGE-NAMES :EXECUTABLE :ELF :LINUX :GLIBC2 :UNIX :RANDOM-MT19937
:GENCGC :UNICODE :COMPLEX-FP-VOPS :PENTIUM :I486 :HASH-NEW :DOUBLE-DOUBLE
:HEAP-OVERFLOW-CHECK :STACK-CHECKING :COMMON :COMMON-LISP :ANSI-CL
:IEEE-FLOATING-POINT :CMU)

So it has CMU, CMU20 and CMU20B, but not CMUCL.
-----Original Message-----
Sent: Thursday, June 1, 2017 12:12 AM
Subject: Re: [Maxima-discuss] Announcing version 5.40.0
Post by Viktor T. Toth
$ maxima --lisp cmucl
Maxima branch_5_40_base_3_g912247d http://maxima.sourceforge.net
using Lisp CMU Common Lisp 20b Fedora release 1.fc15 (20B Unicode)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite();
[...]
[...]
227/229 tests passed
The following 2 problems failed: (144 160)
I don't understand why these are reported -- rtest11 tests 144 and 160
are marked as expected failures for CMUCL in tests/testsuite.lisp.
Is it possible that #+(or gcl cmucl ccl64) doesn't have the expected
effect? What does :lisp *features* output? Does *features* contain CMU
and not CMUCL, something like that?
Incidentally I see I'm working with CMUCL 20d, which seems to date to
2012. It has both CMU and CMUCL in *features*.
best
Robert Dodier
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Wolfgang Dautermann
2017-05-31 23:00:43 UTC
Permalink
Post by Wolfgang Dautermann
Post by Viktor T. Toth
I just finished uploading RPMs for Maxima 5.40.0 to the package
repository. Sources are also uploaded.
Great, thanks for your work, Viktor.
My crosscompiled Windows installers will be published probably tomorrow
(I don't know how busy I will be tomorrow, maybe on the 1st of june).
There is one testsuite failure in Windows/Clisp on Windows in the new
decode_time/encode_time function:

(decode_time(encode_time(2024, 7, 5, 8, 7, 0)) = [2024, 7, 5, 9, 7, 0, -
7]) #
[2024, 7, 5, 8, 7, 0]]

This differed from the expected result:
[]

And two with SBCL - some numerical issues:

Running tests in rtest16:
; in: PROGN (DEFPROP $F T TRANSLATED)
; (SETQ MAXIMA::$X 2)
;
; caught WARNING:
; undefined variable: $X
;
; compilation unit finished
; Undefined variable:
; $X
; caught 1 WARNING condition

********************** Problem 562 (line 2156) ***************
Input:
2
%pi (- %pi) %i log(2)
ev(closeto(li (1.0 - %i) - (---- - %i 0.915965594177219 +
-----------------),
2 16 4
4.5e-16),
numer)


Result:
9.930136612989092e-16

This differed from the expected result:
true

********************** Problem 592 (line 2275) ***************
Input:
closeto(li (10.0) - (11.2390407376113 - 3.679606571301997 %i),
5

9.930140000000001e-15)


Result:
1.06581410364015e-14

This differed from the expected result:
true

611/613 tests passed


And I found one issue with VTK and Xmaxima. But surprisingly Xmaxima
works again with Clisp - really strange.

If there are no objections, I will release the Windows installer with
these testsuite failures. I am going to test the 64 bit installer
tomorrow and will release both (32 and 64 bit) at the same time. Should
I also release ZIP-Files? (I removed the restriction, that the
installation directory is fixed now...)


Best regards, Wolfgang
Robert Dodier
2017-06-01 04:48:23 UTC
Permalink
Post by Wolfgang Dautermann
There is one testsuite failure in Windows/Clisp on Windows in the new
(decode_time(encode_time(2024, 7, 5, 8, 7, 0)) = [2024, 7, 5, 9, 7, 0, -
7]) #
[2024, 7, 5, 8, 7, 0]]
Hmm. The first 6 elements of the list returned by decode_time are
supposed to be the same as the 6 arguments of encode_time; I see the 4th
(i.e. hour) is different. What does

(decode-universal-time (encode-universal-time 0 7 8 5 7 2024))

in a Lisp session return? With Windows Clisp 2.49 (executed via Wine) I
get

0 ;
7 ;
8 ;
5 ;
7 ;
2024 ;
4 ;
T ;
8
Post by Wolfgang Dautermann
If there are no objections, I will release the Windows installer with
these testsuite failures.
OK by me. Thanks for your efforts, it's greatly appreciated.

best

Robert Dodier
Thomas D. Dean
2017-06-01 05:02:54 UTC
Permalink
Post by Robert Dodier
Post by Wolfgang Dautermann
There is one testsuite failure in Windows/Clisp on Windows in the new
(decode_time(encode_time(2024, 7, 5, 8, 7, 0)) = [2024, 7, 5, 9, 7, 0, -
7]) #
[2024, 7, 5, 8, 7, 0]]
Hmm. The first 6 elements of the list returned by decode_time are
supposed to be the same as the 6 arguments of encode_time; I see the 4th
(i.e. hour) is different. What does
(decode-universal-time (encode-universal-time 0 7 8 5 7 2024))
in a Lisp session return? With Windows Clisp 2.49 (executed via Wine) I
GCL (GNU Common Lisp) 2.6.12 ANSI Jul 26 2015 18:48:00
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Robert Dodier
(decode-universal-time (encode-universal-time 0 7 8 5 7 2024))
0
7
8
5
7
2024
4
T
7
Wolfgang Dautermann
2017-06-01 07:08:50 UTC
Permalink
Post by Robert Dodier
Hmm. The first 6 elements of the list returned by decode_time are
supposed to be the same as the 6 arguments of encode_time; I see the 4th
(i.e. hour) is different. What does
(decode-universal-time (encode-universal-time 0 7 8 5 7 2024))
in a Lisp session return?
Using Windows 10 I get the right result in Lisp (decode-universal-time
/encode-universal-time) but the wrong result in Maxima
(decode_time/encode_time):

C:\maxima-5.40.0\bin>maxima -l clisp
Maxima 5.40.0 http://maxima.sourceforge.net
using Lisp CLISP 2.49 (2010-07-07)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) :lisp (decode-universal-time (encode-universal-time 0 7 8 5 7 2024))
0
7
8
5
7
2024
4
T
8
(%i1) decode_time(encode_time(2024, 7, 5, 8, 7, 0));
(%o1) [2024, 7, 5, 9, 7, 0, - 7]


Clisp with Wine does the same. Maybe again a timezone issue? We had
something similiar with the parse_timedate() function. Strange.

Best regards, Wolfgang
Robert Dodier
2017-06-02 05:42:15 UTC
Permalink
Post by Wolfgang Dautermann
Using Windows 10 I get the right result in Lisp (decode-universal-time
/encode-universal-time) but the wrong result in Maxima
Clisp with Wine does the same. Maybe again a timezone issue? We had
something similiar with the parse_timedate() function. Strange.
After trying encode_time/decode_time in Clisp for Windows (via Wine), I
believe the immediate cause is that the definition of
ENCODE-TIME-WITH-ALL-PARTS (src/commac.lisp) which is used for
Clisp/Windows causes trouble; there is in it a workaround for another
bug in Clisp for Windows. I'm not quite sure what's going on, who's
right and who's wrong; I'll take another look. Of course anyone else is
welcome to look at it too.

best

Robert Dodier
Robert Dodier
2017-06-18 22:38:38 UTC
Permalink
Post by Wolfgang Dautermann
C:\maxima-5.40.0\bin>maxima -l clisp
Maxima 5.40.0 http://maxima.sourceforge.net
using Lisp CLISP 2.49 (2010-07-07)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) :lisp (decode-universal-time (encode-universal-time 0 7 8 5 7 2024))
0
7
8
5
7
2024
4
T
8
(%i1) decode_time(encode_time(2024, 7, 5, 8, 7, 0));
(%o1) [2024, 7, 5, 9, 7, 0, - 7]
Clisp with Wine does the same. Maybe again a timezone issue? We had
something similiar with the parse_timedate() function. Strange.
I believe I've fixed the problem, with commit 87267ab. Can you please
try it and see if it works for you. I tested with different time zones
(UTC-7 and UTC+9) and Clisp + Windows (via Wine) and other Lisps on
Linux and it works OK in those cases.

best,

Robert Dodier
Wolfgang Dautermann
2017-06-21 22:00:12 UTC
Permalink
Post by Robert Dodier
Post by Wolfgang Dautermann
(%i1) decode_time(encode_time(2024, 7, 5, 8, 7, 0));
(%o1) [2024, 7, 5, 9, 7, 0, - 7]
Clisp with Wine does the same. Maybe again a timezone issue? We had
something similiar with the parse_timedate() function. Strange.
I believe I've fixed the problem, with commit 87267ab. Can you please
try it and see if it works for you. I tested with different time zones
(UTC-7 and UTC+9) and Clisp + Windows (via Wine) and other Lisps on
Linux and it works OK in those cases.
Hi Robert,
sorry for the delay and thanks for the fix - it works now, no testsuite
failures (in Linux/Wine and Win10). I do not get the same values as the
input, but the issue (the '9' above) was solved, so I assume, thats okay.

Win10:

(%i6) decode_time(encode_time(2024, 7, 5, 8, 7, 0));
(%o6) [2024, 7, 5, 8, 7, 0, - 7]

Wine/Linux:
C:\maxima-5.40post\bin>maxima
--run-string="decode_time(encode_time(2024, 7, 5, 8, 7, 0));"

Maxima branch_5_40_base_76_ge1dfe03_dirty http://maxima.sourceforge.net
using Lisp CLISP 2.49 (2010-07-07)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) (%o1) [2024, 7, 5, 8, 7, 0, 2]

The testsuite reports no errors in both setups.

Best regards, Wolfgang
Robert Dodier
2017-06-22 06:10:46 UTC
Permalink
Post by Wolfgang Dautermann
sorry for the delay and thanks for the fix - it works now, no testsuite
failures (in Linux/Wine and Win10). I do not get the same values as the
input, but the issue (the '9' above) was solved, so I assume, thats okay.
In this test, the first 6 values are supposed to be the same. The last
one (local time zone offset) can be different.
Post by Wolfgang Dautermann
(%i6) decode_time(encode_time(2024, 7, 5, 8, 7, 0));
(%o6) [2024, 7, 5, 8, 7, 0, - 7]
C:\maxima-5.40post\bin>maxima
--run-string="decode_time(encode_time(2024, 7, 5, 8, 7, 0));"
Maxima branch_5_40_base_76_ge1dfe03_dirty http://maxima.sourceforge.net
using Lisp CLISP 2.49 (2010-07-07)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) (%o1) [2024, 7, 5, 8, 7, 0, 2]
The results are correct given that the first 6 values of the output
match the input in both cases. But do I understand correctly that your
Win10 system has its local time set to UTC-7 while the Linux system is
UTC+2 ? But if that's the way the systems are configured, then
that's OK.

best,

Robert Dodier
Wolfgang Dautermann
2017-06-22 06:29:56 UTC
Permalink
Post by Robert Dodier
In this test, the first 6 values are supposed to be the same. The last
one (local time zone offset) can be different.
Ok.
Post by Robert Dodier
The results are correct given that the first 6 values of the output
match the input in both cases. But do I understand correctly that your
Win10 system has its local time set to UTC-7 while the Linux system is
UTC+2 ? But if that's the way the systems are configured, then
that's OK.
The Windows 10 system I used here isn't really 'configured' at all, I
just didn't care, which timezone is set there. It is a virtual machine,
one can download for free for testing purposes. So that may be the case,
yes.

Best regards, Wolfgang
Wolfgang Dautermann
2017-06-01 20:12:12 UTC
Permalink
Post by Wolfgang Dautermann
Great, thanks for your work, Viktor.
My crosscompiled Windows installers will be published probably
tomorrow (I don't know how busy I will be tomorrow, maybe on the 1st
of june).
Dear Maxima-team and Maxima-users,

I uploaded the (crosscompiled) Windows installers now (32 and 64 bit (a
32 bit CLISP is used in both installers, but memory management in CLISP
is better than in SBCL. [I hope, they produce a new release before the
next Maxima release (there is some activity (and a GSOC project) now)])).

Xmaxima / Clisp (which did not work in the last release) works now.
Don't know why (and why that combination did not work), there was not
much code change in Xmaxima since 5.39.0.

I removed the restriction, that the installation directory is fixed (but
it is still recommended, to use the default directory).

Maxima is compiled with CLISP and SBCL, there is a small program (in the
startmenu) which a user can use to select 'the default' Lisp. wxMaxima,
Xmaxima, command line Maxima, Gnuplot and VTK as graphics engine should
work properly.

Sorry for the delay.

Best regards, Wolfgang
Gunter Königsmann
2017-06-02 03:54:05 UTC
Permalink
Thanks a lot!


Could anybody with a debian-based system test if
https://www.physikbuch.de/maxima/maxima_5.40.0-1_amd64.deb runs on a
different computer than mine?

If it does I will upload it to maxima.sourceforge.net. Also if any of us
finds a way to get write access to http://launchpad.net/maxima in order
to tell launchpad to import the maxima code from git every day I am
confident I could set up a nightly debian build that
- runs the testbench on various versions of sbcl and clisp
- uploads the resulting debian packages to a ppa archive
- and sends mails if that fails.


Kind regards,

Gunter.
Post by Wolfgang Dautermann
Post by Wolfgang Dautermann
Great, thanks for your work, Viktor.
My crosscompiled Windows installers will be published probably
tomorrow (I don't know how busy I will be tomorrow, maybe on the 1st
of june).
Dear Maxima-team and Maxima-users,
I uploaded the (crosscompiled) Windows installers now (32 and 64 bit (a
32 bit CLISP is used in both installers, but memory management in CLISP
is better than in SBCL. [I hope, they produce a new release before the
next Maxima release (there is some activity (and a GSOC project) now)])).
Xmaxima / Clisp (which did not work in the last release) works now.
Don't know why (and why that combination did not work), there was not
much code change in Xmaxima since 5.39.0.
I removed the restriction, that the installation directory is fixed (but
it is still recommended, to use the default directory).
Maxima is compiled with CLISP and SBCL, there is a small program (in the
startmenu) which a user can use to select 'the default' Lisp. wxMaxima,
Xmaxima, command line Maxima, Gnuplot and VTK as graphics engine should
work properly.
Sorry for the delay.
Best regards, Wolfgang
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Gunter Königsmann
2017-06-02 19:11:48 UTC
Permalink
Ok... .things ..uploaded the newest version.
And since this is about technical things I have taken the liberty to
"cc" the maxima-discuss mailing list.

About building the package:

What you have to do is
- install sbcl, clisp, debhelper, fakeroot, sbcl, clisp , texinfo,
libreadline-dev, locales, automake and debhelper, build-essential
- unzip the tarball of the newest release
- copy the contents of the branch DebianPackaging of the maxima git
repository into the folder the source of the release lies in
- cd into this folder
- type the following command:
debuild

The rest should work automagically.
I hope, though, that the package won't be specific to the system it was
compiled on, though.

Kind regards,

Gunter.
How about this,
Let me have the source and I can compile, test, and then try to package it?
Just give me a good instructions (or a script).
Ray
Thanks for testing!
Seems like I have failed making the .deb package automatically uninstall
all old .deb packages that might conflict with it. Manually uninstalling
the offending packages should resolve the problem. Will try to resolve
the problem and to re-upload the package.
Kind regards,
Gunter.
Raymond
2017-06-02 20:38:40 UTC
Permalink
I'm sorry but where is the maxima source?
Ray
Post by Gunter Königsmann
Ok... .things ..uploaded the newest version.
And since this is about technical things I have taken the liberty to
"cc" the maxima-discuss mailing list.
What you have to do is
- install sbcl, clisp, debhelper, fakeroot, sbcl, clisp , texinfo,
libreadline-dev, locales, automake and debhelper, build-essential
- unzip the tarball of the newest release
- copy the contents of the branch DebianPackaging of the maxima git
repository into the folder the source of the release lies in
- cd into this folder
debuild
The rest should work automagically.
I hope, though, that the package won't be specific to the system it was
compiled on, though.
Kind regards,
Gunter.
How about this,
Let me have the source and I can compile, test, and then try to package it?
Just give me a good instructions (or a script).
Ray
Thanks for testing!
Seems like I have failed making the .deb package automatically uninstall
all old .deb packages that might conflict with it. Manually uninstalling
the offending packages should resolve the problem. Will try to resolve
the problem and to re-upload the package.
Kind regards,
Gunter.
Viktor T. Toth
2017-06-06 02:58:35 UTC
Permalink
Here:

https://sourceforge.net/projects/maxima/files/Maxima-source/


Viktor
-----Original Message-----
Sent: Friday, June 2, 2017 4:39 PM
Subject: Re: [Maxima-discuss] Announcing version 5.40.0
I'm sorry but where is the maxima source?
Ray
Ok... .things ..uploaded the newest version.
And since this is about technical things I have taken the liberty to
"cc" the maxima-discuss mailing list.
What you have to do is
- install sbcl, clisp, debhelper, fakeroot, sbcl, clisp , texinfo,
libreadline-dev, locales, automake and debhelper, build-essential
- unzip the tarball of the newest release
- copy the contents of the branch DebianPackaging of the maxima git
repository into the folder the source of the release lies in
- cd into this folder
debuild
The rest should work automagically.
I hope, though, that the package won't be specific to the system it was
compiled on, though.
Kind regards,
Gunter.
How about this,
Let me have the source and I can compile, test, and then try to package it?
Just give me a good instructions (or a script).
Ray
Thanks for testing!
Seems like I have failed making the .deb package automatically uninstall
all old .deb packages that might conflict with it. Manually uninstalling
the offending packages should resolve the problem. Will try to resolve
the problem and to re-upload the package.
Kind regards,
Gunter.
Robert Dodier
2017-06-03 06:03:06 UTC
Permalink
Post by Gunter Königsmann
What you have to do is
- install sbcl, clisp, debhelper, fakeroot, sbcl, clisp , texinfo,
libreadline-dev, locales, automake and debhelper, build-essential
- unzip the tarball of the newest release
- copy the contents of the branch DebianPackaging of the maxima git
repository into the folder the source of the release lies in
- cd into this folder
debuild
There is already some documentation about building rpms in README.rpms.
Maybe you can collect your notes about building .debs in a similar way.
I think it's safe to say that .deb packages are more widely used these
days.

best

Robert Dodier
Gunter Königsmann
2017-06-03 14:28:28 UTC
Permalink
Post by Robert Dodier
There is already some documentation about building rpms in README.rpms.
Maybe you can collect your notes about building .debs in a similar way.
I think it's safe to say that .deb packages are more widely used these
days.
I *think* I have set up a working nightly build at
https://code.launchpad.net/~peterpall/+archive/ubuntu/maxima-nightly/

What I cannot proof, unfortunately, is if that build will work on PCs
other than mine.


As the builder runs with 2 lisps and runs the testbench in theory we
could now make one of our sf.net mailing lists a subscriber for failure
messages from this build. But I personally would object this telling
anybody who is interested to subscribe individually: The build daemon
creates 6 builds for at least 2 platforms => every testbench failure
will at least cause 12 mails.

Kind regards,

Gunter.
Robert Dodier
2017-06-03 18:43:33 UTC
Permalink
Post by Gunter Königsmann
As the builder runs with 2 lisps and runs the testbench in theory we
could now make one of our sf.net mailing lists a subscriber for failure
messages from this build. But I personally would object this telling
anybody who is interested to subscribe individually: The build daemon
creates 6 builds for at least 2 platforms => every testbench failure
will at least cause 12 mails.
I agree that automatically generated emails should not be broadcast to
the discussion list.

best

Robert Dodier
Wolfgang Dautermann
2017-06-02 20:01:50 UTC
Permalink
Post by Gunter Königsmann
If it does I will upload it to maxima.sourceforge.net. Also if any of
us finds a way to get write access to http://launchpad.net/maxima in
order to tell launchpad to import the maxima code from git every day
I am confident I could set up a nightly debian build that
- runs the testbench on various versions of sbcl and clisp
I am running a test every day using 8(!) different Lisp's (usually the
most recent version):
https://wolfgang.dautermann.at/maxima/nightlybuild/

Would it make sense to build against different versions of the same Lisp
version? Shouldn't be a large problem, but I do not see much sense - we
want to see, if maybe a incompatible change of an recent Lisp version
does affect Maxima.
Keep the current bleeding edge Maxima compatible with SBCL 1.1.0 or
CLISP 2.47 (or TCL 8.3 or Gnuplot 3) and work around bugs in these old
versions - who cares? If one wants to install the bleeding edge Maxima,
it should be possible to install a recent Lisp too...
Post by Gunter Königsmann
- uploads the resulting debian packages to a ppa archive
Well, I could also build a debian package every day. Should be easier
than building a whole Windows installer...

Best regards, Wolfgang
Raymond Toy
2017-06-02 21:31:59 UTC
Permalink
Post by Wolfgang Dautermann
Post by Gunter Königsmann
If it does I will upload it to maxima.sourceforge.net. Also if any of
us finds a way to get write access to http://launchpad.net/maxima in
order to tell launchpad to import the maxima code from git every day
I am confident I could set up a nightly debian build that
- runs the testbench on various versions of sbcl and clisp
I am running a test every day using 8(!) different Lisp's (usually the
https://wolfgang.dautermann.at/maxima/nightlybuild/
​Do you keep an archive of each nightly result? That would be pretty
useful for a couple of reasons: We can find out when something stopped
working (because people, including me, aren't good about testing each
change everywhere). If the machine this runs on is fixed, we can get some
information on performance regressions.
​
Post by Wolfgang Dautermann
Would it make sense to build against different versions of the same Lisp
version? Shouldn't be a large problem, but I do not see much sense - we
​I'm happy with running just against the current version. I personally
would update the lisp version only fairly slowly. Fortunately, most lisps
don't update versions that quickly.

​
--
Ray
Raymond
2017-06-03 14:17:39 UTC
Permalink
I have a 5.40 .deb build for LInux Mint 17.3 (Rosa) using
checkinstall
maxima, xmaxima, wxmaxima seem to be picking up the correct version
And the system package manger has 5.40 registered for maxima.
---------
The developer how-to has things like "merging" and "master" with git.
Since I have doubts about the usefulness of my .deb package I certainly
don't want it "official" without testing. Is there a proper place and
method to put it for testing by others?
Ray
On Fri, Jun 2, 2017 at 1:01 PM, Wolfgang Dautermann
Post by Gunter Königsmann
If it does I will upload it to maxima.sourceforge.net
<http://maxima.sourceforge.net>. Also if any of
Post by Gunter Königsmann
us finds a way to get write access to http://launchpad.net/maxima in
order to tell launchpad to import the maxima code from git every day
I am confident I could set up a nightly debian build that
- runs the testbench on various versions of sbcl and clisp
I am running a test every day using 8(!) different Lisp's (usually the
https://wolfgang.dautermann.at/maxima/nightlybuild/
<https://wolfgang.dautermann.at/maxima/nightlybuild/>
​Do you keep an archive of each nightly result? That would be pretty
useful for a couple of reasons: We can find out when something stopped
working (because people, including me, aren't good about testing each
change everywhere). If the machine this runs on is fixed, we can get
some information on performance regressions.
​
Would it make sense to build against different versions of the same Lisp
version? Shouldn't be a large problem, but I do not see much sense - we
​I'm happy with running just against the current version. I personally
would update the lisp version only fairly slowly. Fortunately, most
lisps don't update versions that quickly.
​
--
Ray
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Gunter Königsmann
2017-06-03 14:57:54 UTC
Permalink
Post by Raymond
I have a 5.40 .deb build for LInux Mint 17.3 (Rosa) using
checkinstall
maxima, xmaxima, wxmaxima seem to be picking up the correct version
And the system package manger has 5.40 registered for maxima.
---------
The developer how-to has things like "merging" and "master" with git.
Since I have doubts about the usefulness of my .deb package I certainly
don't want it "official" without testing. Is there a proper place and
method to put it for testing by others?
Ray
Not really.

The default checkinstall method for compiling the package has one
disadvantage: If one already has installed maxima maxima has brought in
the package maxima-doc.
By default the checkinstall package contains the documentation but
doesn't tell that it
- replaces maxima-doc (which means it is OK that it provides files
already present in a package)
- breaks maxima-doc (which means if your maxima package is installed
maxima-doc should automatically be uninstalled)
- provides maxima-doc (which means that other packages depending on
maxima-doc will work fine in conjunction with the checkinstall package.

The same is true with xmaxima and maxima-share. Don't know if there is a
workaround that causes checkinstall to include this piece of information
in the package.

Which lisp did you compile your package with? I only did sbcl and clisp
as trying to compile maxima with gcl for some reason did result in an error.

Kind regards,

Gunter.
Raymond
2017-06-03 15:21:50 UTC
Permalink
Post by Gunter Königsmann
Post by Raymond
I have a 5.40 .deb build for LInux Mint 17.3 (Rosa) using
checkinstall
maxima, xmaxima, wxmaxima seem to be picking up the correct version
And the system package manger has 5.40 registered for maxima.
---------
The developer how-to has things like "merging" and "master" with git.
Since I have doubts about the usefulness of my .deb package I certainly
don't want it "official" without testing. Is there a proper place and
method to put it for testing by others?
Ray
Not really.
The default checkinstall method for compiling the package has one
disadvantage: If one already has installed maxima maxima has brought in
the package maxima-doc.
By default the checkinstall package contains the documentation but
doesn't tell that it
- replaces maxima-doc (which means it is OK that it provides files
already present in a package)
- breaks maxima-doc (which means if your maxima package is installed
maxima-doc should automatically be uninstalled)
- provides maxima-doc (which means that other packages depending on
maxima-doc will work fine in conjunction with the checkinstall package.
The same is true with xmaxima and maxima-share. Don't know if there is a
workaround that causes checkinstall to include this piece of information
in the package.
Which lisp did you compile your package with? I only did sbcl and clisp
as trying to compile maxima with gcl for some reason did result in an error.
Kind regards,
Gunter.
I had removed maxima, xmaxima, wxmaxima before "checkinstall".
A little confusing:
the installer "apt-get" declares maxima-doc 5.32.1
whereas the
xmaxima ->help->maxima manual (xmaxima browser)
picks up the correct
file://usr/local/share/maxima/5.40.0/doc/html/maxima_1.html
as does
xmaxima ->help->maxima manual (web browser)
xmaxima ->help->xmaxima manual (web browser)
Unfortunatly
xmaxima ->help->xmaxima manual (xmaxima browser)
Fails with "bad path name ".browser
but I presume that that means a file .browser is incorrectly set?
I have forgotten whether I removed maxima-doc from apt-get beforehand.
Shall I remove maxima/xmaxima/maxima-doc
and try again?
----
with
maxima
I now get: "using Lisp CLISP 2.49 (2010-07-07)"
Do you want me to remove it and try another?
Ray
Robert Dodier
2017-06-03 06:00:08 UTC
Permalink
Post by Wolfgang Dautermann
Would it make sense to build against different versions of the same Lisp
version?
I dunno, there are so many bazillions of combinations ... at some point
we have to say it's enough. In this case I think the most recent stable
release of each Lisp is enough.

best

Robert Dodier
Gunter Königsmann
2017-06-03 11:33:18 UTC
Permalink
I just thought we'd take it if we could get it for free.

In the meantime Mario has helped me get the ownership on
https://launchpad.net/maxima. The ubuntu team told me I should build a
team there. If anybody is interested just send me your launchpad ID and
I will try how to tell launchpad that a team is working on this page.

The next step will be setting up automatic nightly builds for all
supported ubuntu versions. Let's see if I manage to succeed in this point.

Kind regards,

Gunter.
Raymond
2017-06-03 14:32:06 UTC
Permalink
I can do a Linux mint 17.3 build (although I am not sure it is
universal) if that is useful.

Ray
Post by Gunter Königsmann
I just thought we'd take it if we could get it for free.
In the meantime Mario has helped me get the ownership on
https://launchpad.net/maxima. The ubuntu team told me I should build a
team there. If anybody is interested just send me your launchpad ID and
I will try how to tell launchpad that a team is working on this page.
The next step will be setting up automatic nightly builds for all
supported ubuntu versions. Let's see if I manage to succeed in this point.
Kind regards,
Gunter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Gunter Königsmann
2017-06-03 15:01:29 UTC
Permalink
Post by Raymond
I can do a Linux mint 17.3 build (although I am not sure it is
universal) if that is useful.
.deb builds are useful. That a maxima build is universal I hope. But I
cannot guarantee that, still: gcl builds of maxima did tend to be
specific to the gcl version they were made with.

Kind regards,

Gunter.
Raymond
2017-06-03 15:57:32 UTC
Permalink
Post by Gunter Königsmann
Post by Raymond
I can do a Linux mint 17.3 build (although I am not sure it is
universal) if that is useful.
.deb builds are useful. That a maxima build is universal I hope. But I
cannot guarantee that, still: gcl builds of maxima did tend to be
specific to the gcl version they were made with.
Kind regards,
Gunter.
Linux mint 17.3 synaptic seems to have a problem with gcl. It has
dependency of wxmaxima and maxima-doc ??? That doesn't seem logical.
apt-get install gcl
gives a bunch of errors. For instance "ERROR: gcl is broken"
Ray
Gunter Königsmann
2017-06-04 07:41:29 UTC
Permalink
Post by Raymond
Post by Gunter Königsmann
Gunter.
Linux mint 17.3 synaptic seems to have a problem with gcl. It has
dependency of wxmaxima and maxima-doc ??? That doesn't seem logical.
Found the reason:
- the wxMaxima .deb file tells it needs a version of maxima-doc that is
newer than something.
- the maxima .deb file tells it provides a maxima-doc. But as we both
didn't create a .deb file named "maxima-doc" there is no version number
that can be checked against => wxMaxima doesn't get what it wants.

Perhaps in the next days I will find out a way how to split the program
into several debian packages.

Unfortunately as the debian utilities compress the documentation in
order to save a (very) small percentage of disk memory and neither
maxima nor xmaxima know how to deal with that I don't think that I will
be able to create a fully working official .deb release, though.
Post by Raymond
apt-get install gcl
gives a bunch of errors. For instance "ERROR: gcl is broken"
On m computer I can install gcl, but it tends to go into endless loops
outputting error messages as soon as I try to make it compile maxima.
I can try to use ecl, though...

Kind regards,

Gunter.
Clinton Winant
2017-06-04 08:08:08 UTC
Permalink
While on the subject of debian packages, has anyone built a package for
ubuntu 16.04, thei latest LTS?
Post by Gunter Königsmann
Post by Raymond
Post by Gunter Königsmann
Gunter.
Linux mint 17.3 synaptic seems to have a problem with gcl. It has
dependency of wxmaxima and maxima-doc ??? That doesn't seem logical.
- the wxMaxima .deb file tells it needs a version of maxima-doc that is
newer than something.
- the maxima .deb file tells it provides a maxima-doc. But as we both
didn't create a .deb file named "maxima-doc" there is no version number
that can be checked against => wxMaxima doesn't get what it wants.
Perhaps in the next days I will find out a way how to split the program
into several debian packages.
Unfortunately as the debian utilities compress the documentation in
order to save a (very) small percentage of disk memory and neither
maxima nor xmaxima know how to deal with that I don't think that I will
be able to create a fully working official .deb release, though.
Post by Raymond
apt-get install gcl
gives a bunch of errors. For instance "ERROR: gcl is broken"
On m computer I can install gcl, but it tends to go into endless loops
outputting error messages as soon as I try to make it compile maxima.
I can try to use ecl, though...
Kind regards,
Gunter.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Gunter Königsmann
2017-06-05 08:08:32 UTC
Permalink
Post by Clinton Winant
While on the subject of debian packages, has anyone built a package for
ubuntu 16.04, thei latest LTS?
You can try

- https://www.peterpall.de/maxima/maxima_5.40.0-1_amd64.deb and
- https://www.peterpall.de/maxima/maxima-doc_5.40.0-1_all.deb

I think I have found a workaround for maxima requiring uncompressed
.info documents.

If they work please inform me so I will finally upload them on the
download page; Currently I cannot build maxima for 32-bit systems as
this would require more storage than my ssd allows me to use.

Kind regards,

Gunter.
Clinton Winant
2017-06-05 15:21:21 UTC
Permalink
Trying to install on ubuntu 16.04, with your first suggestion:

sudo dpkg -i maxima_5.40.0-1_amd64.deb
[sudo] password for abr_ca:
Selecting previously unselected package maxima.
(Reading database ... 266020 files and directories currently installed.)
Preparing to unpack maxima_5.40.0-1_amd64.deb ...
Unpacking maxima (5.40.0-1) ...
dpkg: dependency problems prevent configuration of maxima:
maxima depends on libffcall1 (>= 1.10+2.41); however:
Package libffcall1 is not installed.
maxima depends on libreadline5 (>= 5.2); however:
Package libreadline5 is not installed.
maxima depends on sbcl; however:
Package sbcl is not installed.
maxima depends on clisp; however:
Package clisp is not installed.
maxima depends on ecl; however:
Package ecl is not installed.

dpkg: error processing package maxima (--install):
dependency problems - leaving unconfigured
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20160824-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu5.1) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for shared-mime-info (1.5-2ubuntu0.1) ...
Errors were encountered while processing:
maxima

Did not try the doc package Cheers
Post by Gunter Königsmann
Post by Clinton Winant
While on the subject of debian packages, has anyone built a package for
ubuntu 16.04, thei latest LTS?
You can try
- https://www.peterpall.de/maxima/maxima_5.40.0-1_amd64.deb and
- https://www.peterpall.de/maxima/maxima-doc_5.40.0-1_all.deb
I think I have found a workaround for maxima requiring uncompressed
.info documents.
If they work please inform me so I will finally upload them on the
download page; Currently I cannot build maxima for 32-bit systems as
this would require more storage than my ssd allows me to use.
Kind regards,
Gunter.
Gunter Königsmann
2017-06-05 15:48:04 UTC
Permalink
Post by Clinton Winant
sudo dpkg -i maxima_5.40.0-1_amd64.deb
Selecting previously unselected package maxima.
(Reading database ... 266020 files and directories currently installed.)
Preparing to unpack maxima_5.40.0-1_amd64.deb ...
Unpacking maxima (5.40.0-1) ...
Package libffcall1 is not installed.
Package libreadline5 is not installed.
Package sbcl is not installed.
Package clisp is not installed.
Package ecl is not installed.
dependency problems - leaving unconfigured
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20160824-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu5.1) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for shared-mime-info (1.5-2ubuntu0.1) ...
maxima
This bundle of error messages is normal if dpkg -i is used: You have
instructed the program to install maxima. But maxima needs other
packages installed in order to be able to run.
On my system the command tells automaticaly tells that after trying to
install maxima a

sudo apt-get --fix-missing install

installs all the packages that are missing and resolves the problem.
Seems like your version doesn't do so ;-(

Kind regards,

Gunter.
Raymond
2017-06-05 15:21:48 UTC
Permalink
Post by Clinton Winant
While on the subject of debian packages, has anyone built a package
for ubuntu 16.04, thei latest LTS?
Post by Raymond
Post by Gunter Königsmann
Gunter.
Linux mint 17.3 synaptic seems to have a problem with gcl. It has
dependency of wxmaxima and maxima-doc ??? That doesn't seem
logical.
- the wxMaxima .deb file tells it needs a version of maxima-doc that is
newer than something.
- the maxima .deb file tells it provides a maxima-doc. But as we both
didn't create a .deb file named "maxima-doc" there is no version number
that can be checked against => wxMaxima doesn't get what it wants.
I just checked and wxmaxima is pulling up
help "Maxima 5.9.1"
against wxmaxima 13.04
But it does sense
Maxima 5.40.0

So as a cheat, a direct redirection or recompile the correct help file
could be pointed to. A recompile would even register it correctly into
apt,apt-get,synaptic
Post by Clinton Winant
Perhaps in the next days I will find out a way how to split the program
into several debian packages.
Unfortunately as the debian utilities compress the documentation in
order to save a (very) small percentage of disk memory and neither
maxima nor xmaxima know how to deal with that I don't think that I will
be able to create a fully working official .deb release, though.
This I don't understand. xmaxima does retrieve the correct help page.
So it is installed but not registered.
How about makeing "make xmaxima" would checkinstall pick up xmaxima then?
In addition what if "make" added/recursed to "make xmaxima" it's
already there. Then we would have both debs and a post install could
install it?

Just wondering.
Ray
Gunter Königsmann
2017-06-05 15:55:23 UTC
Permalink
Post by Raymond
This I don't understand. xmaxima does retrieve the correct help page.
So it is installed but not registered.
How about makeing "make xmaxima" would checkinstall pick up xmaxima then?
In addition what if "make" added/recursed to "make xmaxima" it's
already there. Then we would have both debs and a post install could
install it?
I don't even know if there is a way to register help files. wxMaxima and
xMaxima both automatically search for the installed version of maxima
...and it seems that wxMaxima doesn't take the optimum decision here
favouring help files from older versions against new ones.

Would you mind filing a bug at http://andrejv.github.com/wxmaxima/ so
the info that this needs fixing won't get lost?

Thanks a lot,
and kind regards,

Gunter.
Raymond
2017-06-05 19:05:17 UTC
Permalink
Post by Gunter Königsmann
Post by Raymond
This I don't understand. xmaxima does retrieve the correct help page.
So it is installed but not registered.
How about makeing "make xmaxima" would checkinstall pick up xmaxima then?
In addition what if "make" added/recursed to "make xmaxima" it's
already there. Then we would have both debs and a post install could
install it?
I don't even know if there is a way to register help files. wxMaxima and
xMaxima both automatically search for the installed version of maxima
...and it seems that wxMaxima doesn't take the optimum decision here
favouring help files from older versions against new ones.
Would you mind filing a bug at http://andrejv.github.com/wxmaxima/ so
the info that this needs fixing won't get lost?
Thanks a lot,
and kind regards,
Gunter.
Just to update:
Installing: maxima-doc_5.40.0-1_all.deb
Recompiling: maxima-5.40.0.tgz , wxmaxima-Version-17.05.0.tgz
Seems to have everything in sync including help files and registrations.
The recompiles were due to : libtinfo5 - requires >=6 from the web .deb's
I can place the recompiles and ldd's somewhere if wanted.

Ray
Robert Dodier
2017-06-05 05:26:39 UTC
Permalink
Post by Gunter Königsmann
Unfortunately as the debian utilities compress the documentation in
order to save a (very) small percentage of disk memory and neither
maxima nor xmaxima know how to deal with that I don't think that I will
be able to create a fully working official .deb release, though.
Maybe you can take a look at the commit messages on branch
read-compressed-info. I'd be interested to talk it over.
Post by Gunter Königsmann
On m computer I can install gcl, but it tends to go into endless loops
outputting error messages as soon as I try to make it compile maxima.
I can try to use ecl, though...
Hmm. Maybe you can try SBCL (faster, fewer bugs) or Clisp (slower, fewer
bugs). Just a thought.

best

Robert Dodier
Gunter Königsmann
2017-06-05 06:15:38 UTC
Permalink
Post by Robert Dodier
Post by Gunter Königsmann
On m computer I can install gcl, but it tends to go into endless loops
outputting error messages as soon as I try to make it compile maxima.
I can try to use ecl, though...
Hmm. Maybe you can try SBCL (faster, fewer bugs) or Clisp (slower, fewer
bugs). Just a thought.
SBCL and CLISP work fine. The ECL version Ubuntu currently ships with
doesn't compile the current maxima version.
But normally only lapack is broken in ecl => This would be an option, too.

Kind regards,

Gunter.
Robert Dodier
2017-06-03 18:46:13 UTC
Permalink
Post by Gunter Königsmann
In the meantime Mario has helped me get the ownership on
https://launchpad.net/maxima. The ubuntu team told me I should build a
team there. If anybody is interested just send me your launchpad ID and
I will try how to tell launchpad that a team is working on this page.
I think that's great. Unfortunately I can't contribute to that effort,
but I think it's a good idea and wish you the best of luck with it.

Robert Dodier
Gunter Königsmann
2017-06-03 15:14:40 UTC
Permalink
Gunter,
I had some problems with wxMaxima after installing from this deb file.
Synaptic showed wxmaxima as broken. I eventually re-installed the 5.40.0
package using my version of your instructions for installing
maxima/wxmaxima from the ground up.
Weird: I have told the package to inform the package manager that it
does provide maxima-doc... ...but on processing the wxMaxima it doesn't
seem to know that => Removing the .deb package again.

Kind regards,

Gunter.
Raymond
2017-06-03 15:30:58 UTC
Permalink
Post by Gunter Königsmann
Gunter,
I had some problems with wxMaxima after installing from this deb file.
Synaptic showed wxmaxima as broken. I eventually re-installed the 5.40.0
package using my version of your instructions for installing
maxima/wxmaxima from the ground up.
Weird: I have told the package to inform the package manager that it
does provide maxima-doc... ...but on processing the wxMaxima it doesn't
seem to know that => Removing the .deb package again.
Kind regards,
Gunter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Same here: the wxmaxima "about" has picked up Maxima 5.40
but the wxmaxima help declares 5.32 .
This was after a re-installation of wxmaxima.
So I guess I will remove everything and use the .deb file and see what
happens.
Ray
Raymond
2017-06-03 15:41:35 UTC
Permalink
Post by Gunter Königsmann
Gunter,
I had some problems with wxMaxima after installing from this deb file.
Synaptic showed wxmaxima as broken. I eventually re-installed the 5.40.0
package using my version of your instructions for installing
maxima/wxmaxima from the ground up.
Weird: I have told the package to inform the package manager that it
does provide maxima-doc... ...but on processing the wxMaxima it doesn't
seem to know that => Removing the .deb package again.
Kind regards,
Gunter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
I removed maxima, xmaxima, wxmaxima
Used the .deb file created by "checkinstall"
maxima got registered as 5.40 synaptic/apt-get
xmaxima did not get registered by is installed and the help is 5.40
maxima-doc did not get registered in aptitude
to reinstall wxmaxima 5.32 from aptitude requires maxima-doc 5.32
In my case only the registration with synaptic seems to be a problem.
Ray
Robert Dodier
2017-05-31 14:54:03 UTC
Permalink
Post by Viktor T. Toth
On my system, this version passed all tests with six different LISP
systems, with the exception of two obscure date format related issues
in CMUCL, which are known.
Hmm, what are the unexpected failures for CMUCL? I marked some expected
failures in commit 753095e (dated May 26).
Post by Viktor T. Toth
Please don't hesitate to let me know if there are any issues with the
RPMs, especially as I had to go through some hoops to address
complaints by rpmbuild about recently added folders.
If you've updated maxima.spec (or more precisely maxima.spec.in), I hope
you'll commit those updates.

I don't know if it's widely known, but: Debian-based systems such as
Ubuntu can install rpms via alien.

Thanks for your work on the release, I appreciate it very much.

best

Robert Dodier
Viktor T. Toth
2017-05-31 15:43:57 UTC
Permalink
Post by Robert Dodier
Hmm, what are the unexpected failures for CMUCL? I marked
some expected failures in commit 753095e (dated May 26).
Tests 144 and 160 in rtest11.mac. I'll paste the output below.
Post by Robert Dodier
If you've updated maxima.spec (or more precisely maxima.spec.in),
I hope you'll commit those updates.
Of course. Already did.


Viktor

--------------------
Running tests in rtest11:
********************** Problem 144 (line 487) ***************
Input:
map(parse_timedate, [1900-01-02 00:00:00+24:00, 1900-01-01 23:00:00+23:00,
1900-01-01 22:00:00+22:00, 1900-01-01 21:00:00+21:00,
1900-01-01 20:00:00+20:00, 1900-01-01 19:00:00+19:00,
1900-01-01 18:00:00+18:00, 1900-01-01 17:00:00+17:00,
1900-01-01 16:00:00+16:00, 1900-01-01 15:00:00+15:00,
1900-01-01 14:00:00+14:00, 1900-01-01 13:00:00+13:00,
1900-01-01 12:00:00+12:00, 1900-01-01 11:00:00+11:00,
1900-01-01 10:00:00+10:00, 1900-01-01 09:00:00+09:00,
1900-01-01 08:00:00+08:00, 1900-01-01 07:00:00+07:00,
1900-01-01 06:00:00+06:00, 1900-01-01 05:00:00+05:00,
1900-01-01 04:00:00+04:00, 1900-01-01 03:00:00+03:00,
1900-01-01 02:00:00+02:00, 1900-01-01 01:00:00+01:00,
1900-01-01 00:00:00+00:00, 1900-01-01Z, 1900-01-01 00:00:00-00:00,
1899-12-31 23:00:00-01:00, 1899-12-31 22:00:00-02:00,
1899-12-31 21:00:00-03:00, 1899-12-31 20:00:00-04:00,
1899-12-31 19:00:00-05:00, 1899-12-31 18:00:00-06:00,
1899-12-31 17:00:00-07:00, 1899-12-31 16:00:00-08:00,
1899-12-31 15:00:00-09:00, 1899-12-31 14:00:00-10:00,
1899-12-31 13:00:00-11:00, 1899-12-31 12:00:00-12:00,
1899-12-31 11:00:00-13:00, 1899-12-31 10:00:00-14:00,
1899-12-31 09:00:00-15:00, 1899-12-31 08:00:00-16:00,
1899-12-31 07:00:00-17:00, 1899-12-31 06:00:00-18:00,
1899-12-31 05:00:00-19:00, 1899-12-31 04:00:00-20:00,
1899-12-31 03:00:00-21:00, 1899-12-31 02:00:00-22:00,
1899-12-31 01:00:00-23:00, 1899-12-31 00:00:00-24:00])


Result:
error-catch

This differed from the expected result:
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

********************** Problem 160 (line 703) ***************
Input:
map(lambda([l], apply(encode_time, l)),
[[1900, 1, 2, 0, 0, 0, + 24], [1900, 1, 1, 23, 0, 0, + 23],
[1900, 1, 1, 22, 0, 0, + 22], [1900, 1, 1, 21, 0, 0, + 21],
[1900, 1, 1, 20, 0, 0, + 20], [1900, 1, 1, 19, 0, 0, + 19],
[1900, 1, 1, 18, 0, 0, + 18], [1900, 1, 1, 17, 0, 0, + 17],
[1900, 1, 1, 16, 0, 0, + 16], [1900, 1, 1, 15, 0, 0, + 15],
[1900, 1, 1, 14, 0, 0, + 14], [1900, 1, 1, 13, 0, 0, + 13],
[1900, 1, 1, 12, 0, 0, + 12], [1900, 1, 1, 11, 0, 0, + 11],
[1900, 1, 1, 10, 0, 0, + 10], [1900, 1, 1, 9, 0, 0, + 9],
[1900, 1, 1, 8, 0, 0, + 8], [1900, 1, 1, 7, 0, 0, + 7],
[1900, 1, 1, 6, 0, 0, + 6], [1900, 1, 1, 5, 0, 0, + 5],
[1900, 1, 1, 4, 0, 0, + 4], [1900, 1, 1, 3, 0, 0, + 3],
[1900, 1, 1, 2, 0, 0, + 2], [1900, 1, 1, 1, 0, 0, + 1],
[1900, 1, 1, 0, 0, 0, + 0], [1900, 1, 1, 0, 0, 0, - 0],
[1899, 12, 31, 23, 0, 0, - 1], [1899, 12, 31, 22, 0, 0, - 2],
[1899, 12, 31, 21, 0, 0, - 3], [1899, 12, 31, 20, 0, 0, - 4],
[1899, 12, 31, 19, 0, 0, - 5], [1899, 12, 31, 18, 0, 0, - 6],
[1899, 12, 31, 17, 0, 0, - 7], [1899, 12, 31, 16, 0, 0, - 8],
[1899, 12, 31, 15, 0, 0, - 9], [1899, 12, 31, 14, 0, 0, - 10],
[1899, 12, 31, 13, 0, 0, - 11], [1899, 12, 31, 12, 0, 0, - 12],
[1899, 12, 31, 11, 0, 0, - 13], [1899, 12, 31, 10, 0, 0, - 14],
[1899, 12, 31, 9, 0, 0, - 15], [1899, 12, 31, 8, 0, 0, - 16],
[1899, 12, 31, 7, 0, 0, - 17], [1899, 12, 31, 6, 0, 0, - 18],
[1899, 12, 31, 5, 0, 0, - 19], [1899, 12, 31, 4, 0, 0, - 20],
[1899, 12, 31, 3, 0, 0, - 21], [1899, 12, 31, 2, 0, 0, - 22],
[1899, 12, 31, 1, 0, 0, - 23], [1899, 12, 31, 0, 0, 0, - 24]])


Result:
error-catch

This differed from the expected result:
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

227/229 tests passed

The following 2 problems failed: (144 160)
Gunter Königsmann
2017-06-01 04:56:13 UTC
Permalink
Post by Robert Dodier
I don't know if it's widely known, but: Debian-based systems such as
Ubuntu can install rpms via alien.
I've looked into Camm's rules for making a .deb package for debian.

Seems like
http://http.debian.net/debian/pool/main/m/maxima/maxima_5.39.0-2.debian.tar.xz
contains loads of patches to our original sources. I wonder if we want
to upstream a few of them. One that looks interesting (debian insists on
.info files being compressed and I think its standalone info program
relies on that) is attached to this mail.

Another thing debuild isn't happy about is that a few of the .info or
other text files don't end in a newline character and that some .texi
files are marked as executable in the tarball.

Kind regards,

Gunter.
Gunter Königsmann
2017-06-01 06:10:40 UTC
Permalink
I wonder if we can create a minimalistic nightly linux build on
launchpad that sends anybody who is interested a mail if building the
package or the test bench fails. Currently my attempts fail with debuild
not believing that what we created is an executable but I can bet that
there will be a solution to that:

dpkg-genbuildinfo: error: binary build with no binary artifacts found;
.buildinfo is meaningless
dpkg-buildpackage: error: dpkg-genbuildinfo gave error exit status 2

Also I have no idea how to set up a nightly build for a package I am not
the maintainer of on launchpad. But I believe that to be possible.
One thing that we should fix is that the build process isn't idempotent:
after a make&&make distclean debuild claims it detects changes to files.
Which is no obstacle for the build demon. But it means that for every
attempt to try it at home I need a fresh build directory.

There is a thing I honestly don't understand - which is the reason I
have decided to ask the mailing list:
./tests/clisp-test.sh doesn't output anything on stdout or stderr: If
there is no output for >10 minutes while the CPU is busy the build demon
looses its patience - and we want the test results end up in the build
log, anyway.
What strikes me as odd is that
- clisp-tests.sh contains a tee command that should make all that ends
up in the log file is output on the console, as well and
- clisp-tests.sh appends data to the log file on a regular basis -
which, if the data would be output to the console, as well, would keep
the build demon happy.

What I didn't succeed in was making the gcl build work on my linux
computer. But as launchpad uses ubuntu's stock gcl as does my computer I
think that won't be possible, anyway: I can switch to an ansi gcl build.
But that build still doesn't contain Camm's recent changes that make
maxima build again.

Kind regards,

Gunter.
Robert Dodier
2017-06-03 07:05:11 UTC
Permalink
Post by Gunter Königsmann
http://http.debian.net/debian/pool/main/m/maxima/maxima_5.39.0-2.debian.tar.xz
contains loads of patches to our original sources. I wonder if we want
to upstream a few of them.
I looked at the patches and I agree that some of them could be merged
into Maxima. Any such commit should be identified as originating from a
specific patch in a specific Debian tarball, to make it easier to know
what changes have and have not been applied.
Post by Gunter Königsmann
One that looks interesting (debian insists on
.info files being compressed and I think its standalone info program
relies on that) is attached to this mail.
Well, I'm not sure what to think about that. Maxima needs to have
uncompressed .info at present and anyway the storage saved is miniscule
in current terms. I think debian should allow uncompressed info but oh
well.

I did some exploration of the idea of reading compressed info files, and
I think I did get it to work in some way (I think the mailing list
archive has the details). But it was more complicated than I expected. I
suppose if we must cope with compressed info, we can revisit that.
Post by Gunter Königsmann
Another thing debuild isn't happy about is that a few of the .info or
other text files don't end in a newline character and that some .texi
files are marked as executable in the tarball.
I guess it's harmless to fix up these things to avoid the warnings.

best

Robert Dodier
Gunter Königsmann
2017-06-04 07:33:19 UTC
Permalink
Post by Robert Dodier
Post by Gunter Königsmann
One that looks interesting (debian insists on
.info files being compressed and I think its standalone info program
relies on that) is attached to this mail.
Well, I'm not sure what to think about that. Maxima needs to have
uncompressed .info at present and anyway the storage saved is miniscule
in current terms. I think debian should allow uncompressed info but oh
well.
I assume that this rule was created in times when everyone was using a
100-Megabyte hard-disk and half a megabyte of .info files was huge. But
they started to enforce this rule only recently.
Post by Robert Dodier
I did some exploration of the idea of reading compressed info files, and
I think I did get it to work in some way (I think the mailing list
archive has the details). But it was more complicated than I expected. I
suppose if we must cope with compressed info, we can revisit that.
Seeing that the patch was quite small I assumed that it must contain
some magic we had overlooked.

Currently it is one of three things prevent me from publishing a working
debian package of the release: The debian packaging tools automatically
compress our .info files. Also xmaxima doesn't like the documentation to
be compressed...

If anybody finds a way around the automatic compression of the
documentation on the debhelper side: Please tell me. All automatic
packaging instructions I have come up with are in the DebianPackaging
branch of our git repo.

Kind regards,

Gunter.
Robert Dodier
2017-07-12 03:57:55 UTC
Permalink
Post by Robert Dodier
I looked at the patches and I agree that some of them could be merged
into Maxima. Any such commit should be identified as originating from a
specific patch in a specific Debian tarball, to make it easier to know
what changes have and have not been applied.
I've merged the following patches as obtained from
maxima_5.39.0-2.debian.tar.

088c60d fix_closeto_test_1: compute numerical test with numer flag.
71930d0 utf8-gcl-alphabetp: modify ALPHABETP for GCL.
41b5506 pathname and patches/pathname1: fix up conditionalizations in defsystem.lisp for GCL.
3904c6a taylor_test_errors: mark expected failures for GCL.

I didn't merge other patches, which were mostly or entirely about where
to put info files and other file/directory topics.

best

Robert Dodier
Thomas D. Dean
2017-07-12 05:02:07 UTC
Permalink
Post by Robert Dodier
Post by Robert Dodier
I looked at the patches and I agree that some of them could be merged
into Maxima. Any such commit should be identified as originating from a
specific patch in a specific Debian tarball, to make it easier to know
what changes have and have not been applied.
I've merged the following patches as obtained from
maxima_5.39.0-2.debian.tar.
088c60d fix_closeto_test_1: compute numerical test with numer flag.
71930d0 utf8-gcl-alphabetp: modify ALPHABETP for GCL.
41b5506 pathname and patches/pathname1: fix up conditionalizations in defsystem.lisp for GCL.
3904c6a taylor_test_errors: mark expected failures for GCL.
I didn't merge other patches, which were mostly or entirely about where
to put info files and other file/directory topics.
best
Robert Dodier
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
maxima-local
Maxima branch_5_40_base_133_g54d7e47 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite();
Running tests in rtest_rules: 103/103 tests passed
...

Running tests in rtest_taylor:
********************** Problem 23 (line 75) ***************
Input:
taylor(rat(x (x - 1)), x, 0, 5)


Result:
2
(- x) + x + . . .

... Which was correct, but was expected to be wrong due to a known bug in
Maxima.

********************** Problem 129 (line 459) ***************
Input:
taylor(rat(factor(1 + x)), x, 0, 1)


Result:
1 + x + . . .

... Which was correct, but was expected to be wrong due to a known bug in
Maxima.
149/149 tests passed (not counting 8 expected errors)
Running tests in rtest_dot: 60/60 tests passed
Running tests in rtest_mset: 112/112 tests passed
...
Running tests in rtest_algsys: 55/55 tests passed


No unexpected errors found out of 11,229 tests.
real time : 99.180 secs
run-gbc time : 75.900 secs
child run time : 9.779 secs
gbc time : 12.869 secs

Tom Dean
Robert Dodier
2017-07-13 04:56:48 UTC
Permalink
Post by Thomas D. Dean
********************** Problem 23 (line 75) ***************
taylor(rat(x (x - 1)), x, 0, 5)
2
(- x) + x + . . .
... Which was correct, but was expected to be wrong due to a known bug in
Maxima.
********************** Problem 129 (line 459) ***************
taylor(rat(factor(1 + x)), x, 0, 1)
1 + x + . . .
... Which was correct, but was expected to be wrong due to a known bug in
Maxima.
Yeah, the patch marked these as expected failures for GCL ... Not sure
what to think of this. For some version of GCL / on some platform? Does
it actually pass on all version/platform combinations now? I dunno.

best,

Robert Dodier

Marco Ciampa
2017-06-01 06:12:53 UTC
Permalink
Post by Viktor T. Toth
I just finished uploading RPMs for Maxima 5.40.0 to the package
repository. Sources are also uploaded.
Is there a what's new page somewhere?

TIA

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

------------------------

GNU/Linux User #78271
FSFE fellow #364

------------------------
Viktor T. Toth
2017-06-06 02:54:48 UTC
Permalink
There is a changelog:

https://sourceforge.net/p/maxima/code/ci/master/tree/ChangeLog-5.40.md


Viktor
-----Original Message-----
Sent: Thursday, June 1, 2017 2:13 AM
Subject: Re: [Maxima-discuss] Announcing version 5.40.0
Post by Viktor T. Toth
I just finished uploading RPMs for Maxima 5.40.0 to the package
repository. Sources are also uploaded.
Is there a what's new page somewhere?
TIA
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
------------------------
GNU/Linux User #78271
FSFE fellow #364
------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Loading...