#9475 closed enhancement (fixed)
update M4RI to newest upstream release
Reported by:  malb  Owned by:  tbd 

Priority:  major  Milestone:  sage4.5.3 
Component:  packages: standard  Keywords:  M4RI, spkgcheck 
Cc:  mariah  Merged in:  sage4.5.3.alpha1 
Authors:  Martin Albrecht, Leif Leonhardy  Reviewers:  Leif Leonhardy, David Kirkby, Mariah Lenox 
Report Upstream:  Not yet reported upstream; Will do shortly.  Work issues:  
Branch:  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
The new version improves elimination to some extent, comes with a cleaner API and has an option to suppress SSE instructions.
Note to the release managers
Apply only m4ri_new_version.v2.patch to the Sage library when merging the new M4RI spkg.
Attachments (2)
Change History (55)
comment:1 Changed 9 years ago by
 Status changed from new to needs_review
comment:2 Changed 9 years ago by
I've run the M4RI self test (not the Sage test suite) on the following machines:
 x86_64 Linux (Xeon, sage.math and eno);
 x86 OSX (Xeon, bsd);
 ia64 Linux (iras);
 UltraSPARC T2 Solaris using GCC (t2.math.washington.edu)
 x86 Linux (VirtualBox);
comment:3 followup: ↓ 5 Changed 9 years ago by
 Status changed from needs_review to needs_work
 SPKG.txt under "Releases" says latest
release is libm4ri20100107, do you mean libm4ri20100701?
 Since spkgcheck exists, in spkginstall
the commented out lines:
# $MAKE check # if [ $? ne 0 ]; then # echo "libm4ri testsuite failed, please report upstream!" # exit 1 # fi
can be removed.
 In spkginstall, if SAGE_FAT_BINARY is yes, then
sse2 is disabled. What about sse3 as was the reported problem in #9381
 This version of libm4ri does not appear under the
downloads on the m4ri web site, thus no way to tell if the source in the spkg corresponds to the source under the claimed version.
comment:4 Changed 9 years ago by
 Cc mariah added
comment:5 in reply to: ↑ 3 Changed 9 years ago by
Replying to mariah:
 SPKG.txt under "Releases" says latest release is libm4ri20100107, do you mean libm4ri20100701?
Fixed.
 Since spkgcheck exists, in spkginstall the commented out lines:
# $MAKE check # if [ $? ne 0 ]; then # echo "libm4ri testsuite failed, please report upstream!" # exit 1 # fi
can be removed.
Fixed.
 In spkginstall, if SAGE_FAT_BINARY is yes, then sse2 is disabled. What about sse3 as was the reported problem in #9381
We never use SSE3, but yeah all checks for SSEx instructions are suppressed in that case.
 This version of libm4ri does not appear under the downloads on the m4ri web site, thus no way to tell if the source in the spkg corresponds to the source under the claimed version.
This is because I am upstream and wanted to wait for portability issues before putting the release on the website. I'm putting it online now, if that makes your life easier.
comment:6 Changed 9 years ago by
 Status changed from needs_work to needs_review
comment:7 Changed 9 years ago by
The changes to SPKG.txt
, spkginstall
and spkgcheck
are not checked in.
comment:8 Changed 9 years ago by
SPKG.txt
:
 Author should be Authors
 Is the given email address still uptodate?
 I'd substitute "function names match what the function is doing now" by "function names now match ... is doing"
 s/supress/suppress/
 s/SSE2 instruction/SSE2 instructions/
spkginstall:
 Old typo, I guess: s/CLFAGS/CFLAGS/ twice
 The choice of the variable name
SSE2_SUPPORT
isn't that nice; I'd rather call itDISABLE_SSE2
, but never mind.
spkgcheck:
 Uses
make
rather than$MAKE
(in contrast tospkginstall
), but shouldn't be a problem.
comment:9 followup: ↓ 13 Changed 9 years ago by
 Status changed from needs_review to needs_work
