Mailman 3 March 2012 - Mailman-Developers

Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code
by Bill Janssen March 28, 2012

March 28, 2012

Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda <terri(a)zone12.com> wrote: > > >> Looks like archiver for mm3 is still in development stage. As far as I > >> understand searcher depends on the srchiver, right? Not completely but it > >> somewhat depends on archiver. I am not sure if searcher can be implemented > >> without archiver. If possible I can implement for mm3 also. > > > > Searcher and archiver are interdependent *if* we want to share caches and > > data stores, which we probably do for any installation with larger archives > > where storing 2 copies vs 4 of each message would make a difference. Plus, > > many archive views may be basically searches "messages in the last month" > > "messages which are replies to messageid $foo" etc. > > Actually, as far as I can see, the summary/search/index/retrieval > functions depend only on the API for the message store. If you > want, you can split this into the database layer and a presentation > layer, of course. However, the database layer is surely going to > have its own schema optimized for the kinds of retrieval its > designer considers important. If the designer emphasizes > threads, however, she is *not* going to try to store messages in > thread order or anything like that. Rather, any reasonable store > will be message-ID-addressable. Right. UpLib has a 'message-store', which the threading code interacts with to generate threads as data referring to document IDs. The message-store API can take both message-IDs or UpLib document IDs and resolve them. > The only tricky issue is that we *do* have to worry about > message-ID collisions of truly different messages and about > messages without message IDs, especially for converted > historical archives. So the API needs to be able to deal > with these issues, probably by returning a set or sequence > of messages. Right. UpLib takes a message and creates multiple 'documents' (one for the message, and one for each attachment), each of which have their own unique 'doc ID', the assigned UpLib ID. In addition, the email is assigned a 'mail-guid', which is calculated from some of the header information and may also include the doc ID. The metadata of each attachment refers back to the 'mail-guid' of the message it was part of. Message-ID, mail-guid, and document ID are all separately indexed for each document, and any of them can be searched on. > Oh, and we probably ought to have a more general notion > of retrievable "object" rather than just messages, as some > archive/retrieval backends may store some types of MIME > part separately. Hopefully these would be presented to > us as MIME parts with external bodies and content IDs. Here's how I do it. In UpLib, a multipart email is analyzed into a message plus possible attachments. The parts that are the 'message' are unified and presented as a document. The parts that are attachments are broken out and processed as independent documents, iconified links to which are then put back into the 'message' document. See http://uplib.parc.com/misc/noguchi.png for an example of the UpLib reader, ReadUp, showing a plain-text email with an attached PDF file. Most of the things that can be links there (like "Reply" or the email addresses or my name or the URL or the attachment icon and name) are in fact links. > And that's all we want to say about the archiver and the > associated message-retrieval logic, I think. (In fact, it occurs to > me that maybe we should say "RFC 3501" and be done with > it. I don't mean that we necessarily implement IMAP protocol > per se, but some subset of its functionality probably is what we > need from an archiver.) Yes, there's an IMAP server that runs in UpLib, and can export any document via IMAP (including archived email). Though it currently doesn't scale well; I need to re-write it with Tornado, too. Bill

2 1

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
by Odhiambo Washington March 28, 2012

March 28, 2012

On Wed, Mar 28, 2012 at 20:03, Stephen J. Turnbull <stephen(a)xemacs.org>wrote: > On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington <odhiambo(a)gmail.com> > wrote: > > > However, I am lost as to why the argument to this procedure was named > > "syncdb" and not "createdb", which is what it's doing. Can you explain > that > > please? Sorry, I am a noob in this. > > It's called "syncdb" because it synchronizes the actual data store > with the schema, by creating and updating tables and indexes as > necessary. Creating a database is a special case of syncing where the > database is completely empty. However, the schema in Django is > dynamic; it will automatically add tables and indexes when the Django > application is changed. > > You don't need to know about this unless you plan to dig in and > develop the Django application that provides the administration > interface. > Thank you for the explanation. I actually accept the argument now:) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.

1 0

Re: [Mailman-Developers] [Bug 265831] Re: Autoreplies confirm subscription invitations
by Barry Warsaw March 28, 2012

March 28, 2012

On Mar 28, 2012, at 04:45 PM, Bernard wrote: >** Changed in: mailman/2.1 > Status: Fix Committed => Confirmed > >** Changed in: mailman/3.0 > Status: New => Confirmed Bernard, While I am glad you've found some enthusiasm for contributing to Mailman, please stop changing our bug statuses out from underneath us. You're just making our work harder this way. We would welcome you becoming more involved in Mailman, but it's important to understand our work flow first. Introduce yourself on the mailman-developers mailing list, and let us guide you on how to best participate in the project. Thanks, -Barry

1 0

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
by Stephen J. Turnbull March 28, 2012

March 28, 2012

On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington <odhiambo(a)gmail.com> wrote: > However, I am lost as to why the argument to this procedure was named > "syncdb" and not "createdb", which is what it's doing. Can you explain that > please? Sorry, I am a noob in this. It's called "syncdb" because it synchronizes the actual data store with the schema, by creating and updating tables and indexes as necessary. Creating a database is a special case of syncing where the database is completely empty. However, the schema in Django is dynamic; it will automatically add tables and indexes when the Django application is changed. You don't need to know about this unless you plan to dig in and develop the Django application that provides the administration interface.

1 0

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
by Odhiambo Washington March 28, 2012

March 28, 2012

On Wed, Mar 28, 2012 at 19:40, Odhiambo Washington <odhiambo(a)gmail.com>wrote: > > > On Wed, Mar 28, 2012 at 19:13, Florian Fuchs <f(a)state-of-mind.de> wrote: > >> Hi Odhiambo, >> >> Am 28.03.12 17:13, schrieb Odhiambo Washington: >> > Hey Jeff and all, >> > >> > I followed the "five minute guide", but I am hitting a brickwall: >> > >> > [root@jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# >> python >> > manage.py syncdb >> > Traceback (most recent call last): >> > File "manage.py", line 29, in <module> >> > execute_manager(settings) >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", >> > line 459, in execute_manager >> > utility.execute() >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", >> > line 382, in execute >> > self.fetch_command(subcommand).run_from_argv(self.argv) >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", >> > line 196, in run_from_argv >> > self.execute(*args, **options.__dict__) >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", >> > line 232, in execute >> > output = self.handle(*args, **options) >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", >> > line 371, in handle >> > return self.handle_noargs(**options) >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py", >> > line 57, in handle_noargs >> > cursor = connection.cursor() >> > File >> > >> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py", >> > line 15, in complain >> > raise ImproperlyConfigured("settings.DATABASES is improperly >> > configured. " >> > django.core.exceptions.ImproperlyConfigured: settings.DATABASES is >> > improperly configured. Please supply the ENGINE value. Check settings >> > documentation for more details. >> >> You're doing nothing wrong! Except you're using the latest Django >> version (1.4) which was released only some days ago... :-) >> >> In Django 1.2 support for multiple databases has been added, so they >> extended the format of the db definition in settings.py. It looks like >> in 1.4 the old format (which we have used so far) is no longer supported >> which most definitely causes the above error to be thrown. >> >> Changing the DATABASE setting in dev_setup/settings.py should do the >> trick. Like here: >> https://docs.djangoproject.com/en/1.4/ref/settings/#databases >> >> I will fix that in our launchpad branch as well, so these changes will >> go into the next alpha (which will probably be released not too far from >> now... :-) >> >> Florian >> > One more thing: In settings.py, I have this: REST_SERVER = 'http://192.168.40.252:8001' However, this doesn't seem to be respected when I do runserver: [root@jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python manage.py runserver Validating models... 0 errors found Django version 1.4, using settings 'dev_setup.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. [root@jaribu] /usr/home/wash# sockstat -l | grep 800 root python 77906 3 tcp4 127.0.0.1:8000 *:* root python 14108 43 tcp4 127.0.0.1:8001 *:* Since I am not using the server as a Desktop, I need a way to access it remotely, not via 127.0.0.1 -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.

1 0

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
by Florian Fuchs March 28, 2012

March 28, 2012

Hi Odhiambo, Am 28.03.12 17:13, schrieb Odhiambo Washington: > Hey Jeff and all, > > I followed the "five minute guide", but I am hitting a brickwall: > > [root@jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python > manage.py syncdb > Traceback (most recent call last): > File "manage.py", line 29, in <module> > execute_manager(settings) > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", > line 459, in execute_manager > utility.execute() > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", > line 382, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", > line 196, in run_from_argv > self.execute(*args, **options.__dict__) > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", > line 232, in execute > output = self.handle(*args, **options) > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", > line 371, in handle > return self.handle_noargs(**options) > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py", > line 57, in handle_noargs > cursor = connection.cursor() > File > "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py", > line 15, in complain > raise ImproperlyConfigured("settings.DATABASES is improperly > configured. " > django.core.exceptions.ImproperlyConfigured: settings.DATABASES is > improperly configured. Please supply the ENGINE value. Check settings > documentation for more details. You're doing nothing wrong! Except you're using the latest Django version (1.4) which was released only some days ago... :-) In Django 1.2 support for multiple databases has been added, so they extended the format of the db definition in settings.py. It looks like in 1.4 the old format (which we have used so far) is no longer supported which most definitely causes the above error to be thrown. Changing the DATABASE setting in dev_setup/settings.py should do the trick. Like here: https://docs.djangoproject.com/en/1.4/ref/settings/#databases I will fix that in our launchpad branch as well, so these changes will go into the next alpha (which will probably be released not too far from now... :-) Florian > > > Can anyone tell what I am doing wrong? > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind… > > Security Policy: http://wiki.list.org/x/QIA9

2 1

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1
by Barry Warsaw March 28, 2012

March 28, 2012

On Mar 28, 2012, at 01:54 PM, Stephen J. Turnbull wrote: >Indeed. I think Barry misspoke here. But remember, we're barely out >of alpha test, and we don't actually have a standard archiver, just a >simple handler to support further development. I just want to be careful about terminology here. "Handlers" specifically are modules that are invoked during pipeline processing. There's a 'to-archive' handler but all that does is put a copy of the message and metadata into the archive queue. There are also implementations of the IArchiver interface, which is where the actual work of getting the message injected into the archiver happens. Implementations are free to do whatever they want here, and in fact you'll see wide variety in the existing ones (send to an address, call a subproc, drop a file in a maildir). The archive queue runner is what loops over the available and enabled IArchiver implementations. So it goes something like: pipeline queue runner --to-archive-> archive queue runner --IArchivers--+ handler ^-------------| Cheers, -Barry

1 0

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
by Odhiambo Washington March 28, 2012

March 28, 2012

On Mon, Mar 26, 2012 at 00:34, Jeff Breidenbach <jeff(a)jab.org> wrote: > Congratulations! I was able to get Postorius running by following the > five minute quick start guide. I didn't see archiving settings in the > user interface, how do I set that up? > > Hey Jeff and all, I followed the "five minute guide", but I am hitting a brickwall: [root@jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python manage.py syncdb Traceback (most recent call last): File "manage.py", line 29, in <module> execute_manager(settings) File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", line 459, in execute_manager utility.execute() File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 196, in run_from_argv self.execute(*args, **options.__dict__) File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 232, in execute output = self.handle(*args, **options) File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 371, in handle return self.handle_noargs(**options) File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py", line 57, in handle_noargs cursor = connection.cursor() File "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py", line 15, in complain raise ImproperlyConfigured("settings.DATABASES is improperly configured. " django.core.exceptions.ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details. Can anyone tell what I am doing wrong? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.

1 0

Re: [Mailman-Developers] [Question #191915]: unsubscription from conversations in Mailman
by Barry Warsaw March 28, 2012

March 28, 2012

On Mar 28, 2012, at 08:35 AM, Bhavya PH wrote: >New question #191915 on mailman in Ubuntu: >https://answers.launchpad.net/ubuntu/+source/mailman/+question/191915 > >I have looked through the release notes of Mailman3.0 and can find >documentation only on a user subscribing, unsubscribing to mailing lists >using REST ful API, but I am a little confused about how users are >unsubscribed from conversations ? Can someone point me to that part of the >documentation? This feature does not yet exist in Mailman 3. -Barry

1 0

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1
by Stephen J. Turnbull March 28, 2012

March 28, 2012

On Wed, Mar 28, 2012 at 9:20 AM, Jeff Breidenbach <jeff(a)jab.org> wrote: >> archivers are configured site-wide, so there's almost nothing >> to expose in the web-ui. > > I'm worried about confusion. Indeed. I think Barry misspoke here. But remember, we're barely out of alpha test, and we don't actually have a standard archiver, just a simple handler to support further development. > The last thing we want is for a list to be > accidentally archived contrary to the list administrator's wish. It sounds > scary to me not to have any indication whatsoever in the web > interface. However, this is unavoidable, since in an open-subscription or confirm-only list anybody can request Gmane or mail-archive.com to subscribe, and of course users will save their mail in many cases. I think it's arguable that it's best to archive everything (eg, so you can demonstrate that a particular piece of spam did or did not come through your list), and lock it down at the archive-viewer level. > Along similar lines, there seems opportunity for confusion if there are > two independent mechanisms for archival; site wide configuration and > also manually subscribing an archival subscriber Personally, I think only the latter should be provided by default since it can't easily be prevented unless the list owner vets all subscribers very carefully (including having access to their .forwards!) Of course individual sites or lists can provide their own archiving handlers, and for the purpose of developing archivers and archive browsers offline, it may be useful to have a simple archive-to-maildir handler. (Note that the usual MTA/MDA suites can be used to deliver to maildirs, so for a list that's actually online, to get a local archive you just set up a $LIST-archiver virtual user delivering to maildir. AFAICS, this will be sufficiently efficient.)

1 0