
I'm trying to install mm 3.0.0b1 as per the directions in START.rst. I'm running into a bit of a problem with zc.buildout. in the bootstrap.py script. The script reports:
$ python bootstrap.py Downloading http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg Traceback (most recent call last): File "bootstrap.py", line 254, in <module> ws.require(requirement) File "/tmp/tmp6ebmh9/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 666, in require File "/tmp/tmp6ebmh9/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 565, in resolve pkg_resources.DistributionNotFound: zc.buildout==1.5.2
However;
$ dpkg -l python-zc.buildout Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==================================-==================================-== ii python-zc.buildout 1.5.2-1 system for managing development buildouts
I explicitly installed it! Do I need to update the mm3 package?
Where do I go from here?
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |

Lindsay Haisley writes:
pkg_resources.DistributionNotFound: zc.buildout==1.5.2
Butbutbutbutbut:
ii python-zc.buildout 1.5.2-1 system for managing development buildouts
Hm. I suspect that Debian has installed zc.buildout for a different version of Python. Zope is extremely finicky about that.

FWIW, i found installing within a virtualenv to be a sanity-inducing operation for very similar reasons.
On Thu, Jun 21, 2012 at 8:57 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
-- Jessy http://jessykate.com

On Thu, 2012-06-21 at 15:57 +0900, Stephen J. Turnbull wrote:
Hm. I suspect that Debian has installed zc.buildout for a different version of Python. Zope is extremely finicky about that.
well....,
$ python2.6 Python 2.6.7 (r267:88850, Aug 11 2011, 12:18:09) <---- Version 2.6 [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from zc.buildout import * .... :) <happy>
and.....,
$ python2.7 Python 2.7.2+ (default, Oct 4 2011, 20:06:09) <----- Version 2.7 [GCC 4.6.1] on linux2
from zc.buildout import * .... :) <also happy>
zc.buildout is installed for both py 2.6 and 2.7. Could zope be barfing on the full package version spec, "2.7.2-7ubuntu2"?
Jessy Kate Schingler <jessy@jessykate.com> said:
FWIW, i found installing within a virtualenv to be a sanity-inducing operation for very similar reasons.
What's involved here? The target box for the install is my desktop workstation, Linux Mint (a Ubuntu knock-off) running on a virtual machine; not otherwise an issue. I don't grok "virtualenv", nor zope either, having never really encountered either one. I _do_ know enough about python to offer some possibly productive suggestion and patches to the mm code itself, but I don't know if I have the personal bandwidth to learn a couple of new technologies and debug the install system in order to do this.
Jessy Kate, can you send me an online reference on setting up a proper virtual environment?
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |

