From anna.granudd at gmail.com Thu Jul 1 21:33:47 2010 From: anna.granudd at gmail.com (Anna) Date: Thu, 01 Jul 2010 19:33:47 -0000 Subject: [Bug 600780] [NEW] Login function needed in rest-client References: <20100701193347.18635.22304.malonedeb@wampee.canonical.com> Message-ID: <20100701193347.18635.22304.malonedeb@wampee.canonical.com> Public bug reported: For a good, working Mailman 3.0 UI we have to handle the passwords for each user (needed when they subscribe/unsubscribe/want to access their settings page but also for the admins and listowners). Hence, we need to implement the possibility to check for passwords in the rest-client (I believe these are saved in the user table in the core DB) and/or a login function. We should probably use https for the psw authentication. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest-api -- Login function needed in rest-client https://bugs.launchpad.net/bugs/600780 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From anna.granudd at gmail.com Thu Jul 1 21:36:09 2010 From: anna.granudd at gmail.com (Anna) Date: Thu, 01 Jul 2010 19:36:09 -0000 Subject: [Bug 600780] Re: Login function needed in rest-client References: <20100701193347.18635.22304.malonedeb@wampee.canonical.com> Message-ID: <20100701193609.16137.36742.malone@soybean.canonical.com> Or well, we need to implement this functionality to the rest-server to be able to implement it in the rest-client. -- Login function needed in rest-client https://bugs.launchpad.net/bugs/600780 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From adam at amyl.org.uk Thu Jul 1 22:56:36 2010 From: adam at amyl.org.uk (Adam McGreggor) Date: Thu, 01 Jul 2010 20:56:36 -0000 Subject: [Bug 600780] [NEW] Login function needed in rest-client References: <20100701193347.18635.22304.malonedeb@wampee.canonical.com> Message-ID: <20100701205636.GT25409@hendricks.amyl.org.uk> On Thu, Jul 01, 2010 at 07:33:47PM -0000, Anna wrote: > We should probably use https for the psw authentication. *ouch*. I'd really prefer that to be something configurable. I don't particularly want to run lists stuff over SSL. -- "I only can properly enjoy carol services if I am having an illicit affair with someone in the congregation. Why is this? Perhaps because they are essentially pagan, not Christian, celebrations." (Alan Clark's 'Diaries') -- Login function needed in rest-client https://bugs.launchpad.net/bugs/600780 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From anna.granudd at gmail.com Thu Jul 1 23:43:40 2010 From: anna.granudd at gmail.com (Anna) Date: Thu, 01 Jul 2010 21:43:40 -0000 Subject: [Bug 600780] Re: Login function needed in rest-client References: <20100701193347.18635.22304.malonedeb@wampee.canonical.com> Message-ID: <20100701214340.6052.902.malone@potassium.ubuntu.com> Hm, you might be right... I was just worried about security when sending the password between the rest-client and the server. Making it configurable would also be nice for debugging. -- Login function needed in rest-client https://bugs.launchpad.net/bugs/600780 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From anna.granudd at gmail.com Fri Jul 2 11:16:44 2010 From: anna.granudd at gmail.com (Anna) Date: Fri, 02 Jul 2010 09:16:44 -0000 Subject: [Bug 600962] [NEW] Rest getter and setter functions needed in MM3 References: <20100702091644.16079.9063.malonedeb@soybean.canonical.com> Message-ID: <20100702091644.16079.9063.malonedeb@soybean.canonical.com> Public bug reported: Below I'll list some functions we need implemented in the rest server to be able to implement them in the rest-client and use them for the UI. I don't think any of these are implemented yet but we'll need them. * A "getter" and a "setter" function for the user settings, i.e. a function returning the values the user had set for a particular mailing list and a function setting the new values the user has changed on the settings page for a mailing list. * A "getter" and a "setter" function for the admin settings for each list. Since there are many settings possible for each list, we may want to divide these into groups and create a getter and setter for each group, but I'm not sure about this. Maybe it's possible to make something generic just changing the values the user has changed making the grouping unnecessary, I really don't know. I just brought it up for consideration. I'll leave the functions necessary for the archives so far but likely we'll later need functions returning old emails grouped according to threads, dates etc. like old Mailman has. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest-api -- Rest getter and setter functions needed in MM3 https://bugs.launchpad.net/bugs/600962 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From bwigoder at gmail.com Sat Jul 3 19:04:52 2010 From: bwigoder at gmail.com (benwiggy) Date: Sat, 03 Jul 2010 17:04:52 -0000 Subject: [Bug 601419] [NEW] Adjust default list configuration on shared servers References: <20100703170452.16337.24899.malonedeb@soybean.canonical.com> Message-ID: <20100703170452.16337.24899.malonedeb@soybean.canonical.com> Public bug reported: On shared servers, if you are managing tens or hundreds of lists, it can be very time consuming to manually adjust the settings for each new list, to the configuration you like. For example, we have to change 20 settings to get each list to behave as we like. It should be possible to set a default configuration in mailman (for individual shared hosting accounts). One way which could work quite well is if you could make a list "mailman_default_configuration at domain.com" - and when mailman makes a new list, if that default configuration list exists, it copies the settings from that. Or perhaps there are other ways which would work better.. Thanks, Ben ** Affects: mailman Importance: Undecided Status: New -- Adjust default list configuration on shared servers https://bugs.launchpad.net/bugs/601419 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From bwigoder at gmail.com Sat Jul 3 19:11:45 2010 From: bwigoder at gmail.com (benwiggy) Date: Sat, 03 Jul 2010 17:11:45 -0000 Subject: [Bug 601419] Re: Adjust default list configuration on shared servers References: <20100703170452.16337.24899.malonedeb@soybean.canonical.com> Message-ID: <20100703171146.24259.12093.launchpad@palladium.canonical.com> ** Description changed: -- Adjust default list configuration on shared servers https://bugs.launchpad.net/bugs/601419 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jul 3 19:33:59 2010 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 03 Jul 2010 17:33:59 -0000 Subject: [Bug 601419] Re: Adjust default list configuration on shared servers References: <20100703170452.16337.24899.malonedeb@soybean.canonical.com> Message-ID: <20100703173359.15537.3378.malone@gandwana.canonical.com> For Mailman 2.1 you can do something like bin/config_list -o default_config at domain appropriately_configured_list and then edit that to remove list specific settings such as for example real_name, owner, moderator, description, info and subject_prefix. Or, just put your 20 settings in that file. Then after creating a new list, run bin/config_list -i default_config at domain new_list You might be able to modify your list creation process to do this automatically. I realize this is not a complete satisfaction of your request, but nothing more automatic will be added in Mailman 2.1 Mailman 3 will support multiple templates for creating lists. -- Adjust default list configuration on shared servers https://bugs.launchpad.net/bugs/601419 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jul 3 23:03:41 2010 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 03 Jul 2010 21:03:41 -0000 Subject: [Bug 266824] Re: Add option to remove Sender header References: <20080905194257.1806.1335.launchpad@forster.canonical.com> Message-ID: <20100703210342.18577.39908.launchpad@wampee.canonical.com> ** Also affects: mailman/2.1 Importance: Undecided Status: New ** Changed in: mailman/2.1 Importance: Undecided => Medium ** Changed in: mailman/2.1 Status: New => Fix Committed ** Changed in: mailman/2.1 Milestone: None => 2.1.14 ** Changed in: mailman/2.1 Assignee: (unassigned) => Mark Sapiro (msapiro) -- Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From bwigoder at gmail.com Sat Jul 3 23:56:42 2010 From: bwigoder at gmail.com (benwiggy) Date: Sat, 03 Jul 2010 21:56:42 -0000 Subject: [Bug 601419] Re: Adjust default list configuration on shared servers References: <20100703170452.16337.24899.malonedeb@soybean.canonical.com> Message-ID: <20100703215642.24259.7013.malone@palladium.canonical.com> Thanks, but not any good without root access (Can't access 'bin'...) -- Adjust default list configuration on shared servers https://bugs.launchpad.net/bugs/601419 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From anna.granudd at gmail.com Mon Jul 5 15:07:28 2010 From: anna.granudd at gmail.com (Anna) Date: Mon, 05 Jul 2010 13:07:28 -0000 Subject: [Bug 601899] [NEW] Delete list function in rest-server References: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Message-ID: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Public bug reported: A function to delete a list is needed in the rest-server (which I believe is necessary to be able to implement it in the rest-client). ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest-api -- Delete list function in rest-server https://bugs.launchpad.net/bugs/601899 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From tkikuchi at is.kochi-u.ac.jp Tue Jul 6 06:24:29 2010 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 06 Jul 2010 04:24:29 -0000 Subject: [Merge] lp:~tkikuchi/mailman/2.1-ja into lp:mailman/2.1 Message-ID: <20100706042429.6910.70362.launchpad@loganberry.canonical.com> Tokio Kikuchi has proposed merging lp:~tkikuchi/mailman/2.1-ja into lp:mailman/2.1. Requested reviews: Mailman Coders (mailman-coders) Japanese translation update for 2.1.14 -- https://code.launchpad.net/~tkikuchi/mailman/2.1-ja/+merge/29251 Your team Mailman Coders is requested to review the proposed merge of lp:~tkikuchi/mailman/2.1-ja into lp:mailman/2.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 2553 bytes Desc: not available URL: From 601899 at bugs.launchpad.net Wed Jul 7 03:01:30 2010 From: 601899 at bugs.launchpad.net (Barry Warsaw) Date: Wed, 07 Jul 2010 01:01:30 -0000 Subject: [Bug 601899] Re: Delete list function in rest-server References: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Message-ID: <20100707010130.29004.420.launchpad@soybean.canonical.com> ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Milestone: None => 3.0.0a6 ** Changed in: mailman Status: New => In Progress -- Delete list function in rest-server https://bugs.launchpad.net/bugs/601899 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 601899 at bugs.launchpad.net Wed Jul 7 04:44:02 2010 From: 601899 at bugs.launchpad.net (Barry Warsaw) Date: Wed, 07 Jul 2010 02:44:02 -0000 Subject: [Bug 601899] Re: Delete list function in rest-server References: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Message-ID: <20100707024402.10010.52835.malone@gandwana.canonical.com> I have a branch for this which I'll merge momentarily. You'll be able to delete a list via the REST API, but not yet the archives for the list. I'm not quite sure what the right interfaces is for deleting a list's archives. -- Delete list function in rest-server https://bugs.launchpad.net/bugs/601899 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 601899 at bugs.launchpad.net Wed Jul 7 04:43:19 2010 From: 601899 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Wed, 07 Jul 2010 02:43:19 -0000 Subject: [Bug 601899] Re: Delete list function in rest-server References: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Message-ID: <20100707024332.25414.37583.launchpad@loganberry.canonical.com> ** Branch linked: lp:~barry/mailman/601899-deletelist -- Delete list function in rest-server https://bugs.launchpad.net/bugs/601899 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 601899 at bugs.launchpad.net Wed Jul 7 04:58:06 2010 From: 601899 at bugs.launchpad.net (Barry Warsaw) Date: Wed, 07 Jul 2010 02:58:06 -0000 Subject: [Bug 601899] Re: Delete list function in rest-server References: <20100705130728.16337.77219.malonedeb@soybean.canonical.com> Message-ID: <20100707025807.28022.6917.launchpad@palladium.canonical.com> ** Changed in: mailman Status: In Progress => Fix Committed -- Delete list function in rest-server https://bugs.launchpad.net/bugs/601899 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From flo.fuchs at gmail.com Wed Jul 7 09:45:49 2010 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Wed, 07 Jul 2010 07:45:49 -0000 Subject: [Merge] lp:~flo-fuchs/mailman/restclient into lp:mailman In-Reply-To: <20100625165042.6066.5358.launchpad@loganberry.canonical.com> Message-ID: <20100707074509.22180.41144.codereview@wampee.canonical.com> First of all: Thanks a lot for that extensive review - I really, really appreciate getting this kind of detailed comment! Exceptions ========== MailmanRESTClientError is only used for email- and domain-validation. Apart from that the original Exceptions don't get catched any more. If there are no mailing lists yet, an empty list is returned instead of an Exception. Proxy Objects ============= > What do you think about having proxy objects for Domains, Lists, etc.? > Launchpadlib works like this and it provides more of a natural, object > oriented API to clients, rather than an XMLRPC style seen here. Great idea! I've added two sub-classes two return as List and Domain objects like: domain = client.get_domain('example.com') list = domain.create_list('test') and so on... No user object yet: What do you think: Are we talking about a User with n email addresses and n memberships here or more like User = Membership? Generally I'd say "get_singularterm" and "create_singularterm" (get_list(), create_domain() etc.) should return an object with helpful methods and "get_pluralterm"/"create_pluralterm" (get_lists, get_members) should return lists oder dicts... Style issues ============ I've fixed all the issues according to the style guide and pep8. At least I hope so... Lesson learned... ;-) Func name issue =============== > I'm not sure 'reading' a list is the right phrase here. "Reading" a list > implies to me reading its archive. Maybe .get_list() here? I was thinking in CRUD terms where I understand "reading" more like getting a db record. But I agree, it's a little strange here. So I changed it to get_list(). List order ========== > This is why I added the dump_json() helper in > src/mailman/tests/test_documentation.py. That helper isn't entirely > appropriate for your tests because you don't explicitly pass in a url; that's > basically embedded in .get_lists and the client. But there's enough > commonality that dump_json() should be refactored into something that can be > shared. I'm not sure if a func name like dump_json is a little confusing in that context since the client doesn't return any json. Maybe we could rename the function into dump_rest_output() (or similar) and make url, method optional? So if url is set, the rest server is called; if not, only data is sorted. `data` would then either server as a parm for POST/PUT content or as a dict to sort... For now I've added the sort logic to the test (only a couple of lines). So, thanks again for reviewing. On to the next round...? :-) Florian -- https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 Your team Mailman Coders is requested to review the proposed merge of lp:~flo-fuchs/mailman/restclient into lp:mailman. From 600962 at bugs.launchpad.net Thu Jul 8 15:53:08 2010 From: 600962 at bugs.launchpad.net (Barry Warsaw) Date: Thu, 08 Jul 2010 13:53:08 -0000 Subject: [Bug 600962] Re: Rest getter and setter functions needed in MM3 References: <20100702091644.16079.9063.malonedeb@soybean.canonical.com> Message-ID: <20100708135308.16752.41898.malone@soybean.canonical.com> I've been thinking about this one. Perhaps we shouldn't have getters and setters for each individual attribute. I think the right way to do this is to use PATCH and PUT to make modifications to user and mailing list resources. IOW, you'll do a GET to access the current state of the mailing list, then a PATCH (for partial update) or a PUT (for full update) of that resource. Of course the server side will impose any restrictions or sanity checks. This should be fairly easy to do, so I'll work on this one next. ** Changed in: mailman Milestone: None => 3.0.0a6 ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Status: New => Confirmed -- Rest getter and setter functions needed in MM3 https://bugs.launchpad.net/bugs/600962 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 265403 at bugs.launchpad.net Fri Jul 9 06:42:26 2010 From: 265403 at bugs.launchpad.net (Barry Warsaw) Date: Fri, 09 Jul 2010 04:42:26 -0000 Subject: [Bug 265403] Re: missing facility to recover list admin passwords References: <20080905192121.27052.7911.launchpad@forster.canonical.com> Message-ID: <20100709044226.21169.96348.malone@potassium.ubuntu.com> This is really no longer relevant in a Mailman 3 world. -- missing facility to recover list admin passwords https://bugs.launchpad.net/bugs/265403 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Fri Jul 16 16:43:39 2010 From: barry at canonical.com (Barry Warsaw) Date: Fri, 16 Jul 2010 14:43:39 -0000 Subject: [Merge] lp:~flo-fuchs/mailman/restclient into lp:mailman In-Reply-To: <20100625165042.6066.5358.launchpad@loganberry.canonical.com> Message-ID: <20100716144234.29631.43428.codereview@soybean.canonical.com> Review: Needs Fixing Thanks for all the great updates. Things look pretty good, and I have only a few minor issues to comment on. I think we're almost ready to merge it! Great work. On the dump_json() issue, i just thought of something: since you're only displaying dictionaries, perhaps pprint will do the trick. In Python 2.6, pprint.pprint() sorts the dictionary elements I believe. >>> import os >>> from pprint import pprint >>> pprint(dict(os.environ)) {'COLUMNS': '79', ... 'DISPLAY': ':0.0', 'EMACS': 't', ... You asked: >No user object yet: What do you think: Are we talking about a User with n >email addresses and n memberships here or more like User = Membership? I think we should stick fairly close to the internal model here. So 'Users' represent people, 'Addresses' represent their email addresses, which are usually associated with a user, and 'Member' joins an address to a mailing list with a given role. Only indirectly can you get at the user for a member (i.e. through its address). I agree about singular/plural terms. -B === added file 'src/mailman/rest/docs/restclient.txt' --- src/mailman/rest/docs/restclient.txt 1970-01-01 00:00:00 +0000 +++ src/mailman/rest/docs/restclient.txt 2010-07-15 14:02:55 +0000 > @@ -0,0 +1,129 @@ > +=================== > +Mailman REST Client > +=================== > + > + # The test framework starts out with an example domain, so let's delete > + # that first. > + >>> from mailman.interfaces.domain import IDomainManager > + >>> from zope.component import getUtility > + >>> domain_manager = getUtility(IDomainManager) > + > + >>> domain_manager.remove('example.com') > + > + >>> transaction.commit() > + > +First let's get an instance of MailmanRESTClient. > + > + >>> from mailmanclient.rest import MailmanRESTClient, MailmanRESTClientError > + >>> client = MailmanRESTClient('localhost:8001') > + > +So far there are no lists. > + > + >>> lists = client.get_lists() > + >>> print lists > + [] I think you can just do >>> client.get_lists() [] > + > + > +Domains > +======= > + > +In order to add new lists first a new domain has to be added. > + > + >>> new_domain = client.create_domain('example.com') > + >>> new_domaininfo = new_domain.get_domaininfo() > + >>> for key in sorted(new_domaininfo): > + ... print '{0}: {1}'.format(key, new_domaininfo[key]) > + base_url: http://example.com > + ... > + > +Later the domain object can be instanciated using get_domain() > + > + >>> my_domain = client.get_domain('example.com') > + > + > +Mailing lists > +============= > + > +Now let's add some mailing lists. > + > + >>> new_list = my_domain.create_list('test-one') > + > +Lets add another list and get some information on the list. s/Lets/let's/ > + > + >>> another_list = my_domain.create_list('test-two') > + >>> another_listinfo = another_list.get_listinfo() > + >>> for key in sorted(another_listinfo): > + ... print '{0}: {1}'.format(key, another_listinfo[key]) > + fqdn_listname: test-two at example.com > + ... > + > +Later the new list can be instanciated using get_list(): s/instanciated/instantiated/ > + > + >>> some_list = client.get_list('test-one at example.com') > + > +The lists have been added and get_lists() returns a list of dicts, sorted > +by fqdn_listname. > + > + >>> lists = client.get_lists() > + >>> for i, list in enumerate(lists): > + ... print 'entry %d:' % i > + ... for key in sorted(list): > + ... print ' {0}: {1}'.format(key, list[key]) > + entry 0: > + fqdn_listname: test-one at example.com > + ... > + entry 1: > + fqdn_listname: test-two at example.com > + ... > + > + > +Membership > +========== > + > +Since we now have a list we should add some members to it (.subscribe() > +returns an HTTP status code, ideally 201) > + > + >>> new_list.subscribe('jack at example.com', 'Jack') > + 201 > + >>> new_list.subscribe('meg at example.com', 'Meg') > + 201 > + >>> another_list.subscribe('jack at example.com', 'Jack') > + 201 > + > +We can get a list of all members: > + > + >>> members = client.get_members() > + >>> for i, member in enumerate(members): > + ... print 'entry %d:' % i > + ... for key in sorted(member): > + ... print ' {0}: {1}'.format(key, member[key]) The other thing to think about is, if you repeat similar code in the doctest, you can always refactor them into a function defined in the doctest. > + entry 0: > + ... > + self_link: http://localhost:8001/3.0/lists/test-one at example.com/member/jack at example.com > + entry 1: > + ... > + self_link: http://localhost:8001/3.0/lists/test-one at example.com/member/meg at example.com > + entry 2: > + ... > + self_link: http://localhost:8001/3.0/lists/test-two at example.com/member/jack at example.com The client is returning json here, right? > + > +Or just the members of a specific list: > + > + >>> new_list_members = new_list.get_members() > + >>> for i, member in enumerate(new_list_members): > + ... print 'entry %d:' % i > + ... for key in sorted(member): > + ... print ' {0}: {1}'.format(key, member[key]) > + entry 0: > + http_etag: ... > + self_link: http://localhost:8001/3.0/lists/test-one at example.com/member/jack at example.com > + entry 1: > + http_etag: ... > + self_link: http://localhost:8001/3.0/lists/test-one at example.com/member/meg at example.com > + > +After a while Meg decides to unsubscribe from the mailing list (like > +.subscribe() .unsubscribe() returns an HTTP status code, ideally 200). > + > + >>> new_list.unsubscribe('meg at example.com') > + 200 > + === added directory 'src/mailmanclient' === added file 'src/mailmanclient/__init__.py' === added file 'src/mailmanclient/rest.py' --- src/mailmanclient/rest.py 1970-01-01 00:00:00 +0000 +++ src/mailmanclient/rest.py 2010-07-15 14:02:55 +0000 > @@ -0,0 +1,321 @@ > +# Copyright (C) 2010 by the Free Software Foundation, Inc. > +# > +# This file is part of GNU Mailman. > +# > +# GNU Mailman is free software: you can redistribute it and/or modify it under > +# the terms of the GNU General Public License as published by the Free > +# Software Foundation, either version 3 of the License, or (at your option) > +# any later version. > +# > +# GNU Mailman is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > +# more details. > +# > +# You should have received a copy of the GNU General Public License along with > +# GNU Mailman. If not, see . > + > +"""A client library for the Mailman REST API.""" > + > + > +from __future__ import absolute_import, unicode_literals > + > +__metaclass__ = type > +__all__ = [ > + 'MailmanRESTClient', > + 'MailmanRESTClientError', > + ] > + > + > +import json > +import re Believe it or not, these lines should be reversed. I know it's weird but non from-import-* imports get sorted in increasing length. Just a little quirk I inherited from Guido. :) import re import json > + > +from httplib import HTTPConnection, HTTPException > +from urllib import urlencode Should we be using httplib2 and urllib2 here? See the implementation of dump_json(). > + > + > +class MailmanRESTClientError(Exception): > + """An exception thrown by the Mailman REST API client.""" > + You don't need that extra blank line. Strictly speaking, you don't need the following 'pass' line either! > + pass > + > + > +class MailmanRESTClient(object): The base class isn't necessary here, because the '__metaclass__ = type' at the top of the module already makes all unadorned classes default to new style. > + """A wrapper for the Mailman REST API.""" > + > + def __init__(self, host): > + """Connect to host First line should end in a period, and there should be a blank line following. Also, I try to make :param: descriptions full sentences too (capitalized and ending in a period). Not the :type: description though. Apply these rules to all the following docstrings. > + :param host: the host name of the REST API > + :type host: string > + """ > + self.host = host > + # If there is a trailing slash remove it > + if self.host[-1] == '/': > + self.host = self.host[:-1] > + # Include general header information > + self.headers = { > + 'User-Agent': 'MailmanRESTClient', > + 'Accept': 'text/plain', > + } > + self.c = HTTPConnection(self.host) Abbreviations == bad! :) Well, usually. ;) You can use self.connection or self.conn here to make it a little more readable. OTOH, in dump_json(), we create a new HTTP() instance for every request. I wonder if that wouldn't be a better way to go. IOW, what's the advantage of caching this HTTPConnection instance in this attribute? > + > + def __repr__(self): > + return '' % self.host > + > + def _get_request(self, path): > + """Send an HTTP GET request. > + > + :param path: the URL to send the GET request to > + :type path: string > + :rtype: list Add an :return: to describe what gets returned. > + """ > + try: > + self.c.request('GET', path, None, self.headers) > + r = self.c.getresponse() > + raw_data = r.read() > + data = json.loads(raw_data) > + return data > + finally: > + self.c.close() > + > + def _post_request(self, path, data): > + """Send an HTTP POST request. > + > + :param path: the URL to send POST request to > + :type path: string > + :param data: the post data to send > + :type data: dict > + :return: request status code > + :rtype: string > + """ > + self.headers['Content-type'] = "application/x-www-form-urlencoded" > + try: > + self.c.request('POST', path, urlencode(data), self.headers) > + r = self.c.getresponse() > + return r.status > + finally: > + self.c.close() > + > + def _delete_request(self, path): > + """Send an HTTP DELETE request. > + > + :param path: the URL to send the DELETE request to > + :type path: string > + :return: request status code > + :rtype: string > + """ > + try: > + self.c.request('DELETE', path, None, self.headers) > + r = self.c.getresponse() > + return r.status > + finally: > + self.c.close() I wonder if this duplication can be refactored? > + > + def _put_request(self, path, data): > + """Send an HTTP PUT request. > + > + :param path: the URL to send the PUT request to > + :type path: string > + :param data: the put data to send > + :type data: dict > + :return: request status code > + :rtype: string > + """ > + self.headers['Content-type'] = "application/x-www-form-urlencoded" > + try: > + self.c.request('PUT', path, urlencode(data), self.headers) > + r = self.c.getresponse() > + return r.status > + finally: > + self.c.close() > + > + def _validate_email_host(self, email_host): > + """Validates a domain name. > + > + :param email_host: the domain str to validate > + :type email_host: string > + """ > + pat = re.compile('^[-a-z0-9\.]+\.[-a-z]{2,4}$', re.IGNORECASE) > + if not pat.match(email_host): > + raise MailmanRESTClientError('%s is not a valid domain name' % email_host) Won't the Mailman core refuse to create a domain if it's not valid? It might still be worth doing client-side validation, but I would expect that more in some webui JavaScript. What's the advantage of doing this extra check (which might be different than what happens in the core)? > + > + def _validate_email_address(self, email_address): > + """Validates an email address. > + > + :param email_address: the email string to validate > + :type email_address: string > + """ > + pat = re.compile('^[-a-z0-9_.]+@[-a-z0-9\.]+\.[a-z]{2,6}$',re.IGNORECASE) > + if not pat.match(email_address): > + raise MailmanRESTClientError('%s is not a valid email_address' % email_address) Same question here. > + > + def create_domain(self, email_host): > + """Create a domain and return a domain object. > + > + :param email_host: host domain to create > + :type email_host: string > + :rtype object > + """ > + self._validate_email_host(email_host) > + data = { > + 'email_host': email_host, > + } > + r = self._post_request('/3.0/domains', data) > + return _Domain(self.host, email_host) Better to use 'response' rather than 'r'. > + > + def get_domain(self, email_host): > + """Return a domain object. > + > + :param email_host: host domain > + :type email_host: string > + :rtype object > + """ > + self._validate_email_host(email_host) > + return _Domain(self.host, email_host) > + > + def get_lists(self): > + """Get a list of all mailing list. > + > + :return: a list of dicts with all mailing lists > + :rtype: list > + """ > + r = self._get_request('/3.0/lists') > + if 'entries' not in r: > + return [] > + else: > + # Return a dict with entries sorted by fqdn_listname > + return sorted(r['entries'], > + key=lambda list: list['fqdn_listname']) lambdas are kind of icky, how about: # Move this to the imports at the top of the file. from operator import itemgetter return sorted(response['entries'], key=itemgetter('fqdn_listname')) > + > + def get_list(self, fqdn_listname): > + """Find and return a list object. > + > + :param fqdn_listname: the mailing list address > + :type fqdn_listname: string > + :rtype: object > + """ > + self._validate_email_address(fqdn_listname) > + return _List(self.host, fqdn_listname) > + > + def get_members(self): > + """Get a list of all list members. > + > + :return: a list of dicts with the members of all lists > + :rtype: list > + """ > + r = self._get_request('/3.0/members') > + if 'entries' not in r: > + return [] > + else: > + return sorted(r['entries'], > + key=lambda member: member['self_link']) See above. > + > + > +class _Domain(MailmanRESTClient): > + """A domain wrapper for the MailmanRESTClient.""" > + > + def __init__(self, host, email_host): > + """Connect to host and get list information. > + > + :param host: the host name of the REST API > + :type host: string > + :param email_host: host domain > + :type email_host: string > + :rtype: object > + """ > + MailmanRESTClient.__init__(self, host) For new-style classes: super(_Domain, self).__init__(host) > + self.domain_info = self._get_request('/3.0/domains/' + email_host) > + > + def get_domaininfo(self): > + """Get information about the domain. > + > + :rtype: dict > + """ > + return self.domain_info I wonder if this method is necessary. In general, attributes are preferred over accessors, and you've already got a public one right here! So clients can do: >>> my_domain = client.get_domain('example.com') >>> my_domain.domain_info ... directly. In fact, for polymorphism, maybe the attribute should just be called 'info'? > + > + def create_list(self, list_name): > + """Create a mailing list and return a list object. > + > + :param list_name: the name of the list to be created > + :type list_name: string > + :rtype: object > + """ > + fqdn_listname = list_name + '@' + self.domain_info['email_host'] > + self._validate_email_address(fqdn_listname) > + data = { > + 'fqdn_listname': fqdn_listname > + } > + r = self._post_request('/3.0/lists', data) > + return _List(self.host, fqdn_listname) > + > + def delete_list(self, list_name): > + return self._delete_request('/3.0/lists/' + fqdn_listname) > + > + > +class _List(MailmanRESTClient): > + """A mailing list wrapper for the MailmanRESTClient.""" > + > + def __init__(self, host, fqdn_listname): > + """Connect to host and get list information. > + > + :param host: the host name of the REST API > + :type host: string > + :param fqdn_listname: the mailing list address > + :type fqdn_listname: string > + :rtype: object > + """ > + MailmanRESTClient.__init__(self, host) > + self.list_info = self._get_request('/3.0/lists/' + fqdn_listname) > + > + def get_listinfo(self): > + """Get information about the list. > + > + :rtype: dict > + """ > + return self.list_info > + > + def subscribe(self, address, real_name=None): > + """Add an address to a list. > + > + :param address: email address to add to the list. > + :type address: string > + :param real_name: the real name of the new member > + :type real_name: string > + """ > + self._validate_email_address(address) > + data = { > + 'fqdn_listname': self.list_info['fqdn_listname'], > + 'address': address, > + 'real_name': real_name > + } > + return self._post_request('/3.0/members', data) > + > + def unsubscribe(self, address): > + """Unsubscribe an address to a list. > + > + :param address: email address to add to the list. > + :type address: string > + :param real_name: the real name of the new member > + :type real_name: string > + """ > + self._validate_email_address(address) > + return self._delete_request('/3.0/lists/' + > + self.list_info['fqdn_listname'] + > + '/member/' + > + address) > + > + def get_members(self): > + """Get a list of all list members. > + > + :return: a list of dicts with all members > + :rtype: list > + """ > + r = self._get_request('/3.0/lists/' + > + self.list_info['fqdn_listname'] + > + '/roster/members') > + if 'entries' not in r: > + return [] > + else: > + return sorted(r['entries'], > + key=lambda member: member['self_link']) > + -- https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 Your team Mailman Coders is requested to review the proposed merge of lp:~flo-fuchs/mailman/restclient into lp:mailman. From 610364 at bugs.launchpad.net Tue Jul 27 10:22:50 2010 From: 610364 at bugs.launchpad.net (David Shrimpton) Date: Tue, 27 Jul 2010 08:22:50 -0000 Subject: [Bug 610364] [NEW] fix_url won't save list as no Lock References: <20100727082250.27112.10100.malonedeb@wampee.canonical.com> Message-ID: <20100727082250.27112.10100.malonedeb@wampee.canonical.com> Public bug reported: In mailman 2.1.13 and 2.1.11 using python 2.52 on a linux host bin/withlist -r fix_url listname -u url fails with Mailman.LockFile.NotLockedError eg bin/withlist -r fix_url listname -u url Importing fix_url... Running fix_url.fix_url()... Loading list test (unlocked) Setting web_page_url to: URL Setting host_name to: HOSTNAME Saving list Traceback (most recent call last): File "bin/withlist", line 299, in main() File "bin/withlist", line 277, in main r = do_list(listname, args, func) File "bin/withlist", line 202, in do_list return func(m, *args) File "/opt/mailman/bin/fix_url.py", line 86, in fix_url mlist.Save() File "/opt/mailman/Mailman/MailList.py", line 559, in Save self.__lock.refresh() File "/opt/mailman/Mailman/LockFile.py", line 229, in refresh raise NotLockedError, '%s: %s' % (repr(self), self.__read()) Mailman.LockFile.NotLockedError: : None Finalizing Fix is *** bin/fix_url.py.orig 2010-05-30 16:12:06.000000000 +1000 --- bin/fix_url.py 2010-07-27 18:19:04.000000000 +1000 *************** *** 83,88 **** --- 83,89 ---- print _('Setting host_name to: %(mailhost)s') mlist.host_name = mailhost print _('Saving list') + mlist.Lock() mlist.Save() mlist.Unlock() ** Affects: mailman Importance: Undecided Status: New -- fix_url won't save list as no Lock https://bugs.launchpad.net/bugs/610364 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Tue Jul 27 15:51:43 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Tue, 27 Jul 2010 13:51:43 -0000 Subject: [Bug 610454] [NEW] Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Public bug reported: i have install Zimbra open source 6.0.7 and integrate mailman version 2.1.7, after complete installation of mailman when i acess my link i get this error, Bug in Mailman version 2.1.7 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. ** Affects: mailman Importance: Undecided Status: New -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jul 27 15:54:54 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 27 Jul 2010 13:54:54 -0000 Subject: [Bug 610364] Re: fix_url won't save list as no Lock References: <20100727082250.27112.10100.malonedeb@wampee.canonical.com> Message-ID: <20100727135454.26475.67361.malone@wampee.canonical.com> Your suggested fix has two serious problems: 1) Locking the list reloads it as a side effect. Thus, locking after making changes to your instance of the list object will undo those changes. 2) The documentation of fix_url states that it should be run via % bin/withlist -l -r fix_url listname [options] Thus, if it is run as documented (with the -l option to withlist), it will throw an AlreadyLockedError exception when it attempts to lock the already locked list. While this isn't really a bug since fix_url is documented to be run via withlist -l, a patch to "fix" it properly is attached ** Attachment added: "Patch to fix_url to lock an unlocked list." http://launchpadlibrarian.net/52587192/patch -- fix_url won't save list as no Lock https://bugs.launchpad.net/bugs/610364 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jul 27 16:43:02 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 27 Jul 2010 14:43:02 -0000 Subject: [Bug 610364] Re: fix_url won't save list as no Lock References: <20100727082250.27112.10100.malonedeb@wampee.canonical.com> Message-ID: <20100727144303.2318.21555.launchpad@soybean.canonical.com> ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- fix_url won't save list as no Lock https://bugs.launchpad.net/bugs/610364 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jul 27 16:52:02 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 27 Jul 2010 14:52:02 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100727145202.21503.98808.malone@gandwana.canonical.com> Without the traceback from Mailman's error log, there's no way we can begin to diagnose or fix this. Please find the full error report including traceback in Mailman's error log and attach it to this report. -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jul 27 18:41:34 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 27 Jul 2010 16:41:34 -0000 Subject: [Bug 266874] Re: Option to NOT confirm unsubscribe References: <20080905194314.1806.76289.launchpad@forster.canonical.com> Message-ID: <20100727164137.2318.6824.launchpad@soybean.canonical.com> *** This bug is a duplicate of bug 266806 *** https://bugs.launchpad.net/bugs/266806 ** This bug has been marked a duplicate of bug 266806 unsubscribe removal confirmation should be optional -- Option to NOT confirm unsubscribe https://bugs.launchpad.net/bugs/266874 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jul 27 19:05:00 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 27 Jul 2010 17:05:00 -0000 Subject: [Bug 610527] [NEW] Unsubscribe confirmation from options login page should include IP address. References: <20100727170501.10666.8672.malonedeb@soybean.canonical.com> Message-ID: <20100727170501.10666.8672.malonedeb@soybean.canonical.com> Public bug reported: The confirmation request email for an unsubscribe request from the member options login page should include the IP address of the requester. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Fix Committed -- Unsubscribe confirmation from options login page should include IP address. https://bugs.launchpad.net/bugs/610527 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Wed Jul 28 10:04:40 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Wed, 28 Jul 2010 08:04:40 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> <20100727145202.21503.98808.malone@gandwana.canonical.com> Message-ID: Dear Mark, Error Log is [root at mailserver cron]# tail -200000 /var/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman [root at mailserver cron]# tail -20000000 /var/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman [root at mailserver cron]# /etc/init.d/mailman restart PID unreadable in: /usr/local/mailman/data/master-qrunner.pid [Errno 2] No such file or directory: '/usr/local/mailman/data/master-qrunner.pid' Is qrunner even running? [root at mailserver cron]# tail -f /var/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman On Tue, Jul 27, 2010 at 7:52 PM, Mark Sapiro wrote: > Without the traceback from Mailman's error log, there's no way we can > begin to diagnose or fix this. Please find the full error report > including traceback in Mailman's error log and attach it to this report. > > -- > Bug in Mailman version 2.1.7 > https://bugs.launchpad.net/bugs/610454 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in GNU Mailman: New > > Bug description: > i have install Zimbra open source 6.0.7 and integrate mailman version > 2.1.7, after complete installation of mailman when i acess my link i get > this error, > > Bug in Mailman version 2.1.7 > > We're sorry, we hit a bug! > > Please inform the webmaster for this site of this problem. Printing of > traceback and other system information has been explicitly inhibited, but > the webmaster can find this information in the Mailman error logs. > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/mailman/+bug/610454/+subscribe > -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Wed Jul 28 10:08:04 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Wed, 28 Jul 2010 08:08:04 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100728080804.27112.65772.malone@wampee.canonical.com> Dear Mark, i check the log and restart mailman service i got this error. [root at mailserver cron]# tail -200000 /var/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman [root at mailserver cron]# tail -20000000 /var/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman [root at mailserver cron]# /etc/init.d/mailman restart PID unreadable in: /usr/local/mailman/data/master-qrunner.pid [Errno 2] No such file or directory: '/usr/local/mailman/data/master-qrunner.pid' Is qrunner even running? [root at mailserver cron]# tail -f /v ar/log/mailman/error Jul 28 12:14:14 2010 mailmanctl(3446): Site list is missing: mailman Jul 28 12:14:14 2010 (3446) Site list is missing: mailman Even i remove 2.1.7 and reinstall with 2.1.6 still same error. MTA is postfix -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Wed Jul 28 15:54:10 2010 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 28 Jul 2010 13:54:10 -0000 Subject: [Bug 557750] Re: Mailman should honor X-Approve and X-Approved References: <20100408013036.30054.67600.malonedeb@soybean.canonical.com> Message-ID: <20100728135411.27748.32538.launchpad@wampee.canonical.com> ** Changed in: mailman/2.1 Status: Confirmed => Fix Committed -- Mailman should honor X-Approve and X-Approved https://bugs.launchpad.net/bugs/557750 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From flo.fuchs at gmail.com Wed Jul 28 16:01:05 2010 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Wed, 28 Jul 2010 14:01:05 -0000 Subject: [Merge] lp:~flo-fuchs/mailman/restclient into lp:mailman In-Reply-To: <20100716144234.29631.43428.codereview@soybean.canonical.com> Message-ID: <20100728135956.22698.51592.codereview@palladium.canonical.com> Review: Resubmit I did some fixes and improvements like suggested in the last review... > > + entry 0: > > + ... > > + self_link: http://localhost:8001/3.0/lists/test- > one at example.com/member/jack at example.com > > + entry 1: > > + ... > > + self_link: http://localhost:8001/3.0/lists/test- > one at example.com/member/meg at example.com > > + entry 2: > > + ... > > + self_link: http://localhost:8001/3.0/lists/test- > two at example.com/member/jack at example.com > > The client is returning json here, right? Nope, the client never returns json. Either HTTP status codes or lists/dicts are returned. > Should we be using httplib2 and urllib2 here? See the implementation of > dump_json(). Done. > > + def _delete_request(self, path): > > + """Send an HTTP DELETE request. > > + > > + :param path: the URL to send the DELETE request to > > + :type path: string > > + :return: request status code > > + :rtype: string > > + """ > > + try: > > + self.c.request('DELETE', path, None, self.headers) > > + r = self.c.getresponse() > > + return r.status > > + finally: > > + self.c.close() > > I wonder if this duplication can be refactored? There's only one http request method now. > > + def _validate_email_host(self, email_host): > > + """Validates a domain name. > > + > > + :param email_host: the domain str to validate > > + :type email_host: string > > + """ > > + pat = re.compile('^[-a-z0-9\.]+\.[-a-z]{2,4}$', re.IGNORECASE) > > + if not pat.match(email_host): > > + raise MailmanRESTClientError('%s is not a valid domain name' % > email_host) > > Won't the Mailman core refuse to create a domain if it's not valid? It might > still be worth doing client-side validation, but I would expect that more in > some webui JavaScript. What's the advantage of doing this extra check (which > might be different than what happens in the core)? I didn't know if the core does email validation. Also, the django app does some validation. So I removed it. > I wonder if this method is necessary. In general, attributes are preferred > over accessors, and you've already got a public one right here! So clients > can do: > > >>> my_domain = client.get_domain('example.com') > >>> my_domain.domain_info > ... > > directly. In fact, for polymorphism, maybe the attribute should just be > called 'info'? Done. -- https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 Your team Mailman Coders is requested to review the proposed merge of lp:~flo-fuchs/mailman/restclient into lp:mailman. From mark at msapiro.net Wed Jul 28 16:08:10 2010 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 28 Jul 2010 14:08:10 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100728140810.21453.65973.malone@gandwana.canonical.com> You can't run Mailman until you create the site list named 'mailman'. You can create this list with Mailman's bin/newlist (give the --help option for information), and then you will be able to start Mailman. None of this has anything to do with the "we hit a bug" error. Perhaps the log containing that error has rotated to /var/log/mailman/error.1 or /var/log/mailman/error.2 or ... or perhaps you have more that one Mailman installation and the one accessed by the web interface logs somewhere else. -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From jw+debian at jameswestby.net Wed Jul 28 16:39:43 2010 From: jw+debian at jameswestby.net (James Westby) Date: Wed, 28 Jul 2010 14:39:43 -0000 Subject: [Bug 610893] [NEW] Makefiles in 2.x use unsafe shell construct that can lead to infinite recursion References: <20100728143943.7270.67203.malonedeb@soybean.canonical.com> Message-ID: <20100728143943.7270.67203.malonedeb@soybean.canonical.com> Public bug reported: Hi, I set CDPATH in my zsh shell, and somehow this caused off behaviour in /bin/sh (dash) when building mailman 2.x. It somehow stopped "cd $$d" from working when run from a Mailman makefile. While this was a problem with my environment, the build system's behaviour in the face of it isn't very nice. As the Makefiles use (cd $$d; make) if the cd fails, they run the make anyway, which causes infinite recursion. If this was changed to (cd $$d && make) or (make -C $$d) then this wouldn't happen and you would get an error message, rather than thrashing. Thanks, James ** Affects: mailman Importance: Undecided Status: New -- Makefiles in 2.x use unsafe shell construct that can lead to infinite recursion https://bugs.launchpad.net/bugs/610893 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Thu Jul 29 08:29:25 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Thu, 29 Jul 2010 06:29:25 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100729062925.18641.90931.malone@potassium.ubuntu.com> Dear Mark Sapiro, thanks for your kind response, mailman was created. i already create that on this path. [root at mailserver bin]# pwd /usr/local/mailman/bin ./newlist mailman and also fellow these command. bin/config_list -i data/sitelist.cfg mailman bin/newlist --emailhost=virtual-domain1.com --urlhost= # This is just to make sure that aliases and virtual-mailman files get generated. Until you add a virtual-domain based list, virtual-mailman won't be generated. /usr/local/mailman/bin/genaliases # aliases and virtual-mailman must be owned by mailman. chown mailman:mailman /usr/local/mailman/data/aliases* chown mailman:mailman /usr/local/mailman/data/virtual-mailman* -------------------------------------------------------- second time i have only one log in my var directory, that is error log -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Fri Jul 30 03:28:40 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 30 Jul 2010 01:28:40 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100730012840.27112.63211.malone@wampee.canonical.com> Do you have a problem or not? Can you visit Mailman's web interface without the "We hit a bug" response? If you cannot, and you don't have any message in Mailman's error log, either the log is not where you think it is or there are permissions issues in writing it. Try running Mailman's bin/check_perms. -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Fri Jul 30 09:00:47 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Fri, 30 Jul 2010 07:00:47 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> <20100730012840.27112.63211.malone@wampee.canonical.com> Message-ID: Dear Mark sapiro, i already fixed all permissions and also change permissions, still no effect. second this mailman web page is not accessable. i simply check it. On Fri, Jul 30, 2010 at 6:28 AM, Mark Sapiro wrote: > Do you have a problem or not? > > Can you visit Mailman's web interface without the "We hit a bug" > response? > > If you cannot, and you don't have any message in Mailman's error log, > either the log is not where you think it is or there are permissions > issues in writing it. > > Try running Mailman's bin/check_perms. > > -- > Bug in Mailman version 2.1.7 > https://bugs.launchpad.net/bugs/610454 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in GNU Mailman: New > > Bug description: > i have install Zimbra open source 6.0.7 and integrate mailman version > 2.1.7, after complete installation of mailman when i acess my link i get > this error, > > Bug in Mailman version 2.1.7 > > We're sorry, we hit a bug! > > Please inform the webmaster for this site of this problem. Printing of > traceback and other system information has been explicitly inhibited, but > the webmaster can find this information in the Mailman error logs. > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/mailman/+bug/610454/+subscribe > -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Fri Jul 30 16:39:27 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 30 Jul 2010 14:39:27 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> Message-ID: <20100730143927.22698.88896.malone@palladium.canonical.com> I have marked this report invalid because Mailman 2.1.7 is out of date (current is 2.1.13 and 2.1.14 will be released soon), and because I think your Mailman installation is not done correctly and I am unable to get information from you to determine what might be wrong. In any case, I don't think there is an actual Mailman bug, but if you can provide more information to determine what is actually happening, I will be happy to investigate further. For example, what steps are you following to install Mailman (note that Zimbra would have nothing to do with "we hit a bug" in the web interface)? Why are you installing such an old version? ** Changed in: mailman Status: New => Invalid -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 610454 at bugs.launchpad.net Fri Jul 30 16:47:59 2010 From: 610454 at bugs.launchpad.net (Rashid Rasheed) Date: Fri, 30 Jul 2010 14:47:59 -0000 Subject: [Bug 610454] Re: Bug in Mailman version 2.1.7 References: <20100727135143.2318.78035.malonedeb@soybean.canonical.com> <20100730143927.22698.88896.malone@palladium.canonical.com> Message-ID: Dear Mark Sapiro, thanks for your kindly support, i will check it myself and get any positive result then i will share with you all. again thanks,,,,,,, On Fri, Jul 30, 2010 at 7:39 PM, Mark Sapiro wrote: > I have marked this report invalid because Mailman 2.1.7 is out of date > (current is 2.1.13 and 2.1.14 will be released soon), and because I > think your Mailman installation is not done correctly and I am unable to > get information from you to determine what might be wrong. > > In any case, I don't think there is an actual Mailman bug, but if you > can provide more information to determine what is actually happening, I > will be happy to investigate further. For example, what steps are you > following to install Mailman (note that Zimbra would have nothing to do > with "we hit a bug" in the web interface)? Why are you installing such > an old version? > > ** Changed in: mailman > Status: New => Invalid > > -- > Bug in Mailman version 2.1.7 > https://bugs.launchpad.net/bugs/610454 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in GNU Mailman: Invalid > > Bug description: > i have install Zimbra open source 6.0.7 and integrate mailman version > 2.1.7, after complete installation of mailman when i acess my link i get > this error, > > Bug in Mailman version 2.1.7 > > We're sorry, we hit a bug! > > Please inform the webmaster for this site of this problem. Printing of > traceback and other system information has been explicitly inhibited, but > the webmaster can find this information in the Mailman error logs. > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/mailman/+bug/610454/+subscribe > -- Bug in Mailman version 2.1.7 https://bugs.launchpad.net/bugs/610454 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.