Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: What to backup?

by Alain Kohli

Thank you, that's perfect! For anyone that might stumble upon this, I had to make two minor adjustments to automate it. import os msg_ids = {} lm = getUtility(IListManager) ms = getUtility(IMessageStore) for mlistin lm.mailing_lists: requestdb = IListRequests(mlist) for rqin requestdb.held_requests: key, msgdata = requestdb.get_request(rq.id) if msgdata['_request_type'] !='held_message': continue msg = ms.get_message_by_id(key) msg_ids[(msg['Message-ID-Hash'])] =True for root, dirs, filesin os.walk('/docker/var/messages'): for filein files: if not msg_ids.get(file, False): msg = ms.get_message_by_hash(file) # It happened to me that msg was 'None' if msg: ms.delete_message(msg['Message-ID']) # I couldn't run it with '--run' and if you pipe it into 'mailman shell' # I needed this or the loop above wouldn't execute. pass On 5/27/19 6:22 AM, Mark Sapiro wrote: > On 5/26/19 3:07 PM, Mark Sapiro wrote: >> You could modify the above to write the list to a file and then wrap the >> whole thing in a shell script which would make the list and then do >> something like >> >> for f in `find var/messages -type f`;do >> n=`cut -d / -f5 <<<$f` >> for keep in `cat list` ;do >> k=0 >> if [ $n == $keep ] ;then >> k=1 >> break >> fi >> done >> if [ $k -eq 0 ]; then >> rm $f >> fi >> done > Actually, I thought about it a bit more, and I decided that arcane shell > script was a bit obscure and it would be easier to just do it in Python. > Plus, you can properly delete the message that way. > > A complete script for `mailman shell` is like > > import os > msg_ids = {} > lm = getUtility(IListManager) > ms = getUtility(IMessageStore) > for mlist in lm.mailing_lists: > requestdb = IListRequests(mlist) > for rq in requestdb.held_requests: > key, msgdata = requestdb.get_request(rq.id) > if msgdata['_request_type'] != 'held_message': > continue > msg = ms.get_message_by_id(key) > msg_ids[(msg['Message-ID-Hash'])] = True > > for root, dirs, files in os.walk('path/to/var/messages'): > for file in files: > if not msg_ids.get(file, False): > msg = ms.get_message_by_hash(file) > ms.delete_message(msg['Message-ID']) > >

6 years, 8 months

[MM3-users] Re: [EXTERNAL] Re: Database deadlock when trying to delete a member.

by Simon Coggins

Thanks I’ll give that a try. Also in my tracing of the code I noticed https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/dat… it starts with a single quote and ends with triple quotes so the single quote is never terminated. -Simon From: Mark Sapiro <mark(a)msapiro.net> Date: Wednesday, 24 March 2021 at 4:10 am To: "mailman-users(a)mailman3.org" <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: [EXTERNAL] Re: Database deadlock when trying to delete a member. On 3/22/21 9:53 PM, Simon Coggins wrote: > Ok after bit tracking I’ve worked out that the bouncer is dangling transactions when it’s sending warning messages. When https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…<https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…> is called and it get to update last_warn_sent it does the following in the DB: > > 2021-03-23 14:42:50.622 AEST [11693] LOG: statement: UPDATE member SET last_warning_sent='2021-03-23T04:42:50.622015'::timestamp, total_warnings_sent=1 WHERE member.id = 169331 > > But it never COMMITs this transaction. So all write operations are now hung waiting for the transction to be closed as the member record has been modified. As a test I added config.db.commit() after https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…<https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…> and restarted. And my mailman syncmembers worked perfectly and I didn’t have any hangs it correctly removed everyone it should have. In the database logs I can see the COMMIT. > > I’m pretty sure this is not the right spot for a config.db.commit() but hopefully this helps point to what might be going wrong. Thank you for all the research on this. It is extremely helpful. Instead of adding a commit after line 277 please try adding the @transactional decorator to the send_warnings_and_remove method at line 210 @transactional @dbconnection def send_warnings_and_remove(self, store): I think that is the proper fix. Let us know if that works. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>