On Jun 21, 2012, at 09:25 AM, Lindsay Haisley wrote:
It's really pretty simple. I'm not sure what the default version of Python is for Mint (it's 2.7 for Ubuntu 12.04), but either 2.6 or 2.7 should work fine, and it's a bug if it doesn't. Anyway, your steps should be something along the lines of:
- apt-get install python-virtualenv
- virtualenv /path/to/your/mm3/installation
- source /path/to/your/mm3/installation/bin/activate
- python setup.py install
At this point, you actually don't need to be in your virtualenv (or really for the setup.py install step either) but it can be useful because the bin directory will be put on your $PATH. In any case, what I'd do next is:
- edit /path/to/your/mm3/installation/etc/mailman.cfg
- mailman start
I forget whether mailman start
needs to be passed the -C option, but I think
not.
Jessy Kate, can you send me an online reference on setting up a proper virtual environment?
This would be the perfect thing for a code contribution! Would either your or Jessy like to submit a bug and some improved deployment documentation, either as a branch, patch, or .rst file?
Cheers, -Barry

On Jun 20, 2012, at 05:37 PM, Lindsay Haisley wrote:
I'm trying to install mm 3.0.0b1 as per the directions in START.rst.
START.rst needs to be updated.
In general, buildout is only needed to run the test suite, so I think it's more appropriate for development rather than deployment. In fact, I'd like to get rid of the need for buildout and just go with virtualenv, but the test suite currently depends on the buildout environment, so that's not yet feasible.
For deployments (i.e. you just want to run mm3) it's better to create a
virtualenv and then python setup.py install
into that virtualenv.
I should note that on my Ubuntu development machines, I do not have
python-zc.buildout installed, but instead after running python bootstrap.py
I end up with the zc.buildout-1.5.2-pyX.Y.egg in my eggs directory. So I'm
guessing even though the versions are the same, there's some other
incompatibility between the Debuntu package and the PyPI package, but I don't
know what that might be.
Cheers, -Barry

On Thu, 2012-06-21 at 10:36 -0400, Barry Warsaw wrote:
For deployments (i.e. you just want to run mm3) it's better to create a virtualenv and then
python setup.py install
into that virtualenv.
Barry, I don't know if you followed the discussion on the Users list regarding placing an encrypted (AES) header into personalized, VERPed list posts which would contain the subscriber recipient's address and possibly also the list address. This would satisfy AOL's TOS (others, too) and not be redacted in their Email Feedback Reports.
I have some patches and files to this end, Which I've applied successfully to Mailman 2.1.15 and the suggestion was made on the Users list that I submit them for possible application to mm 3, which would probably be a more appropriate place for this feature.
To do this I need to set up a test installation of mm 3 which actually works, and delivers mail to a test list. I don't need to deploy it for general use.
-- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |

On Jun 21, 2012, at 10:32 AM, Lindsay Haisley wrote:
I've been skimming it, so I think I get the gist.
Agreed. I think *something* like this would be useful for mm3. I'm not sure about the best way to do it, i.e. whether it should be a generally available feature enabled by some config, or whether it should be implemented as a plugin. We could certainly discuss all that here.
Cool. The previous virtualenv instructions should still be relevant. You'd of course need to hook it up to an MTA, but mm3 has a nice "development" mode you can enable, which will ensure that the SMTP RCPT TO header will be forced to a specific address. What this means is that with devmode enabled, you can forge all the RFC 5322 headers you want to make it look like real email, and it'll never escape your local test environment. E.g. if you put the following in your mailman.cfg file:
[devmode] enabled: yes recipient: me@example.com
*All* of the email sent through your mm3 deployment will actually get delivered to me@example.com. There are other ways to do similar things e.g. using Postfix transports, but you may not need them.
To make something like this a supported feature does require more work, e.g. probably a schema change, plumbing through REST, documentation and a test suite. A Launchpad bug and merge proposal will be ideal. But don't let that discourage you. If you can come up with a nice proof-of-concept once of us can help shepherd you through the rest of the process.
Cheers, -Barry

On Thu, 2012-06-21 at 11:43 -0400, Barry Warsaw wrote:
The way I switched it on in 2.1.15 was by way of configuration variable in mm_cfg.py containing a global AES secret key. This can be added to mm_cfg.py by running a key generation script in the runtime mm bin directory. Absent this variable, the feature is moot since all relevant code gets bypassed.
Great!! Something to do with all my FREE TIME <LOL>. I'll probably work on it since I can't seem to leave projects like this alone.
One caveat/issue with the work I've done so far is that it requires the python-crypto module. This is no problem on Linux, possibly not on other Unix-like OSes, but from what I've read, the module has longstanding issues on a Windows platform. This might be a show-stopper.
Thanks for the coaching on setting up virtualenv!
-- Lindsay Haisley |"Friends are like potatoes. FMP Computer Services | If you eat them, they die" 512-259-1190 | http://www.fmp.com | - Aaron Edmund

On Jun 21, 2012, at 11:02 AM, Lindsay Haisley wrote:
So the mm3 equivalent would probably be a new variable in the [mta] section of the mailman.cfg file. Note that the defaults for mailman.cfg live in the src/mailman/config/schema.cfg file, so that's where you'd add this. Note too that these control global system-wide configurations, so if there's any reason why you'd want to have different keys for different mailing lists, it can't go there (but I don't see why that would be so I won't describe the alternative).
Also, of course the key will live in plain text in the deployed mailman.cfg file, but it sounds like that's not a problem.
Nope, Mailman doesn't officially run on Windows. :)
OTOH, I would make this feature conditional on the module being importable, so it won't be required even on *nix systems.
Thanks for the coaching on setting up virtualenv!
No problem, good luck!
Don't forget too, that if you can do IRC and need more real-time feedback, I usually hang out on freenode's #mailman channel during US/Eastern working hours. You need to ping my nick (the always clever and hard to guess 'barry' :) to get my attention though.
-Barry

On Thu, 2012-06-21 at 12:20 -0400, Barry Warsaw wrote:
I gave this some thought and decided that since any automated expunging of subscribers probably should be done at a system level (although theoretically a list admin could script an an automated mail command exchange system, or automate an interaction with a web UI), that a global key would be fine. Perhaps the feature could be turned on or off in individual lists.
Also, of course the key will live in plain text in the deployed mailman.cfg file, but it sounds like that's not a problem.
This isn't for *real* security, just to provide an encryption envelope for information so as to reversibly obfuscate it.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |

Lindsay Haisley writes:
pkg_resources.DistributionNotFound: zc.buildout==1.5.2
Butbutbutbutbut:
ii python-zc.buildout 1.5.2-1 system for managing development buildouts
Hm. I suspect that Debian has installed zc.buildout for a different version of Python. Zope is extremely finicky about that.

FWIW, i found installing within a virtualenv to be a sanity-inducing operation for very similar reasons.
On Thu, Jun 21, 2012 at 8:57 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
-- Jessy http://jessykate.com

On Thu, 2012-06-21 at 15:57 +0900, Stephen J. Turnbull wrote:
Hm. I suspect that Debian has installed zc.buildout for a different version of Python. Zope is extremely finicky about that.
well....,
$ python2.6 Python 2.6.7 (r267:88850, Aug 11 2011, 12:18:09) <---- Version 2.6 [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from zc.buildout import * .... :) <happy>
and.....,
$ python2.7 Python 2.7.2+ (default, Oct 4 2011, 20:06:09) <----- Version 2.7 [GCC 4.6.1] on linux2
from zc.buildout import * .... :) <also happy>
zc.buildout is installed for both py 2.6 and 2.7. Could zope be barfing on the full package version spec, "2.7.2-7ubuntu2"?
Jessy Kate Schingler <jessy@jessykate.com> said:
FWIW, i found installing within a virtualenv to be a sanity-inducing operation for very similar reasons.
What's involved here? The target box for the install is my desktop workstation, Linux Mint (a Ubuntu knock-off) running on a virtual machine; not otherwise an issue. I don't grok "virtualenv", nor zope either, having never really encountered either one. I _do_ know enough about python to offer some possibly productive suggestion and patches to the mm code itself, but I don't know if I have the personal bandwidth to learn a couple of new technologies and debug the install system in order to do this.
Jessy Kate, can you send me an online reference on setting up a proper virtual environment?
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |

