Adds a symlink in /usr/share/jupyter/nbextensions, so that the js is
available in a jupyter notebook.
Otherwise, using 3d plots in the jupyter notebook will hit jsdelivr.net.
- compatibility with lrcalc 2.1 (trac #31355)
- fix doctests for ipython-8.1 (trac #33170)
- fix doctests for scipy-1.8 (trac #33336)
- fix doctests for sympy-1.10 (trac #33398)
- fix doctests when sphinx is installed (trac #33585)
- use new package threejs-sage for 3d plots
The package currently shipped in void gives me illegal instructions in a
nehalem cpu.
This commit fixes the issue by disabling native compilation unless a build
option is given; also disable popcnt which, although available on nehalem, is
not available in baseline x86_64.
Backported from upstream https://github.com/scop/bash-completion/pull/688
Fix checkdepends so tests run, deselect 26 tests that fail atm,
with the goal of fixing this for next release 2.12.
Also conditionally deselect a couple of tests that fail only on CI.
Also fix do_check() step:
- add python3-scipy to checkdepends, required by some tests
- add three patches from upstream that fix some other tests
- add a patch to (conditionally) skip a test that hangs on 32 bit
Note: on i686 2 tests fail (qa_ctcss_squelch, qa_constellation)
- patch maxima-sbcl so it uses gmp for arithmetic (closes#34849)
also add libgmp to shlib_requires since it won't be detected
- remove `nopie=yes` to fix#34861, replace by `nopie_files`
- remove `nostrip=yes`, replace by `nostrip_files`
- add checks for #34849 and #34861
- run testsuite only for full check (not in CI)
- some html and info files are shipped with source: do not rebuild
As of today, everything fails on CI with:
```
Run common/travis/fetch_upstream.sh
Fetching upstream...
fatal: remote error:
The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
Error: Process completed with exit code 128.
```
Switching `git://` to `https://` should fix this.
The option `nostrip_files` takes a filename without path, in contrast to
option `nopie_files` which takes only full path.
This commit makes it so that `nostrip_files` can take either the
filename or the full path.
Setting this variable will make xbps-src use an alternative mirror for
remote repositories.
Using this variable one can change the remote repository for all
architectures in a single setting and without the need to modify
`etc/xbps.d/repos-remote*.conf`. This is much more convenient as it
allows changing remote repos without a dirty worktree.
To use just add a line like the following to `etc/conf`:
XBPS_MIRROR=https://repo-us.voidlinux.org/current
We also disable 00-repository-main.conf for cross so we don't use the
remote repo from the xbps package.
- Added a build option 'ecl' (enabled by default)
- The ecl binary and library will be in a subpkg maxima-ecl so this
should not affect current users of maxima
- new patches:
- a0d7a43...: build a FASL library for ECL (this is merged upstream)
- handle-multiple-ldflags.patch: otherwise compilation with multiple
options in LDFLAGS fails (taken from debian)
- matrixexp.patch: fixes an error in matrix exponentiation (taken
from debian, this originates in sagemath)
A weak point is that the library maxima.fas is installed in
/usr/lib/ecl-${ecl_version} which is where ecl looks for them, but this
doesn't seem right.
Maybe an alternative would be to have the ecl package ship a symlink at
/usr/lib/ecl pointing to the versioned directory, then have the
maxima-ecl package place its library in the non-versioned directory.
The patch is taken verbatim from this particular comment:
https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3818325
Note that there are several fake variants of this CSR dongle
(usb id 0a12:0001) that need different workarounds. The gist itself
mentions a workaround (force-suspend) that is already included in 5.15
and fixes some dongles but not mine.
The issue is also mentioned in kernel bugzilla at
https://bugzilla.kernel.org/show_bug.cgi?id=60824#c187
Starting at comment 187 there are several reports of dongles fixed by
that patch (or a variation / rediscovery of the workaround).
Also: add basic tests to detect fpu miscompilation.
The program sets the fpu to 53 bit mode to get consistent results. It
turns out that doing this on musl breaks fmt_fp (-> printf) which uses
long double to format floats. Note this is an issue even on 64 bit musl,
although setting fpu to 53 bits is unnecessary on 64 bits because of the
default -mfpmath=sse.
The way Configure works: it tries different combinations of flags which
exercise different methods to change the fpu control word until one
works, meaning doubles are effectively 53 bits. The fix here is to try
first NOT touching the fpu control word. On x86_64 using the default
-mfpmath=sse this will succeed bypassing all fpucw modification.
For i686 using -mfpmath=387 (always if sse2 not available) the code will
fall back to changing the fpu control word as before. Since this is not
a problem for glibc, everything still works. I expect i686-musl to still
be broken, but we don't support that arch.
A simple way to test the bug on musl is to run
$ sympow -curve '[0,0,0,0,1]' -analrank
...
Analytic Rank is 0 : L-value 7.01091e-01
When the fpucw is changed, on musl this prints "7.01092e-01" instead.
The actual value computed to 128 bits with pari is:
$ echo 'elllseries(ellinit([0,0,0,0,1]),1)' | gp -q
0.70109105266272713058750953952514706773
so the glibc output is the correct one.
Again: what is broken is not computing but printing, as fmt_fp in musl
uses long double, which means messing with fpu control word breaks it.
This is important since sagemath parses sympow output.
This affects sagemath doctests as in
$ sage -t src/sage/lfunctions/sympow.py
...
(3 failures)
After this commit, the doctest in question passes on the 3 supported
archs.
Uses three patches taken from sagemath, cf
https://git.sagemath.org/sage.git/plain/build/pkgs/gfan/patches?h=9.5.beta7
- fix location of cddlib include files
- normalize the output of one failing test
- make tests return an error so build aborts
Also fixes for 32 bit bugs catched by testsuite:
- add `-ffloat-store` to CFLAGS to fix `0009RenderStairCase`
- patch typedef for `int64` which causes hang in `0602ResultantFanProjection`
The tests for ecl were not running as make check failed to find the
binary (according to upstream one should install it before running
tests, but properly setting some variables makes it work).
OTOH, there's a bunch of tests that fail. Out of 18098 tests there are
around 10 that fail on x86_64 and i686 (the number varies as some
failures are kind of random). On x86_64-musl there are about 30 more
failures but they all seem to be the same (something to do with the
value of acosh(-infinity)).
It's also the case that failures in the test suite will NOT stop make
with an error, so packaging with -Q is not broken.
it is left for the future to fix the failing tests and patch make check
so it actually fails the build.
Not revbumping b/c this does not change anything in the installed files.