4 years, 10 months

[MM3-users] Re: (Custom) Plugins: Proper file path(s) for adding a handler?

by Thomas Ward

I was able to instantiate the class AND get the expected three objects from it - pre_hook, post_hook, and resource. >>> from mailman_customizations.hooks import MailmanCustomizations >>> instance = MailmanCustomizations() >>> dir(instance) ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__implemented__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__providedBy__', '__provides__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'post_hook', 'pre_hook', 'resource'] I know Abhilash Raj is probably well versed in this from statements made elsewhere, so I've added them in the CC field. Abhilash Raj, any ideas? Thomas -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Tuesday, October 24, 2023 10:36 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: (Custom) Plugins: Proper file path(s) for adding a handler? On 10/24/23 3:56 PM, Thomas Ward via Mailman-users wrote: > > When I DO NOT have the module loaded in the configuration, `mailman > shell` works. Since that was functional, I went into the shell and > executed this: > > > from mailman_customizations.hooks import MailmanCustomizations > > This worked fine, but obviously importing the class doesn't > necessarily > *activate* the class. So something is up with how I'm *supposed* to > activate the plugin in the config, and we know that it's visible to > Mailman in its shell, but it can't autoload it. I'm past the limit of my knowledge here and only stabbing in the dark, but what happens after you import it. Can you instantiate it, e.g. ``` instance = MailmanCustomizations() dir(instance) ``` I'm not saying this should succeed, just that it may possibly provide useful information. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to teward(a)thomas-ward.net

2 years, 3 months

[MM3-users] Re: digests are created but not sent out

by "Jörg M. Schulz"

when I use the lines below, the templates are looked for in //var. When I comment them out, the location is correct: /var/lib/mailman3/ (debian buster standard) . The user list has full access. The folder is empty. See mailman.cfg: [mailman] # This address is the "site owner" address. Certain messages which must be # delivered to a human, but which can't be delivered to a list owner (e.g. a # bounce from a list owner), will be sent to this address. It should point to # a human. site_owner: help(a)elternserver.de # This is the local-part of an email address used in the From field whenever a # message comes from some entity to which there is no natural reply recipient. # Mailman will append '@' and the host name of the list involved. This # address must not bounce and it must not point to a Mailman process. noreply_address: noreply # The default language for this server. default_language: en [language.en] charset: utf-8 enabled: yes [language.de] description: German charset: iso-8859-1 enabled: yes > Am 09.01.2019 um 21:12 schrieb Mark Sapiro <mark(a)msapiro.net>: > > On 1/9/19 12:02 PM, "Jörg M. Schulz" wrote: >> start fails when I use >> >> >> # The default language for this server. >> default_language: en >> [language.en] >> charset: utf-8 >> enabled: yes >> >> when I comment out the lines above, mailman starts. > > > And in what section is this put? I.e. if the last preceding section > header is not [mailman], the default_language: en is in a section where > it doesn't belong. > > Or are you saying that you had set the server default_language to > something other than 'en' and the above is intended to change it to > 'en'. In that case, look at var/templates/en and ensure it and > subordinates are user:group list:list > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

7 years, 1 month

[MM3-users] Re: Disabled by bounce

by Allan Hansen

