<div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, 5 Jan 2019 11:05:38 +0200 Faidon Liambotis <<a href="mailto:paravoid@debian.org">paravoid@debian.org</a>> wrote:<br>> Therefore attached is a patch that addresses this using the je_rallocx<br>> API. It also deals with the deprecation of the stats.cactive statistic<br>> (as of jemalloc 4.0), using the stats.active instead.<br>> <br>> The patch should be 3.6.0-compatible as well and can go in anytime and<br>> ahead of a potential jemalloc transition. It is lightly tested (i.e.<br><div>> builds and runs the test suite).</div><div><br></div><div>Dear Faidon,</div><div><br></div><div>Thank you for your patch. I was unable to get the tests to complete locally. Via an upload to experimental I confirmed that they do hang on the build machines as well: <a href="https://buildd.debian.org/status/fetch.php?pkg=spades&arch=amd64&ver=3.13.0%2Bdfsg-2%7E0jemalloc5&stamp=1547148149&raw=0">https://buildd.debian.org/status/fetch.php?pkg=spades&arch=amd64&ver=3.13.0%2Bdfsg-2%7E0jemalloc5&stamp=1547148149&raw=0</a></div><div><br></div><div>I see a couple paths forward:</div><div><br></div><div>1. The patch is evolved so that the tests pass</div><div>2. jemalloc is rolled back from 5 to 3 as it breaks an established package and the archive is starting to freeze for Buster</div><div>3. Same as 2, but a jemalloc5 package is introduced for packages that are compatible.</div><div><br></div><div>My goal is that Spades is not dropped from Buster, but looking at the schedule (and the length of the NEW queue) I am afraid that this may happen.</div><div><br></div><div>Obviously method 1 would be ideal, if it can be accomplished in time.</div><div><br></div></div></div></div>