How do you install mailman3 without stomping all over mailman2?

Since Python 2.7 is EOL, it is necessary to plan a move from mailman2 to mailman3. Mailman documentation recommends that you install mailman3 alongside mailman2 so you can migrate your lists. But, the port install of mail/mailman3 installs in the same directory (/usr/local/mailman). So, I used PREFIX=/usr/local/mailman3 to install. Unfortunately, the startup script (in /usr/local/etc/rc.d) is named mailman, so that overwrites the existing startup script. So, I edited the Makefile to change USE_RC_SUBR= mailman to USE_RC_SUBR= mailman3 and renamed the mailman.in file to mailman3.in.

The first step in setting up mailman3 is to run
Code:
mailman info
. So, I went directly to the install directory and ran the command. But I got this:
Code:
Traceback (most recent call last):
  File "bin/mailman", line 33, in <module>sys.exit(load_entry_point('mailman==3.3.1', 'console_scripts', 'mailman')())
  File "bin/mailman", line 22, in importlib_load_entry_point for entry_point in distribution(dist_name).entry_points
  File "/usr/local/lib/python3.8/importlib/metadata.py", line 503, in distribution return Distribution.from_name(distribution_name)
  File "/usr/local/lib/python3.8/importlib/metadata.py", line 177, in from_name raise PackageNotFoundError(name)importlib.metadata.PackageNotFoundError: mailman

Has anyone successfully installed mailman3 alongside mailman2 so they can migrate their lists to mailman3? One of my lists is fairly active, so I don't want to shut down mailman2 until I'm certain mailman3 is working. (Please, no comments about moving to sympa or some other mailing list manager.)
 
This is looking quite complicated.

Mailman Core 3.3.4 was released on Mar 21, 2021. The latest released version for Mailman Core can be found on PyPI. The Mailman Suite consists of 5 individual projects. Below are links to documentation for each of the projects.

Those packages are copyrighted by the Free Software Foundation and distributed under the terms of the GNU General Public License (GPL) version 3 or later.

mail/mailman3 does not install any of the other four components. There is a www/py-postorius and a mail/py-mailmanclient, but there is no hyperkitty port. Since hyperkitty is the list archiver engine, that's kind of essential.

Does anyone know if FreeBSD is going to migrate their lists to mailman3 or go in a different direction?
 
You may close this thread. I now see that a great deal of work is ongoing to get mailman3 running, and define an upgrade path from mailman2.
 
Does anyone know if FreeBSD is going to migrate their lists to mailman3 or go in a different direction?
That is one of those burning questions. Haven't seen it flare up on the freebsd-ports mail list recently, but there have been heated discussions in the past.

Personally, I'm going to avoid Python software from now on. Ansible is going to be the only big lift for me, but I don't run any mail lists.
 
I've been reading a bunch about it, and it seems some people are working toward getting it working on FreeBSD, but the work seems really slow. You would think there would be more urgency since freebsd's own mailing list software is Mailman2. Something has to give. Unless hyperkitty gets ported over and the dependency issues with mailman3 get fixed, I'm probably going to have to go to Sympa.
 
