Re: [Mailman-Developers] [Question #191915]: unsubscription from conversations in Mailman
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Wed, Mar 28, 2012 at 19:40, Odhiambo Washington odhia...@gmail.comwrote: On Wed, Mar 28, 2012 at 19:13, Florian Fuchs f...@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. image001.png___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Wed, Mar 28, 2012 at 20:03, Stephen J. Turnbull step...@xemacs.orgwrote: On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington odhia...@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. image001.png___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC
Hi Ana, Am 26.03.12 19:03, schrieb Ana Cutillas: Hi, my name is Ana Cutillas and I am a senior Computer Science student from Spain. I am really interested in working on the Mailman project either with you directly or with Systers. I have been reading the list of ideas to implement and I am very interested in the #6 Creating user profiles ( http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/). I have been wanting to work on a project that involved data mining for a while now and I think this could be a good opportunity. This would definitely be a very interesting GSOC project! It might involve working on a couple of different ends of the mailman family, like the django web ui (launchpad.net/postorius), the archiver/searcher (see hyperkitty - Toshio Kuratomi probably has more details) and maybe even the Mailman3 core (see: launchpad.net/mailman). In general, I think profiles should have the really straightforward information: last time they started a conversation, last time they sent an email to the list, when did they sign up, what time of the day are they more active, etc. But it should be fairly easy to add cool stuff like, in case a list allows the use of more than one language, the language the user uses the most and maybe even percentages of usage, and with some information retrieval we could get keywords to know what they like to talk about the most. Yes, those would all be very interesting pieces of data. I like some of the other ideas too, so I can talk to you about them if you want to. Of course! I think a good place to start would be to install mailman and postorius and have a look at the code. Also, Toshio could probably tell you a little bit more about the current work on the archiver. You can also find us on irc (#mailman on freenode, my handle is florianf, Toshio's is abadger1999) if you run into problems or have any questions. Florian ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Wed, Mar 28, 2012 at 22:31, Florian Fuchs f...@state-of-mind.de wrote: Hi Odhiambo, Am 28.03.12 18:47, schrieb Odhiambo Washington: 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 http://127.0.0.1:8000*:* root python 14108 43 tcp4 127.0.0.1:8001 http://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 The REST_SERVER setting defines the location of Mailman's rest API (which is frequently accessed by postorius), *not* the address of postorius itself. The API can only be accessed from localhost, so the setting has to be 'http://localhost:8001'. If you'd like to access postorius from a different machine as the one you're running it on, that's no problem: Just run the development server like this and you're good to go: python manage.py runserver 192.168.x.xxx:8000 (Don't do that on a machine that is exposed to the web though, since Django's dev server is not meant to be run in a production environment.) Hope that helps! Florian Thanks. At least I have a firewall in the name of OpenBSD's PF! I am yearning for the day MM3 will be production-ready. You guys are doing a great job! BTW - Seems MM3 will only be run with Postfix, because the Exim experts have not embraced it:-( -- 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. image001.png___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code
Stephen J. Turnbull step...@xemacs.org wrote: On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda te...@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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code
On Mar 28, 2012, at 10:29 AM, Stephen J. Turnbull wrote: 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. Mailman 3 itself requires unique Message-IDs. IIRC, the Mail Archive guys found a very very low collision rate over millions of messages, and I think all such cases were basically spam. The LMTP runner doesn't yet reject duplicates, but it should (LP: #967951). sI would guess she'll probably store messages in YY-MM/MSGID, or as git does in unpacked XX/... format, where XX are the first two digits of the hash ID, and YY... are the remaining ones). But it could easily be backed by an IMAP store or something more specialized; we don't really care as long as it's object-ID-addressable. Don't forget too that the LMTP runner automatically adds the X-Message-ID-Hash header, which is a Base32 encoding of the SHA1 hash of the Message-ID contents (without the angle brackets). This hash could be used as well. -Barry ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code
On Mar 27, 2012, at 11:51 AM, Toshio Kuratomi wrote: The searcher wouldn't be much use without an archiver. There is a sample archiver in mailman core -- if enabled, it stores the messages to lists in maildirs. It does not have a frontend for retrieving or otherwise displaying the archives. Yet. :) Probably a simplistic approach would be to extend the REST API to expose the IMessageStore as a top-level resource. At the simplest, it could provide a GET API which would accept Message-ID or X-Message-ID-Hash values and return the contents of the message, or a 404 if it doesn't exist in the store. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2012
On Mar 24, 2012, at 03:19 AM, vikash agrawal wrote: I am Vikash and very much interested in contributing to mailman and being a GSoC student this year. So far, I have successfully installed mailman in my system. Welcome! I do have skills in Python 2.7 but as I am very new to mailman thus I am looking for something small to hack and doable in this summer. Also, the idea page doesnot mention the skills required for the project so its somewhat difficult for me to choose one. As a result I would like you to guide me over the same . I am willing to learn a lot this summer :-) Fantastic! This is the right place to ask questions. Also many of us hang out on IRC using the freenode channel #mailman. Note that I've started to tag bugs in the tracker with 'easy' if I think they are (but I could be wrong :). So you could search bugs.launchpad.net/mailman for the 'easy' and 'mailman3' tags to find things to get started with. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] mailman / archive-ui / licensing questions
Thanks for the super-detailed replies... I'm separating these discussions, so here I have some questions about licensing and bundling.. So in some sense, CSLA needn't become *the* Mailman archiver, but it should definitely be *a* Mailman archiver. Then you can make all the engineering and design decisions you prefer, but with the confidence that it will Just Work with Mailman 3. Sure but this isn't why I'm here. CSLA is already *a* mailman archiver..I think we first released it in 2004. A few of us ex-egroups folks hacked it out because we used it for private projects. We open-sourced it so we could use it across organizational boundaries and because we were happy to give it away to anyone who wanted it. We're just all primarily focused on startup and commercial endeavors, so we havn't done much to package and popularize it. Right now I'm in between entrepreneural endeavors and spending some time 'giving back' and coding/donating-to/helping several open-source projects. As I engage with these projects, all of them are using Mailman, which is fantastic. However, nearly all of them are also using pipermail, which is not so great. They are using it because it's the default, so it was easy. I started to talk to one of them about installing CSLA (or MHonArc, or anything really), and realized I should see if you folks are interested in a great bundled archiver, to fix the problem at the source. I'm not particularly interested in promoting or maintaining an open-source project around this, so if you folks don't want a shiny new (S-BSD licensed) archiver to bundle, I'll probably just fix a few things, bump the CSLA archiver to 0.3 and move on. --- I admit that even with a pretty good knowledge of these many licenses, I'm not familiar with the intracacies of FSF copyright assignment and non-GPL free licenses. The ClearsilverArchiver code (written by me and two others) is released under the Simplified BSD license and totally free. It's important to me that any code I release be similarly free-and-unrestricted (i.e. BSD/Python/Artistic/PublicDomain), not free under certain conditions (i.e. GPL/LGPL). It's not possible to assert GPL restrictions on totally-free code, because it's already totally free. FSF says S-BSD is GPL-Compatible, which I believe means they are saying they have no problem with GPL code depending on and being combined with (i.e. linked with) S-BSD code, because the S-BSD code is fully open-source and does not put restrictions on the use of the GPL code. It's also my understanding that the primary reason for FSF copyright assignment is to provide a coherent entity to enforce the terms of the GPL by challenging violators who don't redistribute source something which is not necessary for S-BSD. (Though I suppose they could enforce that folks include the S-BSD copyright notices.) So I guess this all drives to the following question: Is Mailman-team is interested in having a better built-in archiver that is included in the distribution, but licensed under the less-restrictive S-BSD terms? Sorry for the length. This license stuff can be complicated. -- On a weirdly unrelated coincidence, thanks for smtpd.py. I just hacked it into smtp-to-maildir for a private hosted webmail installation. We were migrating code/data to some new machines and smtpd.py seemed simpler than fighting with qmail-installation or configuring postfix to accept everything (something it doesn't seem designed to do). But that absolutely shouldn't stop any other third party archiver from being Mailman 3 compatible. As I said, like the Python standard library, it's both a blessing and a curse. :) As for the features it doesn't have from your list: Editing would be easy to add because it's sqlite (deciding on the auth system is probably more of an issue than the editing). Anti-Crawl code is really an issue of configuration for cheap in-memory state-management. NNTP is well. that would be a big job that I doubt will be bitten off by something as small as a list archiver. Why can't we kill off Gmane while we're killing off Gmail, and *Groups? :). What is the REST UI used by? CSLA supports RSS. When it comes to a more involved REST UI, what software would be hitting it? I don't think I'll understand your other API/REST points until I see an answer to this. I'm a list owner and someone requests that a post containing private information be taken down. As a drive-by archive user, I want to request that a message get sent to me so that I can reply to it in my mail reader as if I had received the original. I run a question/answer forum that gateways a list, and I want to +1 really helpful messages, or give some extra kudos to really helpful users. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives:
