* geogebra 6 : init at 6-0-598-0
since geogebra was ported from java to electron, this is a repacke;
wont want to delete geogebra 5, no darwin package for 6
ran nixpkgs-fmt over the file to cleanly reformat the spacings
Update pkgs/top-level/all-packages.nix
remove a trailing space
Co-authored-by: Tom Smeets <Tom.TSmeets@Gmail.com>
Update pkgs/applications/science/math/geogebra/geogebra_6.nix
Co-authored-by: Tom Smeets <Tom.TSmeets@Gmail.com>
Applied a sugestion for the formating of the lines
fixed a mistake, where the wrong name attribute was used
removed an unnecassary chmod statement
added a downlod link to archive.org
moved geogebra_6.nix to geogebra6.nix
removed unnecesary build inputs statement
* renamed to geogebra6
As suggested by Max Horn.
This exists since gap 4.10 and will only run the install checks once
while also exiting with an appropriate exit code. This new check has
uncovered some test failures, which are harmless and actually disabled
in a future gap release. The error-detection code for the previous test
target was probably broken.
According to the homepage[1]:
> Small change in Mori.h for compatibility with gcc_10 (thanks to J.
Puydt) [May 15, 2020].
Disabling the strictoverflow seems to be no longer necessary (I'm
relying on the check phase here).
[1] http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
The commit description is 18.02.0 -> 20.02.4, because in the last version bump (1c6a193b3e), the version string was changed, but the hash was not.
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
The better way to fix this would be to backport the upstream sphinx
patch:
faedcc48cc
Unfortunately it doesn't apply cleanly and isn't worth the effort
of backporting. Let's hope we can switch to python3 sage and the recent
sphinx version that comes with it before this becomes a problem.
I believe this test is currently incorrect on aarch64 and expects a
warning about loss of precision with much smaller numbers than the
platform's long doubles can handle.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
The pybrial package is a bit awkward. It doesn't have its own top-level
attribute, since it has a cyclic dependency with sage. That's one of the
reasons why it rarely gets updated. Its distributed along with brial, so
its best to keep the versions synchronized. The easiest way to do this
is to just re-use the source of brial.
I already did that once in 359bf7f1e3.
That change mysteriously got lost somehow (presumably in some merge
commit).
Nix has its own timeout settings, so there is no risk in running
forever. At the same time, some tests can exceed the default timeout
(30minutes per file for --long tests) when run on many weak cores (like
the aarch64 community builder or some hydra builders).
python.pkgs.pkgconfig raises an exception on missing packages since
version 1.5.0. Previously those errors were just silently ignored. That
worked fine, since the packages are only missing at runtime (when they
are not really needed) but present at buildtime.
Since this fails the tests now, we just add the packages to
PKG_CONFIG_PATH at runtime. This does not add additional runtime
dependencies. Still, it would be nicer if the sage testssuite would not
test the buildsystem at runtime in the first place.
The breakage was originally caused by the pkgconfig update in
1efa71616f.
cmp is deprecated since attrs 19.2.0:
http://www.attrs.org/en/19.2.0/changelog.html
The deprecation warning breaks the doctests. Fortunately they have a
rather long deprecation window, so we can just wait until upstream(s)
fix this.
elementary OS's ecosystem is curated around Ubuntu's LTS releases.
This means the development platform for their curated applications
always includes a LTS version of vala (in 18.04 it's 0.40).
Because of how vala development works it suspect some of these
applications to have serious issues if complied with the latest vala.
However in the past year or so, for Pantheon at least, I don't think
their applications will have much issues with latest vala, and if there
is I don't think they'd be difficult to fix. In this single regard they've
become more responsive since their preferred language is vala.
As for the curated applications I have less of this confidence in.
So I'd have to be accept less applications, but that's something
I'm willing to compromise on. And this is easily reversible or
could be done on a per-application basis. And nix already makes
this trivial.
Sage now by default expects the lcalc library to be named Lfunction
(instead of libLfunction). This could be changed by an environment
variable (https://trac.sagemath.org/ticket/28224), but various distros
seem to agree on this standard
(https://groups.google.com/forum/#!topic/sage-packaging/xvh55IxHTZg) so
it's best just to follow it. The old standard was set by sage anyway and
sage is the only consumer of lcalc in nixpkgs.