I'd suggest adding the (standard) section Special Update/Build? Instructions to SPKG.txt
, with the following:
 Remove upstream Mercurial repository (directory
src/.hg
, filesrc/.hgtags
)  Remove directory
src/autom4te.cache
, filesrc/m4ri.vcproj
I've built a p1 spkg with the above mentioned files removed: 392KB vs. 1.2MB
If there are no dependencies on Sage packages (which is the case here), we don't need to add $SAGE_LOCAL/include
to the preprocessor search path in spkginstall
(CFLAGS
and CPPFLAGS
).
Perhaps touch src/configure
, because it has the same time stamp as configure.*
.
Upstream notes:
 There is no target
clean
. src/NEWS
andsrc/ChangeLog
are empty files. ;)
Tests in progress,
Leif
comment:10 Changed 9 years ago by
 Ubuntu 9.04 x86 (P4 Prescott, gcc 4.3.3) Sage 4.5.rc0 (with ECL 10.2.1.p1):
ptestlong: All tests passed.
 Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3) Sage 4.5.rc0:
ptestlong: All tests passed. (with my strippeddown M4RI spkg, see above)
I've only installed the new package (dated July 13th) and applied the patch, i.e. did not build Sage from scratch, and haven't (yet) run the testsuite.
comment:11 Changed 9 years ago by
Shame on me I missed that one:
./spkginstall: line 47: [x: command not found
if ["x$SAGE_FAT_BINARY" = "xyes"]; then SSE2_SUPPORT="disablesse2" else SSE2_SUPPORT="" fi
should be
if [ "x$SAGE_FAT_BINARY" = "xyes" ]; then ...
Note that [
is actually a command (namely an alias for or link to test
, depending on the shell), and ]
is its last parameter.
On both of the above systems, the testsuite passed without errors.
(I reinstalled the package(s) with SAGE_CHECK="yes"
.)
comment:12 Changed 9 years ago by
Just let me know if I should provide (a) reviewer patch(es) to the spkg (after a commit to the changes not yet checked in); I cannot upload an updated spkg to sage.math though.
Leif
comment:13 in reply to: ↑ 9 Changed 9 years ago by
Replying to leif:
 Remove upstream Mercurial repository (directory
src/.hg
, filesrc/.hgtags
) Remove directory
src/autom4te.cache
, filesrc/m4ri.vcproj
I've built a p1 spkg with the above mentioned files removed: 392KB vs. 1.2MB
It's strange that there was an autom4te.cache, since I rm it in my release script. I'm okay with these changes.
comment:14 followup: ↓ 15 Changed 9 years ago by
Leif,
I'd appreciate if you could update SPKG according to your suggestions, I'm okay with them all. If you upload the SPKG somewhere or send it my way I can upload it to sage.math.
comment:15 in reply to: ↑ 14 Changed 9 years ago by
Replying to malb:
I'd appreciate if you could update SPKG according to your suggestions, I'm okay with them all. If you upload the SPKG somewhere or send it my way I can upload it to sage.math.
Ok, I'll create a cumulative spkg patch and a "strippeddown" p1 package in a few hours and then mail you both.
(I assume your .ac.uk email address in SPKG.txt is still appropriate as upstream contact.)
Currently running stresstest builds of 4.5.rc1... ;)
Leif
comment:16 Changed 9 years ago by
Yes, that's still current, however martinralbrecht@ googleblablabla might be current for a longer time.
Thanks!
comment:17 Changed 9 years ago by
 Description modified (diff)
 Status changed from needs_work to needs_review
Patch for p1 Sage package is up. Remember to commit Martin's changes (of July 13th) first before you apply this patch. (This patch does not remove the unnecessary files in src/
since they are not under our version control; they are of course deleted from the p1 spkg.)
(Link to) New libm4ri20100701.p1.spkg is on the way.
Tested with both 4.5.rc0 and rc1 (Ubuntu 9.04 x86_64).
Sorry for the delay.
Leif
comment:18 Changed 9 years ago by
 Report Upstream changed from N/A to Not yet reported upstream; Will do shortly.
 Reviewers set to Leif Leonhardy, David Kirkby
 Status changed from needs_review to positive_review
I uploaded Leif's SPKG to
http://sage.math.washington.edu/home/malb/spkgs/libm4ri20100701.p1.spkg
and I give it a positive review.
comment:19 Changed 9 years ago by
 Reviewers changed from Leif Leonhardy, David Kirkby to Leif Leonhardy, David Kirkby, Mariah Lenox
