Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sage: 8.9 -> 9.2 #105615

Merged
merged 11 commits into from Dec 19, 2020
Merged

sage: 8.9 -> 9.2 #105615

merged 11 commits into from Dec 19, 2020

Conversation

collares
Copy link
Member

@collares collares commented Dec 1, 2020

Motivation for this change

@omasanori did most of the work in this update (see #101447), but I had some free time to finish up the work over the last days. All tests pass, except for the fact that src/sage/interfaces/singular.py is failing intermittently upstream (https://trac.sagemath.org/ticket/30945).

Keep in mind while reviewing is that I changed SAGE_LOCAL in sage-env.nix. There's a comment on the file explaining the motivation, but I am not sure if I made the right call.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

pkgs/applications/science/math/sage/sage-with-env.nix Outdated Show resolved Hide resolved
@@ -36,6 +36,17 @@ stdenv.mkDerivation {
};

patches = [
# https://git.sagemath.org/sage.git/tree/build/pkgs/ecl/patches/ECL_WITH_LISP_FPE.patch?id=f82c716fdf9c6e91a07166d36b6329a15ecfb41d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please use fetchurl?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh derp. You can use fetchurl but fetchpatch is better because it normalizes the patch that changing metadata does not cause a hash mismatch. Sorry about my derp.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't worry! I thought about that (it was done like this before), but the patches are plain files committed to Sage's repository, they are not dynamically generated. Does fetchpatch still provide an advantage in this case?

@omasanori omasanori mentioned this pull request Dec 1, 2020
10 tasks
@collares collares force-pushed the sage-update branch 3 times, most recently from f0ba932 to b17b4e5 Compare December 2, 2020 00:34
@collares
Copy link
Member Author

collares commented Dec 2, 2020

ecl.pyx is also intermittently segfaulting on the CI build (it passed before I pushed sagedoc changes which have nothing to do with ECL). A trac search returns nothing, and I can't reproduce the failure locally.

Update: This was a GC problem and is now fixed (see below).

@jcumming
Copy link
Contributor

jcumming commented Dec 2, 2020

I just gave this a whirl, and it works for me. I'll try it in a few more spots and see if I can isolate a failure.

@Synthetica9
Copy link
Member

I'm still running tests, but the build seems to work. Kudos!

@symphorien
Copy link
Member

I reviewed the giac/xcas update and it looks good to me.

@collares
Copy link
Member Author

collares commented Dec 2, 2020

Context for the intermittent failure: ecl.py is just

from sage.libs.ecl import *
from cysignals.tests import interrupt_after_delay
ecl_eval("(setf i 0)")
inf_loop = ecl_eval("(defun infinite() (loop (incf i)))")
interrupt_after_delay(1000)
inf_loop()

Here's the stacktrace for the ecl.pyx failure (running under Python instead of IPython, but that shouldn't make a difference).

#0  0x00007f58ee108c71 in sigsegv_handler ()
   from /nix/store/9wzdzij7qwv27ak6p93shmp22xwvx2ha-ecl-20.4.24/lib/libecl.so.20.4
#1  <signal handler called>
#2  0x00007f58ee11aca6 in ecl_cons ()
   from /nix/store/9wzdzij7qwv27ak6p93shmp22xwvx2ha-ecl-20.4.24/lib/libecl.so.20.4
#3  0x00007f58ee0bffb0 in ecl_interpret ()
   from /nix/store/9wzdzij7qwv27ak6p93shmp22xwvx2ha-ecl-20.4.24/lib/libecl.so.20.4
#4  0x00007f58ee0bd5b5 in ecl_apply_from_stack_frame ()
   from /nix/store/9wzdzij7qwv27ak6p93shmp22xwvx2ha-ecl-20.4.24/lib/libecl.so.20.4
#5  0x00007f58ee0bda55 in cl_apply ()
   from /nix/store/9wzdzij7qwv27ak6p93shmp22xwvx2ha-ecl-20.4.24/lib/libecl.so.20.4
#6  0x00007f58ee3337b4 in safe_cl_apply ()
   from /nix/store/cczgihp4z3f20mvgfw74kymjs0avxvsv-python3-3.8.6-env/lib/python3.8/site-packages/sage/libs/ecl.cpython-38-x86_64-linux-gnu.so
#7  0x00007f58ee33bcca in __pyx_f_4sage_4libs_3ecl_ecl_safe_apply ()
   from /nix/store/cczgihp4z3f20mvgfw74kymjs0avxvsv-python3-3.8.6-env/lib/python3.8/site-packages/sage/libs/ecl.cpython-38-x86_64-linux-gnu.so
#8  0x00007f58ee33c213 in __pyx_pw_4sage_4libs_3ecl_9EclObject_15__call__ ()
   from /nix/store/cczgihp4z3f20mvgfw74kymjs0avxvsv-python3-3.8.6-env/lib/python3.8/site-packages/sage/libs/ecl.cpython-38-x86_64-linux-gnu.so
#9  0x00007f5a89bffd47 in _PyObject_MakeTpCall ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#10 0x00007f5a89c6d839 in _PyEval_EvalFrameDefault ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#11 0x00007f5a89c681f1 in _PyEval_EvalCodeWithName ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#12 0x00007f5a89c67ef3 in PyEval_EvalCodeEx ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#13 0x00007f5a89cdea5b in PyEval_EvalCode ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#14 0x00007f5a89cef718 in run_eval_code_obj ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#15 0x00007f5a89cef6b3 in run_mod ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#16 0x00007f5a89bbb148 in PyRun_FileExFlags ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#17 0x00007f5a89bbaf1b in PyRun_SimpleFileExFlags ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#18 0x00007f5a89cf75e6 in Py_RunMain ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#19 0x00007f5a89cf6f59 in Py_BytesMain ()
   from /nix/store/fzgk230riagc58n8w1fa41ngs723pzpb-python3-3.8.6/lib/libpython3.8.so.1.0
#20 0x00007f5a896fedbd in __libc_start_main ()
   from /nix/store/a3syww9igm49zdzq3ibzw9m8ccvsgxla-glibc-2.32/lib/libc.so.6
#21 0x000000000040107a in _start ()

ecl_cons disables interrupts temporarily. Maybe that interacts badly with cysignals?

@collares
Copy link
Member Author

collares commented Dec 2, 2020

ecl/default.nix does not use boehmgc by default, but ecl/16.1.2.nix does. Is that intentional? The intermittent failures in ecl.pyx are related to that, and I fixed them by overriding useBoehmgc in sage/default.nix. I wonder if we should change the default GC, though.

@jcumming
Copy link
Contributor

jcumming commented Dec 2, 2020

I've come across a few more warts:

Copy link
Member

@Synthetica9 Synthetica9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiles and runs for me!

@Synthetica9
Copy link
Member

What's holding this up?

@jcumming
Copy link
Contributor

My derpy RS code stuff works. Thanks everyone! I support merging this.

@collares
Copy link
Member Author

collares commented Dec 14, 2020

I have rebased and reverted the cypari2 update that landed after this PR was submitted (in #105368), since it was decided in #103810 that we would wait for upstream to update cypari2 first (https://trac.sagemath.org/ticket/31029). Hopefully that helps with the failure.

@collares
Copy link
Member Author

Since there are several people on the Sage maintainer team and @omasanori already reviewed the patches, hopefully asking this will help coordinate: Is reviewing this a pending task on someone else's to-do list? If so, I am very happy to wait to get comments, especially on some potentially questionable decisions I made to get the testsuite to pass. I completely understand that time is a scarce resource, and this message is not intended to rush anyone! If you do intend to review this but haven't gotten around to do it yet, please don't re-order your to-do list because of this comment :)

On the other hand, if no one has a pending review, then I propose we merge this PR, since the tests currently pass (modulo the intermittent singular.pyx failure, which also affects upstream and is being investigated there) and there is user interest in getting Sage back into a usable state. There are definitely some parts that need feedback and cleanup, even if just removing "is this OK?" comments I left, but I promise to address any comments or suggestions quickly in a follow-up PR.

cc @timokau @7c6f434c

@symphorien
Copy link
Member

I ran nix-review successfully on this afternoon (before your last commit). Could you add an explanation in comment to the FIXME you added ?

The old `nauty` tarball is currently accessible at
https://distfiles.macports.org/nauty/nauty27r1.tar.gz. The diff is a
single line in genbg.c:

-    SUMMARY(&nout,t2-t1);
+    SUMMARY(nout,t2-t1);
pip install deprecated the --build flag. The standard python
installPhase (in pip-install-hook.sh) got updated in commit
76966f8, but we use a custom one so
we need to update it separately.
@collares
Copy link
Member Author

collares commented Dec 15, 2020

@symphorien Good catch, thanks! Those lines weren't needed after all, so I just removed them. I also squashed the sage fixups to help with merging.

@timokau
Copy link
Member

timokau commented Dec 19, 2020

Yes, I had planned to review this. Unfortunately my spare time for open source development is very limited recently and this is quite the diff, so I kept putting it off.

I agree with you: This is a definite improvement over the status quo and shouldn't be held off for too long. Sage and nixpkgs moves on, and things might break again. Given your promise to fix up any issues that come up in an "after the fact" review, I'm happy to merge this now and look at it in some more detail later. I have skimmed the changes and nothing sticks out.

Could you start discussions on the relevant sections of the diff where you need additional feedback?

Thank you @collares and @omasanori for your incredible work. I am very, very glad that we found not only one, but two people who have the motivation and skill to do this after I have neglected the package for so long.

@timokau timokau merged commit afead52 into NixOS:master Dec 19, 2020
Copy link
Member Author

@collares collares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many thanks @timokau for all your hard work over the years on packaging Sage, and @omasanori for doing most of the work in getting this back to a working state! Sorry for the delay in submitting this, I thought I had done it yesterday but I forgot to click "Submit review" :)

@@ -47,13 +44,26 @@ stdenv.mkDerivation rec {
chmod -R 755 "$SAGE_DOC_SRC_OVERRIDE"
'';

postPatch = ''
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is postPatch the right place for this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw some similar patch represented as a sequence of commands postPatch instances, so it is fine IMHO.

@@ -129,8 +123,21 @@ writeTextFile rec {
]
}'
export SAGE_ROOT='${sagelib.src}'
export SAGE_LOCAL='@sage-local@'
'' +
# TODO: is using pythonEnv instead of @sage-local@ here a good
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was one of the places where I wanted feedback. This (along with the sed change) makes environment tests pass, but I wasn't sure if using ${pythonEnv} instead of ${sage-with-env} is a good idea conceptually.

Also, now that I look at this, there's an orthogonal issue: I guess I should keep this as @sage-local@ and adapt sage-with-env.nix's substituteInPlace call with whatever value we decide to use.

src/sage/env.py

# Do not use sage-env-config (generated by ./configure).
# Instead variables are set manually.
echo '# do nothing' > src/bin/sage-env-config
'';

configurePhase = "# do nothing";
# Test src/doc/en/reference/spkg/conf.py will fail if
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream sage now has this src/doc/bootstrap file, which generates some files that are used in tests and documentation. I copied the part that is relevant to tests here and the documentation part into sagedoc.nix, but copying such a big chunk of code felt a bit icky. The alternative would be to generate an empty spkg/index.rst file, which is not terrible if there are no tests there anyway.

Also, is configurePhase the right place for this?

@yurrriq
Copy link
Member

yurrriq commented Dec 21, 2020

Thanks, everyone! Especially @omasanori!

@collares collares deleted the sage-update branch December 28, 2020 14:58
@jpas jpas mentioned this pull request Jan 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants