dap1--- via Mailman-users writes:
Stephen: I get it. It just seems there is no place where all these *nix dependent variations are easily found. Mailman docs seems like to logical place.
*You* don't need to find *all* the variations -- just what you have installed. *We* have to find them and keep them up to date.
Anyway, I still need help. I migrated my mailman2 to mailman3 per the documentation and all seemed to go well. However, now that I have the web UI working, no lists show up. Indeed, using mysql, all the relevant tables in mailman db are empty. How do I figure out if the import really worked when there are no error messages?
I really don't have any idea how you figure these things out, because the behaviors you report make no sense. There is clearly a lot that you haven't told us, but I don't know what that might be.
Mark suggests you may have used postgresql with Mailman core. Is postgresql installed on your system? There may be multiple versions and multiple database clusters per version. Find them and check for databases named 'mailman'. (And now you're at the end of my relevant knowledge of PostgreSQL.) I know almost nothing about MySQL, but I suppose the situation may be similar to PostgreSQL (multiple versions or flavors installed simultaneously, with multiple database clusters). Check that for 'mailman' databases, too. Check for running database servers. Something like "ps aux | grep sql" might catch them all, or maybe you need to scan the whole ps list.
Mark suggests that you may have multiple configurations active depending on how you try to access Mailman. Try
find / -name mailman.cfg
This should return exactly two instances: /etc/mailman3/mailman.cfg /opt/mailman/venv/lib/python3.12/site-packages/mailman/config/mailman.cfg (I'm guessing the version of Python and I'm only 99% sure it's /opt/mailman.) If others exist, there's a good chance they were automagically created when you started mailman the first time, and some chance they're being used when you invoke 'mailman' explicitly (eg, "mailman shell" or the migration command).
Similarly
find / -name settings.py
This should return /etc/mailman3/settings.py and a truckload of them under /opt/mailman/venv/lib/python3.12/site-packages. If there are others, copy the list for possible future reference. (Can't rule valid other instances out because it's such a common name.)
Search /etc/mailman3/mailman.cfg and /etc/mailman3/settings.py for spurious database configurations. (Pretty sure we checked for mailman.cfg already and it was OK, but I don't recall mentioning settings.py.)
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan