On Sat, Dec 01, 2018 at 07:34:45AM +0100, Andreas Tille wrote: > On Tue, Nov 27, 2018 at 05:15:48PM +0100, Adam Borowski wrote: > > I'm afraid that your package fails to build with jemalloc 5.1.0-1 (currently > > in experimental). Transitioning to jemalloc 5 is long overdue, and some > > packages currently carry private copies of jemalloc which does not make the > > security and release teams happy. > > Thanks for working on jemalloc update and checking its rdepends.
I'm not sure if such a transition is viable before Buster. While the maintainers are not a problem (they have no tuits themselves but are open to NMUs, communicate swiftly, etc), I see problems with dependencies. These tend to be big prominent packages that are in a notoriously bad condition. Those which have been kicked out of testing are not a problem but at least neovim has an unfixed (for half a year!) FTBFS in unstable only. That'd make any transition of jemalloc pretty hard. > > Your package is the only RB-Dep that fails to build. > > Spades is originally carrying a code copy. I'm afraid upstream will > give the advise to use the code they are shipping which we want to > avoid. Could you possibly provide some patch which I could use and > provide to upstream once tested? Unfortunately I have no idea about > jemalloc. I don't have a clue about spades either -- nor really about jemalloc, for that matter. The latter is merely a dependency I need. And, in this particular case, memkind needs _patched_ jemalloc, anyway. As far as I know, this particular patch was rejected upstream. As other pieces of software also want that patch (eg. redis), it might be an option to carry it in a common library -- but for now, my preliminary memkind packaging also ships a patched copy. Other options would be having both jemalloc3 and jemalloc5. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.