Mark, I can see your argument here, but if a 'Disabled by bounce' subscription is enabled, it would require just looking at that particular subscription and set the bounce count to 0, so that the next bounce (before staleness) does not disable it again. __ Yours, Allan On 2/2/23, 13:44, "Mark Sapiro" <mark(a)msapiro.net> wrote: On 2/2/23 04:54, Danil Smirnov wrote: > Hi Mark > > On Wed, Feb 1, 2023 at 9:28 PM Mark Sapiro <mark(a)msapiro.net> wrote: > >> Yes and no. If 'Bounce info stale after' is set to 3d and no bounces for >> a user are received in a 3 day period, the user's bounce score is not >> immediately reset, but it will be reset (to 1) the next time a bounce is >> received for the user. I.e., it is effectively the same thing unless you >> are looking at the user's bounce score which doesn't change until the >> next bounce. >> > > Isn't this a bug? We are now showing users' bounce scores on the Members > page and this would be misleading. Is it difficult from internals > perspective to have the bounce score reset immediately? Yes, it is not difficult, but it's a lot of processing. It would require something like a task runner task to periodically look at each row in the member table and if the bounce score is > 0, find the associated list's bounce_info_stale_after and if last_bounce_received + bounce_info_stale_after < now, reset the score. Consider a site like mail.python.org that at this moment has 79024 rows in the member table and 7531 of those have bounce_score > 0. That's a lot of processing, and is it really an issue to show a non-zero bounce score that's stale? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: mailman-users(a)mailman3.org <https://lists.mailman3.org/archives/list/<a href=>/message/ERW6LLR3VIJHUS5ECDA7A2P53WD7ZZEB/">https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to hansen(a)rc.org

3 years

[MM3-users] Re: digests are created but not sent out

by "Jörg M. Schulz"

When I remove the offending special character from the footer, digests are sent out perfectly. So, for international use, we have to wait for the language template system to be ready … By the way: Thank you for your continuing work with this marvellous piece of software. > Am 09.01.2019 um 19:16 schrieb Mark Sapiro <mark(a)msapiro.net>: > > On 1/9/19 9:33 AM, "Jörg M. Schulz" wrote: >> But, also in mailman log. >> Uncaught runner exception: 'ascii' codec can't encode character '\xdf' in position 157: ordinal not in range(128) >> Jan 09 12:24:06 2019 (17491) Traceback (most recent call last): >> File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 173, in _one_iteration >> self._process_one_file(msg, msgdata) >> File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 266, in _process_one_file >> keepqueued = self._dispose(mlist, msg, msgdata) >> File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 324, in _dispose >> mime = mime_digest.finish() >> File "/usr/lib/python3/dist-packages/mailman/runners/digest.py", line 185, in finish >> footer = MIMEText(footer_text.encode(self._charset), >> so the footers may not contain special characters. >> Will review this one. > > > in the above, self._charset is the character set of the lists > preferred_language. The footer can't contain characters not in the > character set of the list's preferred_language. For English (en) this is > us-ascii. For German (de) it is iso-8859-1. These are artifacts from > Mailman 2.1 > > You can change this for English by putting > > [language.en] > charset: utf-8 > > in your mailman.cfg. This works because us-ascii is a proper subset of > utf-8. > > For other languages, a change like this might require recoding of > templates and/or a message catalog, but since we don't currently ship > any non-English templates or message catalogs, that is moot at the moment. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

7 years, 1 month

[MM3-users] Re: Hyperkitty on Debian 12

by Markus Grandpré

Dear Mr Sapiro, thank you very much for your help. The required command is: # mailman-web hyperkitty_import \ -l mailman21-migration-test-04(a)mailman.uni-konstanz.de \ /var/mailman21/testlist.mbox Due to the following warnings, I still have to customize Hyperkitty: django_mailman3.MailDomain: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the DjangoMailman3Config.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. ... Can you give me another hint? As Linux admin I installed the packages mailman and mailman-web that were offered to me under Debian 12. Although during the installation of the packages user "list" was created, I cannot use it: # su - list This account is currently not available As with Mailman 2.1, I will probably have to continue working with Mailman3 as root. Too bad that there is no documentation for Debian admins like me, who don't want to dive too deep into the python framework. Or have I overlooked something? Best regards, Markus Am 25.03.24 um 18:56 schrieb Mark Sapiro: > On 3/25/24 07:58, Markus Grandpre wrote: >> Dear list members, >> >> when following the instructions to migrate list archives from >> Mailman21 to Mailman3 (see [1]), I face the following problem: >> >> # python3 manage.py hyperkitty_import -l mailman21-migration-test-04 >> /var/mailman21/testlist.mbox >> python3: can't open file '/var/mailman21/manage.py': [Errno 2] No such >> file or directory >> >> and have no clue, where to find the right <manage.py> file. The command > > > This depends on how you installed Mailman 3. You may or may not want > `python3 manage.py` at all. The required command could be something like > `django-admin` or `mailman-web`. > > Also the `#` prompt indicates you may be running as root. Mailman > related commands should be run as the Mailman user (could be `mailman` > or `list` or ... depending again on how you installed Mailman). Running > as root can create files owned by root that later can't be read by the > Mailman user. > -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

