Hi Robin, I'm trying to troubleshoot some test failures in SageMath that are related to the version of glpk in use (does it need to be built with USE=gmp, is the version too old, are the tests themselves buggy, etc.) It would be a huge help if we had the latest version available in the tree.
François already has an ebuild in the sage-on-gentoo overlay that should work:
I think virtual/mysql should be updated, and virtual/pkgconfig should go in BDEPEND, but those are the only changes that stand out to me. Would you mind adding it?
You are glossing over the two extra patches there. Not including those patches will definitely lead to doctest failing. I think the first one is something upstream is not agreeing to (basically allowing the error recovery without having the program library just quitting on you). My memory about the second is more foggy, basically too much verbosity for the end user by default if I remember correctly.
As for the gmp useflag, I cannot remember what the problem is without it but I don't usually copy sage upstream unless I have too on these kind of dependencies.
USE=gmp makes things a lot faster, but I'm not sure if the doctests in Sage itself are looking for output that only happens when USE=gmp. This is one of my failing tests:
glp_exact: 5 rows, 1 columns, 4 non-zeros
GLPK bignum module is being used
(Consider installing GNU MP to attain a much better performance.)
* 0: objval = 0 (0)
* 0: objval = 0 (0)
and you can see that there's a warning there that maybe I should install GMP. Is that a bug in the doctest, or does it go away with a newer version of glpk?
Likewise with the error handling patch. Do the sage doctests fail without that non-standard patch that upstream has rejected? If so, then either the doctests are broken, or the configure script that decides to use the insufficient system glpk is buggy. Either way I'd like to know.
So, I'm not asking for the patches right now, just a new version that I can use to rule certain things out. As it stands, sage is using my system's (unpatched) glpk-4.63, and it's not working. If it also doesn't work with gplk-4.65, then I know it's something to be fixed in sage.
Oh, and *one* of the patches was accepted (written by) upstream:
So that one should be OK to backport.
mjo: you seem to use it enough, please add yourself as a maintainer and feel free to bump as needed.
The bug has been closed via the following commit(s):
Author: Michael Orlitzky <firstname.lastname@example.org>
AuthorDate: 2020-03-06 21:50:06 +0000
Commit: Michael Orlitzky <email@example.com>
CommitDate: 2020-03-07 02:13:24 +0000
sci-mathematics/glpk: new version 4.65.
This new upstream version fixes a few minor ebuild issues:
* I've attempted to fix the MySQL include location in a more standard
way, by using mysql_config (bug 597620). Another solution was already
present in v4.63, so I've marked this bug as resolved.
* The virtual/mysql dependency was replaced, per bug 666060. This will
be completely resolved when v4.65 goes stable and v4.63 is removed.
We also include a new patch, from upstream, to quiet some overly-verbose
output. The patch to debundle the system libraries was forward-ported to
the new version thanks to François Bissey, who maintained an ebuild for
v4.65 in the sage-on-gentoo overlay until now.
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Michael Orlitzky <firstname.lastname@example.org>
sci-mathematics/glpk/Manifest | 1 +
.../files/glpk-4.65-debundle-system-libs.patch | 91 ++++++++++++++++++++++
.../files/glpk-4.65-fix-mysql-include-prefix.patch | 47 +++++++++++
.../glpk/files/glpk-4.65-longstep_verbosity.patch | 23 ++++++
sci-mathematics/glpk/glpk-4.65.ebuild | 69 ++++++++++++++++
5 files changed, 231 insertions(+)