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.