1 year, 10 months

[MM3-users] Re: config incoming email in my domain cpanel

by Rafael Mora

Hello Mark, Ok I Will ask hostgator if they provide mailman. Thank you very much for all your help! On Thu, Aug 3, 2017, 18:12 Mark Sapiro <mark(a)msapiro.net> wrote: > On 08/03/2017 02:14 PM, Rafael Mora wrote: > > El jue., 3 ago. 2017 a las 16:07, tlhackque via Mailman-users (< > > mailman-users(a)mailman3.org>) escribió: > > > >> You've said you're working with labbrands.com. > >> > >> labbrands.com has address 192.185.51.89 > >> mail.labbrands.com has address 192.185.51.89 > >> www.labbrands.com is an alias for labbrands.com. > >> > >> telnet proves that Exim is running on that IP address. Either you're > >> running it, or hostgator is redirecting the SMTP ports. > >> > >> You added: > >> lists.labbrands.com has address 190.145.27.66 > >> > >> Presumably that's a different machine. > >> > >> So that now needs an MX record, and a firewall routing. > > > > > > I added the MX record on our hostgator hosting like this: > > [image: image.png] > > > > Is it correct??? > > > Your screen shot, along with the excessive quoting, only caused your > post to be "too big". > > All the screen shot says is you have two MX records. The higher > priority, 0, is mail.labbrands.com and the lower priority , 1, is > lists.labbrands.com. > > What this means is mail to the domain will be delivered to > mail.labbrands.com unless that server is somehow unreachable in which > case lists.labbrands.com will be tried. > > This is probably not what you want. > > I hate to say this at this point, but you are on a cPanel host. cPanel > provides a functional Mailman 2.1 service. You might save yourself a lot > of grief by just using that. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

8 years, 6 months

[MM3-users] Re: Please help - Held message is crashing mailman.

by Mark Sapiro