comment:20 followup: ↓ 21 Changed 9 years ago by
 Status changed from positive_review to needs_work
With a fresh build, sage doesn't start:
Traceback (most recent call last): File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/bin/sageeval", line 4, in <module> from sage.all import * File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/all.py", line 73, in <module> from sage.matrix.all import * File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/all.py", line 1, in <module> from matrix_space import MatrixSpace, is_MatrixSpace File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/matrix_space.py", line 40, in <module> import matrix_mod2_dense ImportError: /mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/matrix_mod2_dense.so: undefined symbol: mzd_lqup Sage failed to startup.
comment:21 in reply to: ↑ 20 ; followup: ↓ 22 Changed 9 years ago by
Replying to rlm:
With a fresh build, sage doesn't start:
Traceback (most recent call last): File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/bin/sageeval",line 4, in <module> from sage.all import * File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/all.py", line 73, in <module> from sage.matrix.all import * File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/all.py", line 1, in <module> from matrix_space import MatrixSpace, is_MatrixSpace File "/mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/matrix_space.py", line 40, in <module> import matrix_mod2_dense ImportError: /mnt/usb1/scratch/wstein/build/sage4.5.1/local/lib/python2.6/sitepackages/sage/matrix/matrix_mod2_dense.so: undefined symbol: mzd_lqup Sage failed to startup.
Looks as if you haven't applied the Sage library patch (or didn't do sage b
after that).
comment:22 in reply to: ↑ 21 Changed 9 years ago by
 Status changed from needs_work to positive_review
Replying to leif:
Looks as if you haven't applied the Sage library patch (or didn't do
sage b
after that).
I've been pretty bad about this lately... Sorry guys.
comment:23 followup: ↓ 25 Changed 9 years ago by
 Status changed from positive_review to needs_work
sage t long "devel/sagemain/sage/crypto/mq/mpolynomialsystem.py"  Unhandled SIGSEGV: A segmentation fault occurred in Sage. This probably occurred because a *compiled* component of Sage has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run Sage under gdb with 'sage gdb' to debug this. Sage will now terminate (sorry). 
comment:24 Changed 9 years ago by
I tried to reproduce your segmentation fault, but I can't.
malb@sage:~/scratch_sage/sage4.4$ ./sage t long devel/sagemain/sage/crypto/mq/mpolynomialsystem.py sage t long "devel/sagemain/sage/crypto/mq/mpolynomialsystem.py" [16.8 s]  All tests passed! Total time for all tests: 16.8 seconds malb@sage:~/scratch_sage/sage4.4$ cd devel/sage malb@sage:~/scratch_sage/sage4.4/devel/sage$ hg qap m4ri_new_version.patch singular3114.patch
comment:25 in reply to: ↑ 23 Changed 9 years ago by
Replying to rlm:
sage t long "devel/sagemain/sage/crypto/mq/mpolynomialsystem.py"  Unhandled SIGSEGV: A segmentation fault occurred in Sage. ...
Machine, OS, platform? Parallel test? Whole library or just that single file?
comment:26 Changed 9 years ago by
On geom.math, with a parallel build, in parallel and serial testing.
comment:27 Changed 9 years ago by
Trying: C = mq.MPolynomialSystem(r2).connected_components(); C###line 76:_sage_ >>> C = mq.MPolynomialSystem(r2).connecte d_components(); C Expecting: [Polynomial System with 16 Polynomials in 16 Variables, Polynomial System with 16 Polynomials in 16 Variables] ok Trying: C[Integer(0)].groebner_basis()###line 80:_sage_ >>> C[0].groebner_basis() Expecting: [x111*x110 + w113*x110 + w113*x112 + w113*x113 + w113*w111 + w113*w112 + x111 + x113 + w110 + w111 + w112, ... (more output) BOOM
comment:28 Changed 9 years ago by
I executed these steps
 I got a clean 4.5
 installed r2.10.1.p3.spkg #9396
 installed libm4ri20100701.p1.spkg #9475
 applied m4ri_new_version.patch to devel/sagemain repo #9475
 merged trac_9507.patch to local/bin repo #9507
 replaced spkg/install with "install.2" from the ticket #9528
 ./sage sdist 4.5.1
 then extracted the tarball...
 export SAGE_PARALLEL_SPKG_BUILD=yes
 export MAKE=make j20
 make
 since somehow libm4ri wasn't updated afterwards, I reinstalled libm4ri20100701.p1.spkg
