-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
sage: 8.9 -> 9.2 #105615
Conversation
b2861ea
to
2fbcd37
Compare
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
f0ba932
to
b17b4e5
Compare
Update: This was a GC problem and is now fixed (see below). |
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. |
I'm still running tests, but the build seems to work. Kudos! |
I reviewed the giac/xcas update and it looks good to me. |
Context for the intermittent failure:
Here's the stacktrace for the
|
|
I've come across a few more warts:
|
There was a problem hiding this 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!
What's holding this up? |
My derpy RS code stuff works. Thanks everyone! I support merging this. |
6fe3f50
to
90fb6b1
Compare
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. |
348aeda
to
a60c239
Compare
fde8630
to
82aa21d
Compare
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 |
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.
3bb5391
to
1f11137
Compare
1f11137
to
8100c5a
Compare
@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. |
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. |
There was a problem hiding this 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 = '' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
Thanks, everyone! Especially @omasanori! |
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
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)