On Jun 21, 2012, at 09:25 AM, Lindsay Haisley wrote:
It's really pretty simple. I'm not sure what the default version of Python is for Mint (it's 2.7 for Ubuntu 12.04), but either 2.6 or 2.7 should work fine, and it's a bug if it doesn't. Anyway, your steps should be something along the lines of:
- apt-get install python-virtualenv
- virtualenv /path/to/your/mm3/installation
- source /path/to/your/mm3/installation/bin/activate
- python setup.py install
At this point, you actually don't need to be in your virtualenv (or really for the setup.py install step either) but it can be useful because the bin directory will be put on your $PATH. In any case, what I'd do next is:
- edit /path/to/your/mm3/installation/etc/mailman.cfg
- mailman start
I forget whether mailman start
needs to be passed the -C option, but I think
not.
Jessy Kate, can you send me an online reference on setting up a proper virtual environment?
This would be the perfect thing for a code contribution! Would either your or Jessy like to submit a bug and some improved deployment documentation, either as a branch, patch, or .rst file?
Cheers, -Barry

On Jun 20, 2012, at 05:37 PM, Lindsay Haisley wrote:
I'm trying to install mm 3.0.0b1 as per the directions in START.rst.
START.rst needs to be updated.
In general, buildout is only needed to run the test suite, so I think it's more appropriate for development rather than deployment. In fact, I'd like to get rid of the need for buildout and just go with virtualenv, but the test suite currently depends on the buildout environment, so that's not yet feasible.
For deployments (i.e. you just want to run mm3) it's better to create a
virtualenv and then python setup.py install
into that virtualenv.
I should note that on my Ubuntu development machines, I do not have
python-zc.buildout installed, but instead after running python bootstrap.py
I end up with the zc.buildout-1.5.2-pyX.Y.egg in my eggs directory. So I'm
guessing even though the versions are the same, there's some other
incompatibility between the Debuntu package and the PyPI package, but I don't
know what that might be.
Cheers, -Barry

On Thu, 2012-06-21 at 10:36 -0400, Barry Warsaw wrote:
For deployments (i.e. you just want to run mm3) it's better to create a virtualenv and then
python setup.py install
into that virtualenv.
Barry, I don't know if you followed the discussion on the Users list regarding placing an encrypted (AES) header into personalized, VERPed list posts which would contain the subscriber recipient's address and possibly also the list address. This would satisfy AOL's TOS (others, too) and not be redacted in their Email Feedback Reports.
I have some patches and files to this end, Which I've applied successfully to Mailman 2.1.15 and the suggestion was made on the Users list that I submit them for possible application to mm 3, which would probably be a more appropriate place for this feature.
To do this I need to set up a test installation of mm 3 which actually works, and delivers mail to a test list. I don't need to deploy it for general use.
-- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |

On Jun 21, 2012, at 10:32 AM, Lindsay Haisley wrote:
I've been skimming it, so I think I get the gist.
Agreed. I think *something* like this would be useful for mm3. I'm not sure about the best way to do it, i.e. whether it should be a generally available feature enabled by some config, or whether it should be implemented as a plugin. We could certainly discuss all that here.
Cool. The previous virtualenv instructions should still be relevant. You'd of course need to hook it up to an MTA, but mm3 has a nice "development" mode you can enable, which will ensure that the SMTP RCPT TO header will be forced to a specific address. What this means is that with devmode enabled, you can forge all the RFC 5322 headers you want to make it look like real email, and it'll never escape your local test environment. E.g. if you put the following in your mailman.cfg file:
[devmode] enabled: yes recipient: me@example.com
*All* of the email sent through your mm3 deployment will actually get delivered to me@example.com. There are other ways to do similar things e.g. using Postfix transports, but you may not need them.
To make something like this a supported feature does require more work, e.g. probably a schema change, plumbing through REST, documentation and a test suite. A Launchpad bug and merge proposal will be ideal. But don't let that discourage you. If you can come up with a nice proof-of-concept once of us can help shepherd you through the rest of the process.
Cheers, -Barry

On Thu, 2012-06-21 at 11:43 -0400, Barry Warsaw wrote:
The way I switched it on in 2.1.15 was by way of configuration variable in mm_cfg.py containing a global AES secret key. This can be added to mm_cfg.py by running a key generation script in the runtime mm bin directory. Absent this variable, the feature is moot since all relevant code gets bypassed.
Great!! Something to do with all my FREE TIME <LOL>. I'll probably work on it since I can't seem to leave projects like this alone.
One caveat/issue with the work I've done so far is that it requires the python-crypto module. This is no problem on Linux, possibly not on other Unix-like OSes, but from what I've read, the module has longstanding issues on a Windows platform. This might be a show-stopper.
Thanks for the coaching on setting up virtualenv!
-- Lindsay Haisley |"Friends are like potatoes. FMP Computer Services | If you eat them, they die" 512-259-1190 | http://www.fmp.com | - Aaron Edmund

On Jun 21, 2012, at 11:02 AM, Lindsay Haisley wrote:
So the mm3 equivalent would probably be a new variable in the [mta] section of the mailman.cfg file. Note that the defaults for mailman.cfg live in the src/mailman/config/schema.cfg file, so that's where you'd add this. Note too that these control global system-wide configurations, so if there's any reason why you'd want to have different keys for different mailing lists, it can't go there (but I don't see why that would be so I won't describe the alternative).
Also, of course the key will live in plain text in the deployed mailman.cfg file, but it sounds like that's not a problem.
Nope, Mailman doesn't officially run on Windows. :)
OTOH, I would make this feature conditional on the module being importable, so it won't be required even on *nix systems.
Thanks for the coaching on setting up virtualenv!
No problem, good luck!
Don't forget too, that if you can do IRC and need more real-time feedback, I usually hang out on freenode's #mailman channel during US/Eastern working hours. You need to ping my nick (the always clever and hard to guess 'barry' :) to get my attention though.
-Barry

On Thu, 2012-06-21 at 12:20 -0400, Barry Warsaw wrote:
I gave this some thought and decided that since any automated expunging of subscribers probably should be done at a system level (although theoretically a list admin could script an an automated mail command exchange system, or automate an interaction with a web UI), that a global key would be fine. Perhaps the feature could be turned on or off in individual lists.
Also, of course the key will live in plain text in the deployed mailman.cfg file, but it sounds like that's not a problem.
This isn't for *real* security, just to provide an encryption envelope for information so as to reversibly obfuscate it.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
participants (5)
-
Barry Warsaw
-
Jessy Kate Schingler
-
Lindsay Haisley
-
Lindsay Haisley
-
Stephen J. Turnbull