I installed mail/mailman3 in /usr/local/mailman3 (to keep it separate from the production mailman2 setup). I also installed all the missing dependencies (mail/py-authheaders, mail/py-authres, devel/py-importlib-resources, www/py-gunicorn, and devel/py-dateutil. Then I went to the directory and ran
Code:
bin/mailmain info
, and this is what I got:
Code:
bin/mailman info
Traceback (most recent call last):
  File "bin/mailman", line 33, in <module>
    sys.exit(load_entry_point('mailman==3.3.1', 'console_scripts', 'mailman')())
  File "bin/mailman", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
  File "/usr/local/lib/python3.8/importlib/metadata.py", line 503, in distribution
    return Distribution.from_name(distribution_name)
  File "/usr/local/lib/python3.8/importlib/metadata.py", line 177, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: mailman
Does anyone have any idea what I'm missing? I installed devel/py-importlib-metadata, but that didn't make any difference.
 
Mailman3 looks like a case study for the Second System Effect. I'd give it a miss.
You may well be right. Switching from a self-contained system that worked well to a modular system that requires the installation of five separate applications with the attendant setup and configuration headaches seems like a bit much. And right now, some of the required pieces aren't in ports, and the main port is missing dependencies. The only positive I can see is that FreeBSD is using mailman2, and I assume they will want to move to mailman3, so maybe they'll get this all figured out.

For now, I've pkg locked mailman2 and python27, and they will sit there until a better solution comes along.
 
I am running a very simple mailing list and i switched to mlmmj. Best descission ever. Very easy to set up, very clean, great documentation. Later I discovered Freebsd has switched at least some of the mailing lists to mlmmj.
 
I am running a very simple mailing list and i switched to mlmmj. Best descission ever. Very easy to set up, very clean, great documentation. Later I discovered Freebsd has switched at least some of the mailing lists to mlmmj.
The last update on that code was almost five years ago - 24 May 2017 - the last discussion on their mailing list is dated 2017-12. It might work fine now, but not being under current development is a no for me. Too much has changed in the past five years.
 
Well, it seems the death of mail/mlmmj is exaggerated:

Code:
bob$ git log  mail/mlmmj | grep -e commit -e Author -e Date -e mail/mlmmj
commit 191922dd097895100db92e0d103a03bdb19960f4
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Tue Aug 3 10:04:00 2021 +0200
    mail/mlmmj: Improve support for X-Original-From
commit 56643aaceb50afe06f1fb942110851fc3b3b0e0c
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Wed May 26 14:09:03 2021 +0200
    mail/mlmmj: fully handle X-Original-From
commit a2cc7761cc44f6abac141c304f08efd67057e77e
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Wed May 26 13:46:51 2021 +0200
    mail/mlmmj: fix typo in the original from support
commit 71daa4ae2f2b89711db9e1a74ac8eb204adf2bf1
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Wed May 26 13:30:03 2021 +0200
    mail/mlmmj: handle X-Original-From
commit d7f10130e0f3e48c29d71f14d963076bdd5bf979
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Mon May 24 11:19:21 2021 +0200
    mail/mlmmj: add a patch to disable bounce probe
commit 5b8888a8765f40addc5cc6c4d29638f348e07d1b
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Mon May 24 10:15:43 2021 +0200
    mail/mlmmj: enable the mlmmj-receive-strip plugin
commit c7fbbf15f3b8471c85f4c404c61fb2c9fbe1b923
Author: Dima Panov <fluffy@FreeBSD.org>
Date:   Thu May 20 22:07:45 2021 +1000
 
Well, it seems the death of mail/mlmmj is exaggerated:
Indeed https://codeberg.org/bapt/mlmmj-webview
Later I discovered Freebsd has switched at least some of the mailing lists to mlmmj.
Looks like that's the plan. No mailman3 for the Freebsd lists.

"We are currently in the middle of a migration from mailman to mlmmj. If a mailing list you are expecting is not here, it means it is not yet migrated, please have a look here"
 
So, it has a minimal web interface and requires the admin to write scripts that run through cron? One small step for man. One tiny leap for all mankind. I agree that mailman moving to their humongous multi-app setup is not exactly exciting. The last thing I need is MORE work.

Why is it that developers think every admin is a coder who loves digging into the bowels of apps and figuring out what they do? I just want things that work with minimal fuss and constant interaction on my part. (And no, that does not mean Winbloze.) When I have to do extra work to get an app working as it should, I tend to avoid installing such apps. And what really sucks is when I commit to an app and get it up and running, and then the developers turn around and multiply the complexity.

I know some of you guys love the tinkering aspect of Unix. I don't. I enjoy the fantastic network performance and stability of FreeBSD, and the access to almost all the open-source apps (through ports or packages), but I dislike the programmer aspect of some apps which are clearly documented by programmers which makes it harder for me to even grasp what they're saying much less implement it correctly.

Sadly, I've been forced to abandon managing one domain due to all these headaches, so that's one less FreeBSD box and one more CentOS box with cPanel on the net. (Ugh!) And so it goes.
 
Maybe you should view it from a different angle: does a mailing list manager really need a web interface for you to work? In most cases the answer is: it doesn't, you can perfectly fine manage a good mailing list manager by using emails. Heck, one of the most notorious global mailing lists - Linux kernel - still runs on the ancient Majordomo.

So using such a manager in combination with a statically served archive of the mailing list produced by a program like Hypermail, Lurker or mHonArc is pretty much what most people really need.
 
Why is it that developers think every admin is a coder who loves digging into the bowels of apps and figuring out what they do?
Because a lot of us are coders.

I just want things that work with minimal fuss and constant interaction on my part. (And no, that does not mean Winbloze.) When I have to do extra work to get an app working as it should, I tend to avoid installing such apps. And what really sucks is when I commit to an app and get it up and running, and then the developers turn around and multiply the complexity.
I do feel you here, though. I had to take stock of how much time I spent running Gentoo my way. The result was I'm here now.

I know some of you guys love the tinkering aspect of Unix.
Guilty as charged.

Sadly, I've been forced to abandon managing one domain due to all these headaches, so that's one less FreeBSD box and one more CentOS box with cPanel on the net. (Ugh!) And so it goes.
That is a bummer. I'm sorry we couldn't be of more help to you.
 
Because a lot of us are coders.


I do feel you here, though. I had to take stock of how much time I spent running Gentoo my way. The result was I'm here now.


Guilty as charged.


That is a bummer. I'm sorry we couldn't be of more help to you.
I don't blame the FreeBSD crowd for that. As I get older, I'm less inclined to dig into the bowels of programs to figure out why they're not working as expected. FreeBSD will always be the best OS (IMNSHO) for internet service. That particular domain was a PITA anyway because the owners understand precious little but think I can produce the results they want with little work.
 
Maybe you should view it from a different angle: does a mailing list manager really need a web interface for you to work? In most cases the answer is: it doesn't, you can perfectly fine manage a good mailing list manager by using emails. Heck, one of the most notorious global mailing lists - Linux kernel - still runs on the ancient Majordomo.

So using such a manager in combination with a statically served archive of the mailing list produced by a program like Hypermail, Lurker or mHonArc is pretty much what most people really need.
I wasn't even aware of that option. I'll take a look.
 
Maybe too late, but I didn't read this thread until today. I did a succesfully migration from mailman2 to mailman3 last december. There is an step by step on how I did it in
Since that I've been running all the lists that I host with mailman3. Smoothly.
 
Back
Top