* Package name : mmassx
Version : 6.0.1
Upstream Author : Martin Strohalm (original mMass), gyellen, SCIENCE-OPEN
and mMassX contributors
* URL : https://github.com/SCIENCE-OPEN/mmassx
* License : GPL-3+
Programming Lang: Python
Description : mass spectrometry data viewer, processing and
analysis tool

mMassX is a maintained fork of mMass, an open source,
multiplatform application for viewing, processing and analyzing mass
spectrometry data that was widely used in proteomics. It supports common
raw and exported spectrum formats (mzXML, mzData, mzML, MGF, plain
text), peak picking, deisotoping and de-noising, mass calibration and
mass defect plotting, peptide/protein mass fingerprinting and fragment ion
search, and a compound editor with a periodic table for elemental
composition searches.

This is a reintroduction. mMass was previously packaged for Debian (ITP
#525675) and maintained by the Debichem Group from 2011, but was removed
from unstable on 2019-10-18 after upstream development had stalled for
several years. mMassX picks up that upstream
lineage and ports it to Python 3 with current dependency versions, so I'd
like to bring the package back under the new upstream name.

Packaging work in progress at:
https://github.com/katalystnord/mmassx-debian

Status: builds cleanly with dpkg-buildpackage, passes lintian with no
errors (a couple of expected warnings only), and it's genuinely usable, not
just building: I actually drove the app through its main window, spectrum
loading, About dialog, Preferences, and periodic table. Doing that surfaced
seven real upstream bugs (a Linux build failure in a mandatory C extension;
a wxPython/numpy compatibility crash on the very first draw; two dialogs
crashing on open from a wxWidgets sizer/parent mismatch; every
http://mmass.org/ link in the app being dead, since that domain is now
parked; a Preferences page rendering all its widgets on top of each other;
and a periodic table crowded to the point of unreadable from a leftover
negative grid gap). I've packaged fixes for all of them as patches and sent
the same fixes upstream: https://github.com/SCIENCE-OPEN/mmassx/pull/2
-- mmassx's
maintainer has already looked it over and the branch is stable for review
now.

One packaging decision worth flagging: the old mmass was split into mmass
(Architecture: all) and mmass-modules (Architecture: any) for just its one
compiled extension. That split made sense under the
old python-support/pycentral Python 2 tooling, but current
dh-python/ pybuild practice doesn't call for it: for one 44KB extension
against a ~3.5MB package, splitting saves essentially nothing and would
add real complexity (mmassx's Python 3 code uses explicit relative imports,
which don't tolerate the PYTHONPATH trick the old package used to bridge
the split, so the modern equivalent needs a symlink between the two
packages plus a version-locked dependency). I tried this both ways and I'm
proposing a single monolithic Architecture: any package instead, matching
how current Debian packages a Python module with a compiled extension.
Happy to hear if the team sees it differently.

I'd welcome co-maintenance or review from the Debichem team, given their
history with the original package.