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
[WIP] singular: 4.1.1p2 -> 4.1.1p3 #45439
Conversation
Adds proper tests. Also removes the "enableFactory" option because singular actually enables factory by default and explicitly disabling it breaks the build. So the option was never really available.
I dunno, maybe now that you have commit access you could just drop me from maintainer list of packages that I only touched because of Sage. Inside Nixpkgs Singular is only used by Sage, and in any topic related to Sage you know much more than me. I wonder if there are non-Sage direct Nixpkgs users of Singular (for local development). |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: singular Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: singular Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: singular Partial log (click to expand)
|
I don't know which packages you maintain for which reason, if you want that it is probably best you remove yourself. I think two maintainers are better than one, but I understand that your time is limited. I think the ofborg failures are unrelated, I already encountered the cddlib failure somewhere else and am currently bisecting that. |
(Bisecting needs llvm rebuilds though :/) |
I said you could, not «you should», of course — I am OK with being listed as a maintainer and I will try to help as far as I can if someone has a problem with the package and chooses to ping me. You can safely assume, though, that I trust your judgement more than my own for the Sage dependencies. I am not sure what the mention is meant to mean in this case — maybe because I am used to (and I believe it is a reasonable approach to development given the scale) to direct pushes of changes to various packages, including non-maintainer updates to packages with a maintainer who just had not got around to bumping or fixing them. Re: bisecting: I think we have a recent staging merge to make the bisection even less convenient… |
Great :) I just pinged you in case you because you are a maintainer. In case you care and/or have an opinion about the change. It is fine if you don't. I generally prefer to go through PRs. In this case especially because I need ofBorg to see if the tests fail on other platforms. So I'll keep this open until the cddlib issue is resolved. I already did a lot of |
I generally prefer to go through PRs. In this case especially because I need ofBorg to see if the tests fail on other platforms. So I'll keep this open until the cddlib issue is resolved.
Yes, ofBorg testing is nice.
I already did a lot of `git bisect skip` hoping that I can get around the huge rebuilds but it looks like I'll just have to wait for them.
Maybe you want to look at #45442 and related discussion at the commit being reverted.
|
It actually is due to #40826 (after rebuilding llvm 3 or 4 times -- I didn't know changes so close to the root of the dependency tree are that frequent). |
@GrahamcOfBorg build singular |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: singular Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: singular Partial log (click to expand)
|
Timed out, unknown build status on aarch64-linux (full log) Attempted: singular Partial log (click to expand)
|
Waiting for sage support: https://trac.sagemath.org/ticket/25993#comment:21 |
Does https://trac.sagemath.org/ticket/25993#comment:30 give us hope for the next Sage release? |
Yes looks like the situation is better, but someone still has to work on it. I wish upstream wouldn't break on patch releases. Anyway since this is taking longer than expected, we could update and then just pin the sage dependency if you have any usecase for the latest singular? |
No hurry, I am just checking if any things GitHub shows me as pending (via its multiple inconsistent ways) are pending for transient reasons (some indeed were, but here we'll have to see what Sage upstream does) |
Ah, alright. In this case I'm CC'd on the upstream ticket, so as soon as that is ready I will know. |
Seems the latest is |
I'm still waiting for https://trac.sagemath.org/ticket/25993 to be resolved first. There has been recent progress, but I don't have the time to work on it directly right now. I'll just wait until the trac ticket is closed, then pull whatever patch they come up with into nixpkgs. |
An updated version of this patch (including the |
Motivation for this change
Adds proper tests to avoid something like #39370 in the future. Upstream is unclear about weather or not they are appropriate for packaging though. Since its a bit of a pain to contact upstream and they've been unresponsive for a while, I thought we may as well just try.
According to upstream, there may be difficulties with the tests running on 32 bit. Currently we don't compile on 32 bit anyways (reported that upstream too). As soon as we do, we can sort that out or disable some (or all if need be) tests.
Also removes the "enableFactory" option because singular actually enables factory by default and explicitly disabling it breaks the build. So the option was never really available.
@7c6f434c
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)