Result:
malb@geom:~/scratch_sage/SIGSEGV/sage4.5.1$ ./sage t long devel/sage/sage/crypto/mq/mpolynomialsystem.py sage t long "devel/sage/sage/crypto/mq/mpolynomialsystem.py" [17.1 s]  All tests passed! Total time for all tests: 17.1 seconds
comment:29 Changed 9 years ago by
 Status changed from needs_work to positive_review
Well then, maybe it was a cosmic ray...
comment:30 followup: ↓ 33 Changed 9 years ago by
 Status changed from positive_review to needs_work
Do I need to apply
http://sage.math.washington.edu/home/malb/spkgs/libm4ri20100701.p1.spkg
and m4ri_new_version.patch? Can someone put the ticket number in the commit string?
comment:31 Changed 9 years ago by
 Milestone changed from sage4.5.2 to sage4.5.3
comment:32 Changed 9 years ago by
 Description modified (diff)
 Status changed from needs_work to positive_review
Note to the release managers
Apply only m4ri_new_version.v2.patch to the Sage library when merging the new M4RI spkg; that patch is identical to m4ri_new_version.patch
except for the commit message. (I don't have the power to replace Martin's attachment.)
comment:33 in reply to: ↑ 30 Changed 9 years ago by
Replying to mpatel:
Can someone put the ticket number in the commit string?
Done, but now we have yet another attachment since I couldn't replace Martin's.
(I would have thought his patch's comment was sufficient to conclude that the patch has to be applied to the Sage library repository... ;) )
comment:34 followup: ↓ 35 Changed 9 years ago by
Note: I haven't merged this ticket into 4.5.3.alpha0, because I noticed some segfaults that appear to stem from the new package and/or patch, when I doctested various trial alpha0s on sage.math. At the moment, it seems best to put out a 4.5.3.alpha0 with passing doctests and base on this any necessary efforts to merge the new M4RI into alpha1.
comment:35 in reply to: ↑ 34 ; followup: ↓ 36 Changed 9 years ago by
Of course, all long tests now pass (well, there are no reproducible failures) on sage.math with 4.5.3.alpha0 + #9475, so it seems no new efforts are necessary. I'm checking bsd, redhawk, and t2 now.
comment:36 in reply to: ↑ 35 Changed 9 years ago by
comment:37 Changed 9 years ago by
 Status changed from positive_review to needs_work
There definitely is a bug in this new M4RI, I do get SIGSEGVs on my new laptop. I'll investigate.
comment:38 Changed 9 years ago by
while(it!=end){ Exponent e=*it; from_term_map_type::const_iterator from_it=eliminated2row_number.find(e); assert(terms_as_exp_step1[row_start[from_it>second]]==e); assert(from_it!=eliminated2row_number.end()); ===> int index=from_it>second;//...translate e>line number; mzd_write_bit(mat_step2_factor,i,index,1); it++; }
This is where pbori.pyx crashes for me. I installed a new GCC today, so maybe that's to blame?
comment:39 followup: ↓ 40 Changed 9 years ago by
 Status changed from needs_work to positive_review
comment:40 in reply to: ↑ 39 Changed 9 years ago by
Replying to malb:
I think I got it: The PolyBoRi SPKG in 4.5.2 ships its own M4RI (and Boost) which conflicts with this new M4RI SPKG, thus since Leif removed this redundant copy of M4RI in the PolyBoRi, it works in 4.5.3.alpha0 but not before.
LOL! (Sometimes little cleanups make more sense than expected...)
comment:41 Changed 9 years ago by
It seems this ticket is incompatible with#9717. On my laptop I always get SIGSEGVs in pbori.pyx
comment:42 Changed 9 years ago by
I tracked down the issue. The cause is some assumptions inPolyBoRi? about M4RI which are not met anymore. This ticket can go in I say
comment:43 Changed 9 years ago by
comment:44 Changed 9 years ago by
Minor thing: the documentation for rank still says:
On average 'lqup' should be faster than 'm4ri' and hence it is
the default choice.
comment:45 Changed 9 years ago by
comment:46 Changed 9 years ago by
The updated patch only replaces the mention of LQUP with PLS
comment:47 Changed 9 years ago by
Should someone review the latest changes?
comment:48 followup: ↓ 49 Changed 9 years ago by
The only change in the new version compared to the previous version of m4ri_new_version.v2.patch is that one mention of LQUP was replaced by PLS in a docstring. That's all, this is why I didn't reset the status.
comment:49 in reply to: ↑ 48 Changed 9 years ago by
Replying to malb:
The only change in the new version compared to the previous version of m4ri_new_version.v2.patch is that one mention of LQUP was replaced by PLS in a docstring. That's all, this is why I didn't reset the status.
Not 100%:

m4ri_new_version.v2.patch
old new 1 1 # HG changeset patch 2 2 # User Martin Albrecht <malb@informatik.unibremen.de> 3 3 # Date 1277764034 3600 4 # Node ID 3 365789479e6d70cb1930b2e97c7874cbd3310db5 # Parent ba36200d8a2f844179785580245fd95aa6401a514 # Node ID 3b116dd35a84e0b6bd8ea12a732b8fa1fbda796f 5 # Parent 0bb69a98789215c64a81c4602f46a50c0aeca5f0 6 6 #9475 Adapts Sage library interface to new M4RI API (libm4ri20100701) 7 7 8 diff r ba36200d8a2f r 3365789479e6module_list.py9  a/module_list.py Fri Jun 25 10:05:592010 +01008 diff r 0bb69a987892 r 3b116dd35a84 module_list.py 9  a/module_list.py Tue Aug 10 13:46:10 2010 +0100 10 10 +++ b/module_list.py Mon Jun 28 23:27:14 2010 +0100 11 @@  783,7 +783,7 @@11 @@ 807,7 +807,7 @@ 12 12 Extension('sage.matrix.matrix_mod2_dense', 13 13 sources = ['sage/matrix/matrix_mod2_dense.pyx'], 14 14 libraries = ['gmp','m4ri', 'gd', 'png12', 'z'], … … 17 17 18 18 Extension('sage.matrix.matrix_modn_dense', 19 19 sources = ['sage/matrix/matrix_modn_dense.pyx'], 20 @@ 9 71,7 +971,7 @@20 @@ 995,7 +995,7 @@ 21 21 Extension('sage.modules.vector_mod2_dense', 22 22 sources = ['sage/modules/vector_mod2_dense.pyx'], 23 23 libraries = ['gmp','m4ri', 'png12', 'gd'], … … 26 26 27 27 Extension('sage.modules.vector_rational_dense', 28 28 sources = ['sage/modules/vector_rational_dense.pyx'], 29 diff r ba36200d8a2f r 3365789479e6sage/libs/m4ri.pxd30  a/sage/libs/m4ri.pxd Fri Jun 25 10:05:592010 +010029 diff r 0bb69a987892 r 3b116dd35a84 sage/libs/m4ri.pxd 30  a/sage/libs/m4ri.pxd Tue Aug 10 13:46:10 2010 +0100 31 31 +++ b/sage/libs/m4ri.pxd Mon Jun 28 23:27:14 2010 +0100 32 32 @@ 141,6 +141,9 @@ 33 33 # reduced row echelon form from upper triangular form … … 60 60 61 61 # reduced row echelon form using PLUQ factorization 62 62 cdef long mzd_echelonize_pluq(mzd_t *A, int full) 63 diff r ba36200d8a2f r 3365789479e6sage/matrix/matrix_mod2_dense.pyx64  a/sage/matrix/matrix_mod2_dense.pyx Fri Jun 25 10:05:592010 +010063 diff r 0bb69a987892 r 3b116dd35a84 sage/matrix/matrix_mod2_dense.pyx 64  a/sage/matrix/matrix_mod2_dense.pyx Tue Aug 10 13:46:10 2010 +0100 65 65 +++ b/sage/matrix/matrix_mod2_dense.pyx Mon Jun 28 23:27:14 2010 +0100 66 66 @@ 1010,15 +1010,16 @@ 67 67 # * Matrix windows  only if you need strassen for that base … … 116 116 k = 0 117 117 118 118 _sig_on 119 @@ 1681,7 +1691,7 @@ 119 @@ 1106,6 +1116,20 @@ 120 self.cache('rank', r) 121 self.cache('pivots', self._pivots()) 122 123 + elif algorithm == 'top': 124 + 125 + self.check_mutability() 126 + self.clear_cache() 127 + 128 + _sig_on 129 + mzd_top_echelonize_m4ri(self._entries, 0) 130 + r = 0 131 + _sig_off 132 + 133 + self.cache('in_echelon_form',True) 134 + self.cache('rank', r) 135 + self.cache('pivots', self._pivots()) 136 + 137 elif algorithm == 'linbox': 138 139 #self._echelonize_linbox() 140 @@ 1681,7 +1705,7 @@ 120 141 sage: float(d) 121 142 0.63184899999999999 122 143 sage: A.density(approx=True) … … 125 146 sage: float(len(A.nonzero_positions())/1000^2) 126 147 0.63184899999999999 127 148 """ 128 @@ 1691, 7 +1701,7@@149 @@ 1691,18 +1715,18 @@ 129 150 else: 130 151 return matrix_dense.Matrix_dense.density(self) 131 152 … … 134 155 """ 135 156 Return the rank of this matrix. 136 157 137 @@ 1702,7 +1712,7 @@ 158  On average 'lqup' should be faster than 'm4ri' and hence it is 159 + On average 'pls' should be faster than 'm4ri' and hence it is 160 the default choice. However, for small  i.e. quite few 161 thousand rows & columns  and sparse matrices 'm4ri' might be 162 a better choice. 138 163 139 164 INPUT: 140 165 … … 143 168 144 169 EXAMPLE:: 145 170 146 @@ 1722,10 +17 32,10 @@171 @@ 1722,10 +1746,10 @@ 147 172 cdef mzd_t *A = mzd_copy(NULL, self._entries) 148 173 cdef mzp_t *P, *Q 149 174 … … 156 181 mzp_free(P) 157 182 mzp_free(Q) 158 183 elif algorithm == 'm4ri': 159 @@ 2060,9 +20 70,9 @@184 @@ 2060,9 +2084,9 @@ 160 185 mzp_free(q) 161 186 return B,P,Q 162 187 … … 168 193 169 194 INPUT: 170 195 A  matrix 171 @@ 2074,14 +20 84,14 @@196 @@ 2074,14 +2098,14 @@ 172 197 173 198 EXAMPLE:: 174 199 … … 185 210 sage: LU 186 211 [1 0 0 1] 187 212 [1 1 0 0] 188 @@ 2095,7 +21 05,7 @@213 @@ 2095,7 +2119,7 @@ 189 214 [0, 1, 2, 3] 190 215 191 216 sage: A = random_matrix(GF(2),1000,1000) … … 194 219 True 195 220 """ 196 221 cdef Matrix_mod2_dense B = A.__copy__() 197 @@ 2104,15 +21 14,15 @@222 @@ 2104,15 +2128,15 @@ 198 223 199 224 if algorithm == 'standard': 200 225 _sig_on
comment:50 followup: ↓ 51 Changed 9 years ago by
Argh, I'm an idiot! I'll update the patch, the 'top' stuff must be removed
Changed 9 years ago by
Sage library patch  needed to comply with new M4RI API (libm4ri20100701). (Contains ticket number; apply only this one.)
comment:51 in reply to: ↑ 50 Changed 9 years ago by
comment:52 Changed 9 years ago by
 Merged in set to sage4.5.3.alpha0
 Resolution set to fixed
 Status changed from positive_review to closed
comment:53 Changed 9 years ago by
 Merged in changed from sage4.5.3.alpha0 to sage4.5.3.alpha1
I've uploaded an SPKG to
This SPKG also takes care of #9381 (SAGE_FAT_BINARY not being respected) and the M4RI part of #9281 (spkgcheck)