On 11/6/20 8:38 PM, Abhilash Raj wrote:

Hi Everyone,

I am pleased to announce that with a week long delay from the planned date, GNU Mailman Core 3.3.2 is now finally out. This release includes both bug fixes and some new features.

Some notable changes include:

• Support for inviting users to join mailing lists.
• New adddmembers, delmembers and syncmembers command to manage membership from CLI.
• Addition of new REST API endpoints that return the count of held messages and subscription requests of much faster page loads in Postorius.
• Addition of support for filtering in some API endpoints like Members and Subscription requests.
• Support for address= option in email join command to subscribe an address other then sending address.
• Addition of who email command to lookup memberships.
• Expose emergency field for MailingList resource in REST API.
• Several bug fixes to support new major version of libraries like dnspython, flufl.* etc.

You can install it using:

 $ pip install --upgrade mailman

The tarball for the release is available at PyPI:

 https://pypi.org/project/mailman/

Finally, many thanks to all the contributors who have helped make this release a success!

Thank you for the hard work that went into this release.

Is there a change log somewhere that documents the complete changes/bug fixes that went into this release?

--

Brian Carpenter Harmonylists.com Emwd.com

When will these changes be available via the docker container?

Thanks, Seth

On Nov 6, 2020, at 8:38 PM, Abhilash Raj <maxking@asynchronous.in> wrote:

Hi Everyone,

I am pleased to announce that with a week long delay from the planned date, GNU Mailman Core 3.3.2 is now finally out. This release includes both bug fixes and some new features.

Some notable changes include:

• Support for inviting users to join mailing lists.
• New adddmembers, delmembers and syncmembers command to manage membership from CLI.
• Addition of new REST API endpoints that return the count of held messages and subscription requests of much faster page loads in Postorius.
• Addition of support for filtering in some API endpoints like Members and Subscription requests.
• Support for address= option in email join command to subscribe an address other then sending address.
• Addition of who email command to lookup memberships.
• Expose emergency field for MailingList resource in REST API.
• Several bug fixes to support new major version of libraries like dnspython, flufl.* etc.

You can install it using:

$ pip install --upgrade mailman

The tarball for the release is available at PyPI:

https://pypi.org/project/mailman/

Finally, many thanks to all the contributors who have helped make this release a success!

-- Abhilash Raj (maxking) on behalf of Mailman Core team

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

Am 07.11.20 um 02:38 schrieb Abhilash Raj:

You can install it using:

 $ pip install --upgrade mailman

Hi,

today I did this on my setup and got the following exception after "systemctl restart mailman":

# systemctl status mailman.service mailman.service - GNU Mailing List Manager Loaded: loaded (/opt/mailman/core/mailman.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2020-11-22 09:59:53 CET; 46s ago Process: 30520 ExecStop=/opt/mailman/core/bin/mailman.sh stop (code=killed, signal=TERM) Process: 30597 ExecStart=/opt/mailman/core/bin/mailman.sh start (code=exited, status=1/FAILURE) Main PID: 1223 (code=exited, status=0/SUCCESS)

