[Mailman-Users] Start a new thread" button doesn't work - Mailman3.0.2 Panel

Mark Sapiro mark at msapiro.net
Mon Mar 21 17:06:33 EDT 2016

On 03/21/2016 12:15 AM, scorpio 2005 via Mailman-Users wrote:
> My question is still not answered, can i do upgrade using gitlab individuals component to fix this issue. that is, Example hyperkitty version installed already using mailman bundler. but is it possible for me to do upgrade hyperkitty using gitlab individual component latest version will fix this issue? Please treat this urgent request and totally stagnant now.

There is no easy answer to this. I am in the process of setting up a
production Mailman 3 instance at lists.mailman3.org to support a
mailman-users at mailman3.org list (not there yet). I'll outline what I did
which may help you, but it wasn't easy.

I created a system user 'mailman' and a /opt/mailman directory owned by

I cloned mailman-bundler from gitlab into /opt/mailman/mailman-bundler.

I created no virtualenv. In the mailman-bundler directory as the
'mailman' user, I more or less followed

I set buildout.cfg for 'production' and ran buildout, not in a venv.
I did 'sudo apt-get install ruby-sass' (this is on Ubuntu)
I installed psycopg2 and set config stuff for both Django and Mailman to
use PostgreSQL
I installed gunicorn
I configured postfix and nginx and set up mailman and gunicorn services,
installed the Django crontab, ran ./bin/mailman-post-update, etc. (not
necessarily in that order) and made a more or less working installation
with most of the software in /opt/mailman/mailman-bundler/eggs and
/opt/mailman/mailman-bundler/venv-3.4 as created by bundler.

I assume this is where you are now.

My first step towards upgrading was to clone the mailman master branch
from gitlab, activate the venv-3.4 virtualenv, run 'python3 setup.py
install' in the cloned branch directory with the venv installed. Then in
the venv-3.4/lib/python3.4/site-packages I removed the 3.0.2 'mailman'
directory and created a symlink mailman -> mailman-3.1.0-py3.4.egg/mailman.

This then worked to use the core mailman from the gitlab master branch.

This was still not what I wanted, so I then cloned the gitlab master
branches of mailman,  mailman-hyperkitty, hyperkitty, mailmanclient and
postorius and cd to each branch directory in turn and 'sudo command
setup.py install' where 'command is python for mailmanclient, hyperkitty
and postorius, and python3 for mailman and mailman-hyperkitty. This got
almost everything installed system wide (I.e. in
/usr/local/lib/python2.7/dist-packages/ and
/usr/local/lib/python3.4/dist-packages/ instead of
/opt/mailman/mailman-bundler/eggs and

The next step is the really tricky one. I verified that in the system
Python 3.4, I could import the top level module of every package in
/opt/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages and
then removed them all.

I did the same with Python 2 and the /opt/mailman/mailman-bundler/eggs
directory, but here, there were a few things I couldn't find in
/usr/local/lib/python2.7/dist-packages/, so I left them in eggs/. One is
gunicorn-19.4.5-py2.7.egg, which I had originally installed with
buildout and decided to just leave. The others are
beautifulsoup4-4.4.1-py2.7.egg, mock-1.3.0-py2.7.egg,
collective.recipe.cmd-0.11-py2.7.egg, pbr-1.8.1-py2.7.egg,
djangorecipe-2.1.2-py2.7.egg, Whoosh-2.7.2-py2.7.egg,
funcsigs-0.4-py2.7.egg, z3c.recipe.filetemplate-2.2.0-py2.7.egg and
zc.recipe.egg-2.0.3-py2.7.egg. I think mock is just for testing and the
zc stuff is for buildout and others may be unneeded, but I left them all.

I also did 'sudo pip3 install psycopg2' because I think both Python 2
and Python 3 versions are required.

I then went through all the scripts in mailman-bundler/bin and removed
all the no longer present paths from the sys.path[0:0] = [ ... ] at the

I may be forgetting something, but I think that was it.

I may have run into a missing import or two, but they were easy to fix.

The only other thing is you end up here with Django 1.9 only, and the
'mailman-web-django-admin runjobs daily' job runs into
"django.core.cache.get_cache was removed in Django 1.9 which breaks the
daily cache_cleanup job."  The fix is at

I do not recommend this as an install from scratch procedure at all. I'm
still figuring that one out, but if you already have a working install
with bundler and want to upgrade it without discarding all the
infrastructure already built, this may work for you.

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list