On 4/5/19 10:27 PM, Alex King via Mailman-users wrote: > Hi, > > I've used mailman a lot in the past, and decided to install mailman3 in > a recent install. I'm unimpressed so far, it seems buggy. > > Running on Ubuntu 18.04.2 LTS from packages, mailman3 3.1.1-9, > mailman3-web 0+20170523-14, python-django-postorius 1.1.2-3. > > After a few messages, I now can't go to the "Held Messages" in > postorius, I get a 500 error. > > I tried to interact on the command line, but could not work out how. > Reading > https://mailman.readthedocs.io/en/latest/src/mailman/docs/install.html > and > https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…, > I tried: > > # mailman shell > Welcome to the GNU Mailman shell > >>>> command = cli('mailman.commands.cli_withlist.shell') > Traceback (most recent call last): > File "/usr/lib/python3.6/code.py", line 91, in runcode > exec(code, self.locals) > File "<console>", line 1, in <module> > NameError: name 'cli' is not defined > > I did a lot of reading of the manual and googled, but I have no idea > where the cli object is supposed to come from.....? The documentation > is confusing. The line command = cli('mailman.commands.cli_withlist.shell') in <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…> is dependent upon some behind the scenes setup to make the doctests work. Granted this is confusing, but basically all that does is set things up for the doctests to run the 'mailman shell' command. It is not intended to be run from within 'mailman shell'. > Anyway, after some trial and error, i found: > > # mailman shell > Welcome to the GNU Mailman shell >>>> list_manager = getUtility(IListManager) >>>> m=list_manager.get("committee(a)[redacted].org") >>>> from mailman.interfaces.requests import IListRequests >>>> requests = IListRequests(m) >>>> [x for x in requests.held_requests][0].id > 8 >>>> requests.get_request(8) > Traceback (most recent call last): > File "/usr/lib/python3.6/code.py", line 91, in runcode > exec(code, self.locals) > File "<console>", line 1, in <module> > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", > line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/lib/python3/dist-packages/mailman/model/requests.py", line > 120, in get_request > result.data_hash, expunge=False) > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", > line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/lib/python3/dist-packages/mailman/model/pending.py", line > 138, in confirm > value = json.loads(keyvalue.value) > File "/usr/lib/python3.6/json/__init__.py", line 354, in loads > return _default_decoder.decode(s) > File "/usr/lib/python3.6/json/decoder.py", line 339, in decode > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode > obj, end = self.scan_once(s, idx) > json.decoder.JSONDecodeError: Unterminated string starting at: line 1 > column 1 (char 0) > > It seems something was written out to disk that can't be read in for > some reason (assuming a json object on disk?) This is <https://gitlab.com/mailman/mailman/issues/385> which should be fixed by <https://gitlab.com/mailman/mailman/merge_requests/333>. The fix in in Mailman core version 3.2.0 > How do I debug this further? How do I find the json being decoded? Any > help would be appreciated. (I found mailman2 just worked, I was happy > with that.) The issue is in storing a pickled representation of the json encoding of 'rule_misses'. This gets very long if you have lots of header filters, and with at least the mysql backend gets truncated in the database which causes the Unterminated string error. I'm not sure what your options are for upgrading. The current Debian packages are all >= 3.2.0 [1], but Ubuntu doesn't get 3.2.0 until cosmic (18.10) [2]. [1] https://packages.debian.org/search?keywords=mailman3 [2] https://packages.ubuntu.com/search?keywords=mailman3 > (My colleague posted a bug about this I believe but I don't have the > link to that.) I haven't seen it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 10 months

[MM3-users] Re: [EXTERNAL] Re: Database deadlock when trying to delete a member.

by Simon Coggins

I’ve been running with this change as you suggested for a few weeks now in our test environment and I’ve not hit any issues. So this fixes my problem. Will this change be added to mailman core or should I look at manually patching during my upgrades? -Simon From: Mark Sapiro <mark(a)msapiro.net> Date: Wednesday, 24 March 2021 at 4:10 am To: "mailman-users(a)mailman3.org" <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: [EXTERNAL] Re: Database deadlock when trying to delete a member. On 3/22/21 9:53 PM, Simon Coggins wrote: > Ok after bit tracking I’ve worked out that the bouncer is dangling transactions when it’s sending warning messages. When https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…<https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…> is called and it get to update last_warn_sent it does the following in the DB: > > 2021-03-23 14:42:50.622 AEST [11693] LOG: statement: UPDATE member SET last_warning_sent='2021-03-23T04:42:50.622015'::timestamp, total_warnings_sent=1 WHERE member.id = 169331 > > But it never COMMITs this transaction. So all write operations are now hung waiting for the transction to be closed as the member record has been modified. As a test I added config.db.commit() after https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…<https://gitlab.com/mailman/mailman/-/blob/3.3.4/src/mailman/model/bounce.py…> and restarted. And my mailman syncmembers worked perfectly and I didn’t have any hangs it correctly removed everyone it should have. In the database logs I can see the COMMIT. > > I’m pretty sure this is not the right spot for a config.db.commit() but hopefully this helps point to what might be going wrong. Thank you for all the research on this. It is extremely helpful. Instead of adding a commit after line 277 please try adding the @transactional decorator to the send_warnings_and_remove method at line 210 @transactional @dbconnection def send_warnings_and_remove(self, store): I think that is the proper fix. Let us know if that works. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>

4 years, 10 months

Search results for query "sapiro"