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 mailmanThe 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
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 mailmanThe 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
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.html#id1thanks, Abhilash
On Fri, Nov 6, 2020, at 5: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 mailmanThe 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
-- thanks, Abhilash Raj (maxking)
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.html#id1
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...
Kind regards
Torge
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 Wed, Nov 25, 2020, at 1:58 AM, Mark Sapiro wrote:
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.
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 ;).
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.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/
-- thanks, Abhilash Raj (maxking)
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.2pointed 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.2just 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
On Wed, Nov 25, 2020, at 9:24 AM, Mark Sapiro wrote:
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.2pointed 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.
Yeah, I was thinking about internal references, :ref: which accepts heading names, but anchors aren't added you are right.
You can specify explicit anchor name in .rst too, I think just adding a
.. _news-3.3.2just 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.nwill always get a#idnid, but, e.g.3.3.0 – “Tom Sawyer”gets#tom-sawyer
Yep, I created news-3.3.3 for 3.3.3 and we can keep the convention going. I tested it out and it worked for me.
https://gitlab.com/mailman/mailman/-/merge_requests/736
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/
-- thanks, Abhilash Raj (maxking)
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:10 AM, Torge Riedel wrote:
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.
That column was added in 3.3.2 by https://gitlab.com/mailman/mailman/-/merge_requests/644 It is the migration to add that column that failed in the above.
It appears that somehow that migration was previously run and added the column, but the version_num entry in the alembic_version table was not updated to indicate that that migration had been run.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 07.11.20 um 02:38 schrieb Abhilash Raj:
You can install it using:
$ pip install --upgrade mailman
Hi,
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?
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
participants (5)
-
Abhilash Raj -
Brian Carpenter -
Mark Sapiro -
Seth Seeger -
Torge Riedel