Nov 22 09:59:53 basis2 mailman.sh[30597]:   File "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/protocol.py", line 220, in check_error Nov 22 09:59:53 basis2 mailman.sh[30597]: err.raise_mysql_exception(self._data) Nov 22 09:59:53 basis2 mailman.sh[30597]:   File "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/err.py", line 109, in raise_mysql_exception Nov 22 09:59:53 basis2 mailman.sh[30597]:     raise errorclass(errno, errval) Nov 22 09:59:53 basis2 mailman.sh[30597]: sqlalchemy.exc.InternalError: (pymysql.err.InternalError) (1060, "Duplicate column name 'archive_rendering_mode'") Nov 22 09:59:53 basis2 mailman.sh[30597]: [SQL: ALTER TABLE mailinglist ADD COLUMN archive_rendering_mode INTEGER] Nov 22 09:59:53 basis2 mailman.sh[30597]: (Background on this error at: http://sqlalche.me/e/2j85) Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Control process exited, code=exited status=1 Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Failed with result 'exit-code'. Nov 22 09:59:53 basis2 systemd[1]: Failed to start GNU Mailing List Manager.

I checked the database and - yes - there is already such a column in the DB. So I tried it the "hacker" way and just removed the column from the DB and give "systemctl restart mailman" a second try. Now it worked and the column is back.

I don't know if this column was already there from 3.3.1.

I use MySQL as the DB backend.

Kind regards Torge

On 11/22/20 1:22 AM, Torge Riedel wrote:

I like to ask what to do with other packages when upgrading mailman. I noted, that after upgrading mailman, all requirements are fulfilled, but a lot updates are available:

(venv) mailman@basis2:~/core$ pip3 list --outdated Package             Version Latest Type

---

aiosmtpd            1.2     1.2.2  sdist alembic             1.4.2   1.4.3  wheel atpublic            1.0     2.1.1  sdist dkimpy              1.0.4   1.0.5  sdist dnspython           1.16.0  2.0.0  wheel flufl.i18n          2.0.2   3.1.3  sdist flufl.lock          3.2     5.0.3  sdist idna                2.9     2.10   wheel importlib-metadata  1.6.1   2.0.0  wheel importlib-resources 2.0.1   3.3.0  wheel passlib             1.7.2   1.7.4  wheel PyMySQL             0.9.3   0.10.1 wheel requests            2.23.0  2.25.0 wheel SQLAlchemy          1.3.17  1.3.20 wheel urllib3             1.25.9  1.26.2 wheel zipp                3.1.0   3.4.0  wheel zope.component      4.6.1   4.6.2  wheel zope.event          4.4     4.5.0  wheel zope.interface      5.1.0   5.2.0  wheel

Should I update them (regularly) or may I break something in mailman?

In some cases and at some times, Mailman itself specifies a version <= something for a dependency. There have been issues where an upgraded dependency is not compatible with current Mailman.

You can look at the install_requires section of setup.py to see if there are any specific version requirements, but this is not fool proof. For example, flufl.lock 5.0 broke Mailman core (See https://gitlab.com/mailman/mailman/-/issues/754). This was fixed in core version 3.3.2.

Thus, If Mailman is working with the set of installed dependencies that you have and all of them satisfy >= requirements in setup.py, it's probably safest to leave them as is.

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

On 11/22/20 1:04 AM, Torge Riedel wrote:

Am 07.11.20 um 04:24 schrieb Abhilash Raj:

...

I missed it in the original email, but a full list of changes in this version is present here:

     https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.h...

Hi,

this link now points to 3.3.3, is there a chance to make this link more stable? Maybe

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.h...

Those links are created by Sphinx and as you note the fragments are not stable. I don't know if it's possible to tell Sphinx via the .rst source how to name the fragments. Maybe the best idea is to not use fragments at all and just point to the document.

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

On 11/24/20 7:22 PM, Abhilash Raj wrote:

I think I should keep in mind next time to use the #<heading-name> like #3.3.2 pointed out by Torge, instead of #id (which is what I see when I hover over the Link in browser so I copied ;).

It's more complicated than that. Sometimes the fragment name is the heading and sometimes it is #idn. At the moment, neither #3.3.2 nor #3.3.3 work at all as these are #id2 and #id1 respectively. Currently the fragment for 3.3.3 Bugs is #bugs and the fragment for 3.3.2 Bugs is #id3, but presumably prior to the addition of 3.3.3, #bugs was Bugs under 3.3.2, Just as now, #command-line is Command line under 3.3.2, but when a Command line section is added under 3.3.3, that will probably get the command-line id.

Thus, the note "Permalink to this headline" es misleading at best because it isn't very permanent fo an evolving document.

You can specify explicit anchor name in .rst too, I think just adding a .. _news-3.3.2 just above the heading will generate an anchor on the page with #news-3.3.2 (I haven't verified this but I think it will!) which links to the heading.

I too think this is correct. I suppose it might be worth doing for NEWS.rst in particular since Sphinx doesn't seem to like fragments like n.n.n. Another way to deal with this would be to always use code names. It seems like a heading n.n.n will always get a #idn id, but, e.g. 3.3.0 – “Tom Sawyer” gets #tom-sawyer

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