<div dir="ltr"><div><div dir="auto">Hi all,<br><br>mmass (previously maintained by this team, #525675, removed from unstable in 2019-10-18 after upstream went quiet) has an actively maintained successor: mMassX, <a href="https://github.com/SCIENCE-OPEN/mmassx">https://github.com/SCIENCE-OPEN/mmassx</a><br>a Python 3 port with current dependencies.<br><br>I've filed a fresh ITP (bug number to follow once it clears the BTS) and started a packaging skeleton at <a href="https://github.com/katalystnord/mmassx-debian">https://github.com/katalystnord/mmassx-debian</a>, built on top of the mmassx upstream repo.<br><br>It builds cleanly and passes lintian with no errors, and I've gone well past just building it: I actually drove the app through its main window, spectrum loading, About dialog, Preferences, and periodic table, not just launched it once. That surfaced seven real upstream bugs: mspy/calculations (a mandatory C extension) never built on Linux; a wxPython/numpy compatibility crash on the very first canvas draw; two dialogs (the shared progress dialog and the About box) crashing on open from the same wxWidgets sizer/parent mismatch; every <a href="http://mmass.org/">http://mmass.org/</a> link in the app being dead, since that domain is now parked; the Preferences dialog's Software Updates page rendering every widget on top of every other; and the periodic table crowded to the point of unreadable from a leftover negative grid gap (looks like a GTK2-era compensation that GTK3 no longer needs). I've packaged fixes for all of them as patches and sent the same fixes upstream:<br><a href="https://github.com/SCIENCE-OPEN/mmassx/pull/2">https://github.com/SCIENCE-OPEN/mmassx/pull/2</a> -- mmassx's maintainer has already had a first look and the branch is stable for review now.<br><br>One packaging decision I went back and forth on and want your take on. I initially pulled the old mmass 5.5.0-5 packaging from <a href="https://snapshot.debian.org/">https://snapshot.debian.org/</a> and mirrored its binary split: mmass (Architecture: all) for the app, mmass-modules (Architecture: any) for just the compiled calculations extension. But the mechanics behind that split don't carry over cleanly:<br><br>- The old mmass was Python 2, and mspy's submodules used implicit relative imports (e.g. mod_signal.py just did `import calculations`). In Python 2, when an implicit relative import doesn't find the module in its own package directory, it falls back to an ordinary absolute import across sys.path. That's what let the old package physically separate the two halves: mmass shipped the pure-Python mspy/*.py under /usr/share/mmass/mspy/, mmass-modules shipped<br>  calculations.so under a completely different directory, /usr/lib/mmass/mspy/, and debian/start-script bridged them by setting PYTHONPATH=/usr/lib/mmass/mspy/ before launching.<br><br>- mmassx is Python 3, and its code uses explicit relative imports (`from . import calculations`), which never fall back to a sys.path/PYTHONPATH search; they strictly resolve within the<br>  package's own directory. So I had to bridge the two packages with a symlink instead, plus a version-locked mmassx-modules dependency. It worked (built, tested, launched fine through the symlink), but it's a lot of extra machinery for what the split was buying: for a single 44KB compiled extension against a ~3.5MB package, the arch:all/any split saves essentially nothing in mirror footprint or build time, which is really the only reason to do it. Current dh-python/pybuild practice for a Python 3 module with one compiled extension is just to ship it as a single Architecture: any package (that's what python3-lxml, python3-numpy, etc. do), not to split<br>  out a "-modules" package the way python-support/pycentral packaging did back in the Python 2 era.<br><br>So I've gone with a single monolithic mmassx (Architecture: any) package instead of reproducing the old split. If there's a reason the team would still want it split for this one, I'm glad to redo it, but that's my current call.<br><br>If the team would like to co-maintain this under Debichem once it's in shape, I'm happy to move it to Salsa; equally happy to just get review from people who remember the quirks of the original package.<br><br>Thanks,<br>David</div></div></div>