From ardeshir.org at gmail.com Sat Jul 2 00:25:24 2011 From: ardeshir.org at gmail.com (ardeshir) Date: Fri, 1 Jul 2011 17:25:24 -0500 Subject: [Mailman-Developers] Install problems for mailman-3.0.0a7 on Debian Squeeze Message-ID: Don't know if this will help you, but I got the following errors while installing on my system, Running Squeeze Debian Info: Operating system Debian Linux 6.0 Kernel and CPU Linux 2.6.32-5-xen-686 on i686 Processor information Intel(R) Xeon(R) CPU E5430 @ 2.66GHz, 1 cores python -v Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. dlopen("/usr/lib/python2.6/lib-dynload/readline.so", 2); import readline # dynamically loaded from /usr/lib/python2.6/lib-dynload/readline.so root at domU-12-31-38-04-D8-62:/usr/local/mailman/src/mailman-3.0.0a7# python bootstrap.py Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg Creating directory '/usr/local/mailman/src/mailman-3.0.0a7/bin'. Creating directory '/usr/local/mailman/src/mailman-3.0.0a7/parts'. Creating directory '/usr/local/mailman/src/mailman-3.0.0a7/eggs'. Creating directory '/usr/local/mailman/src/mailman-3.0.0a7/develop-eggs'. Getting distribution for 'setuptools'. Got setuptools 0.6c12dev-r88846. Generated script '/usr/local/mailman/src/mailman-3.0.0a7/bin/buildout'. root at domU-12-31-38-04-D8-62:/usr/local/mailman/src/mailman-3.0.0a7# bin/buildout Develop: '/usr/local/mailman/src/mailman-3.0.0a7/.' Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.8.tar.gz Extracting in /tmp/tmpAvhLrS Now working in /tmp/tmpAvhLrS/distribute-0.6.8 Building a Distribute egg in /usr/local/mailman/src/mailman-3.0.0a7 /usr/local/mailman/src/mailman-3.0.0a7/distribute-0.6.8-py2.6.egg warning: no previously-included files matching '*.egg-info' found anywhere in distribution no previously-included directories found matching 'src/attic' no previously-included directories found matching 'src/web' no previously-included directories found matching 'parts' Getting distribution for 'z3c.recipe.sphinxdoc'. Got z3c.recipe.sphinxdoc 0.0.8. Getting distribution for 'Sphinx'. Got Sphinx 1.0.7. Getting distribution for 'docutils'. warning: no files found matching 'MANIFEST' warning: no previously-included files matching '.cvsignore' found under directory '*' warning: no previously-included files matching '*.pyc' found under directory '*' warning: no previously-included files matching '*~' found under directory '*' warning: no previously-included files matching '.DS_Store' found under directory '*' zip_safe flag not set; analyzing archive contents... docutils.writers.html4css1.__init__: module references __file__ docutils.writers.s5_html.__init__: module references __file__ docutils.writers.latex2e.__init__: module references __file__ docutils.writers.pep_html.__init__: module references __file__ docutils.writers.odf_odt.__init__: module references __file__ docutils.writers.newlatex2e.__init__: module references __file__ docutils.parsers.rst.directives.misc: module references __file__ Got docutils 0.7. Getting distribution for 'zc.recipe.egg'. Got zc.recipe.egg 1.3.2. Getting distribution for 'Jinja2>=2.2'. warning: no previously-included files matching '*' found under directory 'docs/_build' warning: no previously-included files matching '*.pyc' found under directory 'jinja2' warning: no previously-included files matching '*.pyc' found under directory 'docs' warning: no previously-included files matching '*.pyo' found under directory 'jinja2' warning: no previously-included files matching '*.pyo' found under directory 'docs' Got Jinja2 2.5.5. Getting distribution for 'Pygments>=0.8'. Got Pygments 1.4. Getting distribution for 'z3c.recipe.filetemplate'. Got z3c.recipe.filetemplate 2.1.0. Getting distribution for 'zope.testing<4'. warning: no files found matching '*.test' under directory 'src' warning: no files found matching 'sampletests' under directory 'src' Got zope.testing 3.10.2. Getting distribution for 'zope.interface'. src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h: No such file or directory src/zope/interface/_zope_interface_coptimizations.c:16:26: error: structmember.h: No such file or directory src/zope/interface/_zope_interface_coptimizations.c:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c: In function 'import_declarations': src/zope/interface/_zope_interface_coptimizations.c:44: error: 'PyObject' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:44: error: (Each undeclared identifier is reported only once src/zope/interface/_zope_interface_coptimizations.c:44: error: for each function it appears in.) src/zope/interface/_zope_interface_coptimizations.c:44: error: 'declarations' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:44: error: 'i' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:44: warning: left-hand operand of comma expression has no effect src/zope/interface/_zope_interface_coptimizations.c:46: warning: implicit declaration of function 'PyImport_ImportModule' src/zope/interface/_zope_interface_coptimizations.c:47: error: 'NULL' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:50: error: 'BuiltinImplementationSpecifications' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:50: warning: implicit declaration of function 'PyObject_GetAttrString' src/zope/interface/_zope_interface_coptimizations.c:55: error: 'empty' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:59: error: 'fallback' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:69: warning: implicit declaration of function 'PyType_Check' src/zope/interface/_zope_interface_coptimizations.c:71: warning: implicit declaration of function 'PyErr_SetString' src/zope/interface/_zope_interface_coptimizations.c:71: error: 'PyExc_TypeError' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:76: error: 'Implements' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:76: error: 'PyTypeObject' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:76: error: expected expression before ')' token src/zope/interface/_zope_interface_coptimizations.c:78: warning: implicit declaration of function 'Py_DECREF' src/zope/interface/_zope_interface_coptimizations.c: At top level: src/zope/interface/_zope_interface_coptimizations.c:84: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SpecType' src/zope/interface/_zope_interface_coptimizations.c:86: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:95: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:152: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:180: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:263: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:276: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:306: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:316: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:343: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:361: error: array type has incomplete element type src/zope/interface/_zope_interface_coptimizations.c:363: error: 'PyCFunction' undeclared here (not in a function) src/zope/interface/_zope_interface_coptimizations.c:363: error: expected '}' before 'Spec_providedBy' src/zope/interface/_zope_interface_coptimizations.c:366: error: expected '}' before 'Spec_implementedBy' src/zope/interface/_zope_interface_coptimizations.c:368: error: expected '}' before 'Spec_extends' src/zope/interface/_zope_interface_coptimizations.c:371: error: 'NULL' undeclared here (not in a function) src/zope/interface/_zope_interface_coptimizations.c:374: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SpecType' src/zope/interface/_zope_interface_coptimizations.c:406: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:421: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'OSDType' src/zope/interface/_zope_interface_coptimizations.c:459: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:485: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CPBType' src/zope/interface/_zope_interface_coptimizations.c:539: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:608: error: array type has incomplete element type src/zope/interface/_zope_interface_coptimizations.c:609: error: expected '}' before '__adapt__' src/zope/interface/_zope_interface_coptimizations.c:631: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:675: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'InterfaceBase' src/zope/interface/_zope_interface_coptimizations.c:715: error: expected specifier-qualifier-list before 'PyObject_HEAD' src/zope/interface/_zope_interface_coptimizations.c:722: error: expected specifier-qualifier-list before 'PyObject_HEAD' src/zope/interface/_zope_interface_coptimizations.c:731: error: expected declaration specifiers or '...' before 'visitproc' src/zope/interface/_zope_interface_coptimizations.c: In function 'lookup_traverse': src/zope/interface/_zope_interface_coptimizations.c:735: error: 'lookup' has no member named '_cache' src/zope/interface/_zope_interface_coptimizations.c:736: warning: implicit declaration of function 'visit' src/zope/interface/_zope_interface_coptimizations.c:736: error: 'lookup' has no member named '_cache' src/zope/interface/_zope_interface_coptimizations.c:741: error: 'lookup' has no member named '_mcache' src/zope/interface/_zope_interface_coptimizations.c:742: error: 'lookup' has no member named '_mcache' src/zope/interface/_zope_interface_coptimizations.c:747: error: 'lookup' has no member named '_scache' src/zope/interface/_zope_interface_coptimizations.c:748: error: 'lookup' has no member named '_scache' src/zope/interface/_zope_interface_coptimizations.c: In function 'lookup_clear': src/zope/interface/_zope_interface_coptimizations.c:759: warning: implicit declaration of function 'Py_CLEAR' src/zope/interface/_zope_interface_coptimizations.c:759: error: 'lookup' has no member named '_cache' src/zope/interface/_zope_interface_coptimizations.c:760: error: 'lookup' has no member named '_mcache' src/zope/interface/_zope_interface_coptimizations.c:761: error: 'lookup' has no member named '_scache' src/zope/interface/_zope_interface_coptimizations.c: In function 'lookup_dealloc': src/zope/interface/_zope_interface_coptimizations.c:769: error: 'lookup' has no member named 'ob_type' src/zope/interface/_zope_interface_coptimizations.c:769: error: 'PyObject' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:769: error: expected expression before ')' token src/zope/interface/_zope_interface_coptimizations.c: At top level: src/zope/interface/_zope_interface_coptimizations.c:778: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:804: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:825: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:862: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:876: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:931: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:957: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:986: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1014: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1048: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1061: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1089: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1131: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1159: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1202: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1215: error: array type has incomplete element type src/zope/interface/_zope_interface_coptimizations.c:1216: error: expected '}' before 'lookup_changed' src/zope/interface/_zope_interface_coptimizations.c:1217: error: expected '}' before 'lookup_lookup' src/zope/interface/_zope_interface_coptimizations.c:1218: error: expected '}' before 'lookup_lookup1' src/zope/interface/_zope_interface_coptimizations.c:1219: error: expected '}' before 'lookup_queryAdapter' src/zope/interface/_zope_interface_coptimizations.c:1220: error: expected '}' before 'lookup_adapter_hook' src/zope/interface/_zope_interface_coptimizations.c:1221: error: expected '}' before 'lookup_lookupAll' src/zope/interface/_zope_interface_coptimizations.c:1222: error: expected '}' before 'lookup_subscriptions' src/zope/interface/_zope_interface_coptimizations.c:1226: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LookupBase' src/zope/interface/_zope_interface_coptimizations.c:1261: error: expected declaration specifiers or '...' before 'visitproc' src/zope/interface/_zope_interface_coptimizations.c: In function 'verifying_traverse': src/zope/interface/_zope_interface_coptimizations.c:1265: error: 'visit' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1265: error: too many arguments to function 'lookup_traverse' src/zope/interface/_zope_interface_coptimizations.c:1269: error: 'verify' has no member named '_verify_ro' src/zope/interface/_zope_interface_coptimizations.c:1270: error: 'verify' has no member named '_verify_ro' src/zope/interface/_zope_interface_coptimizations.c:1274: error: 'verify' has no member named '_verify_generations' src/zope/interface/_zope_interface_coptimizations.c:1275: error: 'verify' has no member named '_verify_generations' src/zope/interface/_zope_interface_coptimizations.c: In function 'verifying_clear': src/zope/interface/_zope_interface_coptimizations.c:1287: error: 'verify' has no member named '_verify_generations' src/zope/interface/_zope_interface_coptimizations.c:1288: error: 'verify' has no member named '_verify_ro' src/zope/interface/_zope_interface_coptimizations.c: In function 'verifying_dealloc': src/zope/interface/_zope_interface_coptimizations.c:1297: error: 'verify' has no member named 'ob_type' src/zope/interface/_zope_interface_coptimizations.c:1297: error: 'PyObject' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1297: error: expected expression before ')' token src/zope/interface/_zope_interface_coptimizations.c: At top level: src/zope/interface/_zope_interface_coptimizations.c:1306: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1329: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c: In function '_verify': src/zope/interface/_zope_interface_coptimizations.c:1376: error: 'PyObject' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1376: error: 'changed_result' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1378: error: 'verify' has no member named '_verify_ro' src/zope/interface/_zope_interface_coptimizations.c:1378: error: 'verify' has no member named '_verify_generations' src/zope/interface/_zope_interface_coptimizations.c:1380: error: 'generations' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1383: warning: implicit declaration of function '_generations_tuple' src/zope/interface/_zope_interface_coptimizations.c:1383: error: 'verify' has no member named '_verify_ro' src/zope/interface/_zope_interface_coptimizations.c:1387: warning: implicit declaration of function 'PyObject_RichCompareBool' src/zope/interface/_zope_interface_coptimizations.c:1387: error: 'verify' has no member named '_verify_generations' src/zope/interface/_zope_interface_coptimizations.c:1388: error: 'Py_NE' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1397: warning: implicit declaration of function 'PyObject_CallMethodObjArgs' src/zope/interface/_zope_interface_coptimizations.c:1397: error: expected expression before ')' token src/zope/interface/_zope_interface_coptimizations.c:1397: error: 'strchanged' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c:1398: error: 'Py_None' undeclared (first use in this function) src/zope/interface/_zope_interface_coptimizations.c: At top level: src/zope/interface/_zope_interface_coptimizations.c:1406: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1422: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1438: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1454: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1470: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1486: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1502: error: array type has incomplete element type src/zope/interface/_zope_interface_coptimizations.c:1503: error: expected '}' before 'verifying_changed' src/zope/interface/_zope_interface_coptimizations.c:1504: error: expected '}' before 'verifying_lookup' src/zope/interface/_zope_interface_coptimizations.c:1505: error: expected '}' before 'verifying_lookup1' src/zope/interface/_zope_interface_coptimizations.c:1506: error: expected '}' before 'verifying_queryAdapter' src/zope/interface/_zope_interface_coptimizations.c:1507: error: expected '}' before 'verifying_adapter_hook' src/zope/interface/_zope_interface_coptimizations.c:1508: error: expected '}' before 'verifying_lookupAll' src/zope/interface/_zope_interface_coptimizations.c:1509: error: expected '}' before 'verifying_subscriptions' src/zope/interface/_zope_interface_coptimizations.c:1513: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'VerifyingBase' src/zope/interface/_zope_interface_coptimizations.c:1555: error: array type has incomplete element type src/zope/interface/_zope_interface_coptimizations.c:1556: error: expected '}' before 'implementedBy' src/zope/interface/_zope_interface_coptimizations.c:1559: error: expected '}' before 'getObjectSpecification' src/zope/interface/_zope_interface_coptimizations.c:1561: error: expected '}' before 'providedBy' src/zope/interface/_zope_interface_coptimizations.c:1564: error: expected '}' before 'NULL' src/zope/interface/_zope_interface_coptimizations.c:1583: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/zope/interface/_zope_interface_coptimizations.c:1673: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'init_zope_interface_coptimizations' ******************************************************************************** WARNING: An optional code optimization (C extension) could not be compiled. Optimizations for this package will not be available! command 'gcc' failed with exit status 1 ******************************************************************************** Got zope.interface 3.6.3. Getting distribution for 'zope.configuration'. Got zope.configuration 3.7.4. Getting distribution for 'zope.component'. Got zope.component 3.10.0. Getting distribution for 'storm'. storm/cextensions.c:23:20: error: Python.h: No such file or directory storm/cextensions.c:24:26: error: structmember.h: No such file or directory storm/cextensions.c:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:62: error: expected ')' before '*' token storm/cextensions.c:75: error: expected ')' before '*' token storm/cextensions.c:100: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:101: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:103: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:104: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:105: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:106: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:107: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:108: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:109: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:110: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:114: error: expected specifier-qualifier-list before 'PyObject_HEAD' storm/cextensions.c:120: error: expected specifier-qualifier-list before 'PyObject_HEAD' storm/cextensions.c:133: error: expected specifier-qualifier-list before 'PyObject_HEAD' storm/cextensions.c:146: error: expected specifier-qualifier-list before 'PyDictObject' storm/cextensions.c: In function 'initialize_globals': storm/cextensions.c:161: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:161: error: (Each undeclared identifier is reported only once storm/cextensions.c:161: error: for each function it appears in.) storm/cextensions.c:161: error: 'module' undeclared (first use in this function) storm/cextensions.c:169: warning: implicit declaration of function 'PyImport_ImportModule' storm/cextensions.c:173: error: 'Undef' undeclared (first use in this function) storm/cextensions.c:173: warning: implicit declaration of function 'PyObject_GetAttrString' storm/cextensions.c:177: warning: implicit declaration of function 'Py_DECREF' storm/cextensions.c:184: error: 'raise_none_error' undeclared (first use in this function) storm/cextensions.c:188: error: 'LazyValue' undeclared (first use in this function) storm/cextensions.c:199: error: 'get_cls_info' undeclared (first use in this function) storm/cextensions.c:210: error: 'EventSystem' undeclared (first use in this function) storm/cextensions.c:221: error: 'SQLRaw' undeclared (first use in this function) storm/cextensions.c:225: error: 'SQLToken' undeclared (first use in this function) storm/cextensions.c:229: error: 'State' undeclared (first use in this function) storm/cextensions.c:233: error: 'CompileError' undeclared (first use in this function) storm/cextensions.c:241: error: 'parenthesis_format' undeclared (first use in this function) storm/cextensions.c:241: warning: implicit declaration of function 'PyUnicode_DecodeASCII' storm/cextensions.c:242: error: 'default_compile_join' undeclared (first use in this function) storm/cextensions.c: At top level: storm/cextensions.c:249: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c:249: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c: In function 'EventSystem_init': storm/cextensions.c:251: error: 'NULL' undeclared (first use in this function) storm/cextensions.c:252: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:252: error: 'owner' undeclared (first use in this function) storm/cextensions.c:252: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:252: warning: statement with no effect storm/cextensions.c:255: warning: implicit declaration of function 'PyArg_ParseTupleAndKeywords' storm/cextensions.c:255: error: 'args' undeclared (first use in this function) storm/cextensions.c:255: error: 'kwargs' undeclared (first use in this function) storm/cextensions.c:259: error: 'EventSystemObject' has no member named '_owner_ref' storm/cextensions.c:259: warning: implicit declaration of function 'PyWeakref_NewRef' storm/cextensions.c:259: warning: statement with no effect storm/cextensions.c:260: error: 'EventSystemObject' has no member named '_owner_ref' storm/cextensions.c:262: error: 'EventSystemObject' has no member named '_hooks' storm/cextensions.c:262: warning: implicit declaration of function 'PyDict_New' storm/cextensions.c:262: warning: statement with no effect storm/cextensions.c:263: error: 'EventSystemObject' has no member named '_hooks' storm/cextensions.c: At top level: storm/cextensions.c:272: error: expected declaration specifiers or '...' before 'visitproc' storm/cextensions.c: In function 'EventSystem_traverse': storm/cextensions.c:274: warning: implicit declaration of function 'Py_VISIT' storm/cextensions.c:274: error: 'EventSystemObject' has no member named '_owner_ref' storm/cextensions.c:275: error: 'EventSystemObject' has no member named '_hooks' storm/cextensions.c: In function 'EventSystem_clear': storm/cextensions.c:282: warning: implicit declaration of function 'Py_CLEAR' storm/cextensions.c:282: error: 'EventSystemObject' has no member named '_owner_ref' storm/cextensions.c:283: error: 'EventSystemObject' has no member named '_hooks' storm/cextensions.c: In function 'EventSystem_dealloc': storm/cextensions.c:291: error: 'EventSystemObject' has no member named 'ob_type' storm/cextensions.c:291: error: request for member 'tp_free' in something not a structure or union storm/cextensions.c:291: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:291: error: expected expression before ')' token storm/cextensions.c:291: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:291: error: called object '' is not a function storm/cextensions.c:291: warning: statement with no effect storm/cextensions.c: At top level: storm/cextensions.c:294: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:350: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:394: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:424: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:497: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'EventSystem_methods' storm/cextensions.c:505: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'EventSystem_members' storm/cextensions.c:512: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyTypeObject' storm/cextensions.c:557: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:584: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c:584: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c: In function 'Variable_init': storm/cextensions.c:589: error: 'NULL' undeclared (first use in this function) storm/cextensions.c:589: error: initializer element is not constant storm/cextensions.c:589: error: (near initialization for 'kwlist[9]') storm/cextensions.c:591: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:591: error: 'value' undeclared (first use in this function) storm/cextensions.c:591: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:591: error: 'Undef' undeclared (first use in this function) storm/cextensions.c:591: warning: statement with no effect storm/cextensions.c:592: error: 'value_factory' undeclared (first use in this function) storm/cextensions.c:592: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:592: warning: statement with no effect storm/cextensions.c:593: error: 'from_db' undeclared (first use in this function) storm/cextensions.c:593: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:593: error: 'Py_False' undeclared (first use in this function) storm/cextensions.c:593: warning: statement with no effect storm/cextensions.c:594: error: 'allow_none' undeclared (first use in this function) storm/cextensions.c:594: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:594: error: 'Py_True' undeclared (first use in this function) storm/cextensions.c:594: warning: statement with no effect storm/cextensions.c:595: error: 'column' undeclared (first use in this function) storm/cextensions.c:595: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:595: error: 'Py_None' undeclared (first use in this function) storm/cextensions.c:595: warning: statement with no effect storm/cextensions.c:596: error: 'event' undeclared (first use in this function) storm/cextensions.c:596: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:596: warning: statement with no effect storm/cextensions.c:597: error: 'validator' undeclared (first use in this function) storm/cextensions.c:597: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:597: warning: statement with no effect storm/cextensions.c:598: error: 'validator_object_factory' undeclared (first use in this function) storm/cextensions.c:598: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:598: warning: statement with no effect storm/cextensions.c:599: error: 'validator_attribute' undeclared (first use in this function) storm/cextensions.c:599: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:599: warning: statement with no effect storm/cextensions.c:600: error: 'tmp' undeclared (first use in this function) storm/cextensions.c:600: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:600: warning: statement with no effect storm/cextensions.c:602: error: 'args' undeclared (first use in this function) storm/cextensions.c:602: error: 'kwargs' undeclared (first use in this function) storm/cextensions.c:611: warning: implicit declaration of function 'PyObject_IsTrue' storm/cextensions.c:613: warning: implicit declaration of function 'Py_INCREF' storm/cextensions.c:614: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:614: error: 'VariableObject' has no member named '_allow_none' storm/cextensions.c:614: warning: statement with no effect storm/cextensions.c:614: error: 'VariableObject' has no member named '_allow_none' storm/cextensions.c:614: warning: statement with no effect storm/cextensions.c:620: warning: implicit declaration of function 'PyObject_CallMethod' storm/cextensions.c:620: error: expected expression before ')' token storm/cextensions.c:620: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:627: warning: implicit declaration of function 'PyObject_CallFunctionObjArgs' storm/cextensions.c:628: error: expected expression before ')' token storm/cextensions.c:628: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:629: warning: statement with no effect storm/cextensions.c:639: error: 'VariableObject' has no member named '_validator' storm/cextensions.c:639: warning: statement with no effect storm/cextensions.c:642: error: 'VariableObject' has no member named '_validator_object_factory' storm/cextensions.c:642: warning: statement with no effect storm/cextensions.c:645: error: 'VariableObject' has no member named '_validator_attribute' storm/cextensions.c:645: warning: statement with no effect storm/cextensions.c:649: error: 'VariableObject' has no member named 'column' storm/cextensions.c:651: error: 'VariableObject' has no member named 'column' storm/cextensions.c:651: warning: statement with no effect storm/cextensions.c:654: error: 'VariableObject' has no member named 'event' storm/cextensions.c:656: error: 'VariableObject' has no member named 'event' storm/cextensions.c:656: warning: statement with no effect storm/cextensions.c: At top level: storm/cextensions.c:665: error: expected declaration specifiers or '...' before 'visitproc' storm/cextensions.c: In function 'Variable_traverse': storm/cextensions.c:667: error: 'VariableObject' has no member named '_value' storm/cextensions.c:668: error: 'VariableObject' has no member named '_lazy_value' storm/cextensions.c:669: error: 'VariableObject' has no member named '_checkpoint_state' storm/cextensions.c:671: error: 'VariableObject' has no member named '_validator' storm/cextensions.c:672: error: 'VariableObject' has no member named '_validator_object_factory' storm/cextensions.c:673: error: 'VariableObject' has no member named '_validator_attribute' storm/cextensions.c:674: error: 'VariableObject' has no member named 'column' storm/cextensions.c:675: error: 'VariableObject' has no member named 'event' storm/cextensions.c: In function 'Variable_clear': storm/cextensions.c:682: error: 'VariableObject' has no member named '_value' storm/cextensions.c:683: error: 'VariableObject' has no member named '_lazy_value' storm/cextensions.c:684: error: 'VariableObject' has no member named '_checkpoint_state' storm/cextensions.c:685: error: 'VariableObject' has no member named '_allow_none' storm/cextensions.c:686: error: 'VariableObject' has no member named '_validator' storm/cextensions.c:687: error: 'VariableObject' has no member named '_validator_object_factory' storm/cextensions.c:688: error: 'VariableObject' has no member named '_validator_attribute' storm/cextensions.c:689: error: 'VariableObject' has no member named 'column' storm/cextensions.c:690: error: 'VariableObject' has no member named 'event' storm/cextensions.c: In function 'Variable_dealloc': storm/cextensions.c:698: error: 'VariableObject' has no member named 'ob_type' storm/cextensions.c:698: error: request for member 'tp_free' in something not a structure or union storm/cextensions.c:698: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:698: error: expected expression before ')' token storm/cextensions.c:698: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:698: error: called object '' is not a function storm/cextensions.c:698: warning: statement with no effect storm/cextensions.c: At top level: storm/cextensions.c:701: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:712: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:723: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:748: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:791: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:927: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:974: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:981: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1005: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1020: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1034: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1046: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1077: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Variable_methods' storm/cextensions.c:1096: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Variable_members' storm/cextensions.c:1107: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyTypeObject' storm/cextensions.c:1152: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1156: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c:1156: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c: In function 'Compile_init': storm/cextensions.c:1158: error: 'NULL' undeclared (first use in this function) storm/cextensions.c:1158: error: initializer element is not constant storm/cextensions.c:1158: error: (near initialization for 'kwlist[1]') storm/cextensions.c:1160: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:1160: error: 'parent' undeclared (first use in this function) storm/cextensions.c:1160: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1160: error: 'Py_None' undeclared (first use in this function) storm/cextensions.c:1160: warning: statement with no effect storm/cextensions.c:1162: error: 'module' undeclared (first use in this function) storm/cextensions.c:1162: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1162: warning: statement with no effect storm/cextensions.c:1163: error: 'WeakKeyDictionary' undeclared (first use in this function) storm/cextensions.c:1163: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1163: warning: statement with no effect storm/cextensions.c:1165: error: 'args' undeclared (first use in this function) storm/cextensions.c:1165: error: 'kwargs' undeclared (first use in this function) storm/cextensions.c:1176: error: 'CompileObject' has no member named '_local_dispatch_table' storm/cextensions.c:1177: error: 'CompileObject' has no member named '_local_precedence' storm/cextensions.c:1178: error: 'CompileObject' has no member named '_local_reserved_words' storm/cextensions.c:1179: error: 'CompileObject' has no member named '_dispatch_table' storm/cextensions.c:1180: error: 'CompileObject' has no member named '_precedence' storm/cextensions.c:1181: error: 'CompileObject' has no member named '_reserved_words' storm/cextensions.c:1188: error: 'CompileObject' has no member named '_children' storm/cextensions.c:1193: error: 'CompileObject' has no member named '_parents' storm/cextensions.c:1193: warning: implicit declaration of function 'PyList_New' storm/cextensions.c:1197: error: 'tmp' undeclared (first use in this function) storm/cextensions.c:1197: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1197: warning: statement with no effect storm/cextensions.c:1201: warning: implicit declaration of function 'PyList_SetSlice' storm/cextensions.c:1201: error: 'CompileObject' has no member named '_parents' storm/cextensions.c:1201: error: 'CompileObject' has no member named '_parents' storm/cextensions.c:1205: warning: implicit declaration of function 'PyList_Append' storm/cextensions.c:1205: error: 'CompileObject' has no member named '_parents' storm/cextensions.c:1208: warning: implicit declaration of function 'PyObject_SetItem' storm/cextensions.c:1208: error: 'CompileObject' has no member named '_children' storm/cextensions.c:1208: error: expected expression before ')' token storm/cextensions.c:1208: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1212: warning: implicit declaration of function 'Compile__update_cache' storm/cextensions.c:1219: warning: implicit declaration of function 'Py_XDECREF' storm/cextensions.c: At top level: storm/cextensions.c:1225: error: expected declaration specifiers or '...' before 'visitproc' storm/cextensions.c: In function 'Compile_traverse': storm/cextensions.c:1227: error: 'CompileObject' has no member named '_local_dispatch_table' storm/cextensions.c:1228: error: 'CompileObject' has no member named '_local_precedence' storm/cextensions.c:1229: error: 'CompileObject' has no member named '_local_reserved_words' storm/cextensions.c:1230: error: 'CompileObject' has no member named '_dispatch_table' storm/cextensions.c:1231: error: 'CompileObject' has no member named '_precedence' storm/cextensions.c:1232: error: 'CompileObject' has no member named '_reserved_words' storm/cextensions.c:1233: error: 'CompileObject' has no member named '_children' storm/cextensions.c:1234: error: 'CompileObject' has no member named '_parents' storm/cextensions.c: In function 'Compile_clear': storm/cextensions.c:1241: error: 'CompileObject' has no member named '__weakreflist' storm/cextensions.c:1242: warning: implicit declaration of function 'PyObject_ClearWeakRefs' storm/cextensions.c:1242: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:1242: error: expected expression before ')' token storm/cextensions.c:1242: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1243: error: 'CompileObject' has no member named '_local_dispatch_table' storm/cextensions.c:1244: error: 'CompileObject' has no member named '_local_precedence' storm/cextensions.c:1245: error: 'CompileObject' has no member named '_local_reserved_words' storm/cextensions.c:1246: error: 'CompileObject' has no member named '_dispatch_table' storm/cextensions.c:1247: error: 'CompileObject' has no member named '_precedence' storm/cextensions.c:1248: error: 'CompileObject' has no member named '_reserved_words' storm/cextensions.c:1249: error: 'CompileObject' has no member named '_children' storm/cextensions.c:1250: error: 'CompileObject' has no member named '_parents' storm/cextensions.c: In function 'Compile_dealloc': storm/cextensions.c:1258: error: 'CompileObject' has no member named 'ob_type' storm/cextensions.c:1258: error: request for member 'tp_free' in something not a structure or union storm/cextensions.c:1258: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:1258: error: expected expression before ')' token storm/cextensions.c:1258: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1258: error: called object '' is not a function storm/cextensions.c:1258: warning: statement with no effect storm/cextensions.c: At top level: storm/cextensions.c:1261: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1315: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1331: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1366: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1401: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1425: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyTypeObject' storm/cextensions.c:1427: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1434: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1447: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1478: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1574: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1708: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1743: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compile_methods' storm/cextensions.c:1758: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compile_members' storm/cextensions.c:1771: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyTypeObject' storm/cextensions.c:1816: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1823: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ObjectInfo_deleted_callback' storm/cextensions.c:1828: error: expected declaration specifiers or '...' before 'PyObject' storm/cextensions.c: In function 'ObjectInfo_init': storm/cextensions.c:1830: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:1830: error: 'self_get_obj' undeclared (first use in this function) storm/cextensions.c:1830: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1830: error: 'NULL' undeclared (first use in this function) storm/cextensions.c:1830: warning: statement with no effect storm/cextensions.c:1831: error: 'empty_args' undeclared (first use in this function) storm/cextensions.c:1831: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1831: warning: statement with no effect storm/cextensions.c:1832: error: 'factory_kwargs' undeclared (first use in this function) storm/cextensions.c:1832: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1832: warning: statement with no effect storm/cextensions.c:1833: error: 'columns' undeclared (first use in this function) storm/cextensions.c:1833: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1833: warning: statement with no effect storm/cextensions.c:1834: error: 'primary_key' undeclared (first use in this function) storm/cextensions.c:1834: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1834: warning: statement with no effect storm/cextensions.c:1835: error: 'obj' undeclared (first use in this function) storm/cextensions.c:1835: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1835: warning: statement with no effect storm/cextensions.c:1838: warning: implicit declaration of function 'PyTuple_New' storm/cextensions.c:1838: warning: statement with no effect storm/cextensions.c:1840: error: 'PyDict_Type' undeclared (first use in this function) storm/cextensions.c:1840: error: request for member 'tp_init' in something not a structure or union storm/cextensions.c:1840: error: expected expression before ')' token storm/cextensions.c:1840: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1840: error: called object '' is not a function storm/cextensions.c:1840: warning: comparison between pointer and integer storm/cextensions.c:1844: warning: implicit declaration of function 'PyArg_ParseTuple' storm/cextensions.c:1844: error: 'args' undeclared (first use in this function) storm/cextensions.c:1848: error: 'ObjectInfoObject' has no member named 'cls_info' storm/cextensions.c:1848: error: 'get_cls_info' undeclared (first use in this function) storm/cextensions.c:1848: error: request for member 'ob_type' in something not a structure or union storm/cextensions.c:1853: error: 'ObjectInfoObject' has no member named '__obj_ref_callback' storm/cextensions.c:1853: warning: implicit declaration of function 'PyCFunction_NewEx' storm/cextensions.c:1853: error: 'ObjectInfo_deleted_callback' undeclared (first use in this function) storm/cextensions.c:1853: error: expected expression before ')' token storm/cextensions.c:1853: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1857: error: 'ObjectInfoObject' has no member named '__obj_ref' storm/cextensions.c:1857: error: 'ObjectInfoObject' has no member named '__obj_ref_callback' storm/cextensions.c:1861: error: 'ObjectInfoObject' has no member named 'event' storm/cextensions.c:1861: error: 'EventSystem' undeclared (first use in this function) storm/cextensions.c:1865: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:1867: error: expected expression before ')' token storm/cextensions.c:1867: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1870: warning: implicit declaration of function 'PyDict_SetItemString' storm/cextensions.c:1870: error: 'ObjectInfoObject' has no member named 'event' storm/cextensions.c:1875: error: 'ObjectInfoObject' has no member named 'cls_info' storm/cextensions.c:1876: warning: implicit declaration of function 'PyTuple_GET_SIZE' storm/cextensions.c:1883: error: 'column' undeclared (first use in this function) storm/cextensions.c:1883: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1883: warning: implicit declaration of function 'PyTuple_GET_ITEM' storm/cextensions.c:1883: warning: statement with no effect storm/cextensions.c:1884: error: 'variable' undeclared (first use in this function) storm/cextensions.c:1884: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1884: error: 'factory' undeclared (first use in this function) storm/cextensions.c:1884: warning: left-hand operand of comma expression has no effect storm/cextensions.c:1884: warning: statement with no effect storm/cextensions.c:1888: warning: implicit declaration of function 'PyObject_Call' storm/cextensions.c:1888: warning: statement with no effect storm/cextensions.c:1891: warning: implicit declaration of function 'PyDict_SetItem' storm/cextensions.c:1891: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:1900: error: expected expression before ')' token storm/cextensions.c:1900: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1904: error: 'ObjectInfoObject' has no member named 'primary_vars' storm/cextensions.c:1907: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1907: warning: statement with no effect storm/cextensions.c:1908: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1908: warning: implicit declaration of function 'PyDict_GetItem' storm/cextensions.c:1908: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:1908: warning: statement with no effect storm/cextensions.c:1910: warning: implicit declaration of function 'PyTuple_SET_ITEM' storm/cextensions.c:1910: error: 'ObjectInfoObject' has no member named 'primary_vars' storm/cextensions.c: At top level: storm/cextensions.c:1929: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1937: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1954: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1971: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:1980: error: expected declaration specifiers or '...' before 'visitproc' storm/cextensions.c: In function 'ObjectInfo_traverse': storm/cextensions.c:1982: error: 'ObjectInfoObject' has no member named '__obj_ref' storm/cextensions.c:1983: error: 'ObjectInfoObject' has no member named '__obj_ref_callback' storm/cextensions.c:1984: error: 'ObjectInfoObject' has no member named 'cls_info' storm/cextensions.c:1985: error: 'ObjectInfoObject' has no member named 'event' storm/cextensions.c:1986: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:1987: error: 'ObjectInfoObject' has no member named 'primary_vars' storm/cextensions.c:1988: error: 'PyDict_Type' undeclared (first use in this function) storm/cextensions.c:1988: error: request for member 'tp_traverse' in something not a structure or union storm/cextensions.c:1988: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:1988: error: expected expression before ')' token storm/cextensions.c:1988: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:1988: error: called object '' is not a function storm/cextensions.c:1988: warning: return makes integer from pointer without a cast storm/cextensions.c: In function 'ObjectInfo_clear': storm/cextensions.c:1994: error: 'ObjectInfoObject' has no member named '__obj_ref' storm/cextensions.c:1995: error: 'ObjectInfoObject' has no member named '__obj_ref_callback' storm/cextensions.c:1996: error: 'ObjectInfoObject' has no member named 'cls_info' storm/cextensions.c:1997: error: 'ObjectInfoObject' has no member named 'event' storm/cextensions.c:1998: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:1999: error: 'ObjectInfoObject' has no member named 'primary_vars' storm/cextensions.c:2000: error: 'PyDict_Type' undeclared (first use in this function) storm/cextensions.c:2000: error: request for member 'tp_clear' in something not a structure or union storm/cextensions.c:2000: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:2000: error: expected expression before ')' token storm/cextensions.c:2000: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:2000: error: called object '' is not a function storm/cextensions.c:2000: warning: return makes integer from pointer without a cast storm/cextensions.c: At top level: storm/cextensions.c:2003: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c: In function 'ObjectInfo_dealloc': storm/cextensions.c:2026: error: 'ObjectInfoObject' has no member named '__weakreflist' storm/cextensions.c:2027: error: 'PyObject' undeclared (first use in this function) storm/cextensions.c:2027: error: expected expression before ')' token storm/cextensions.c:2027: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:2028: error: 'ObjectInfoObject' has no member named '__obj_ref' storm/cextensions.c:2029: error: 'ObjectInfoObject' has no member named '__obj_ref_callback' storm/cextensions.c:2030: error: 'ObjectInfoObject' has no member named 'cls_info' storm/cextensions.c:2031: error: 'ObjectInfoObject' has no member named 'event' storm/cextensions.c:2032: error: 'ObjectInfoObject' has no member named 'variables' storm/cextensions.c:2033: error: 'ObjectInfoObject' has no member named 'primary_vars' storm/cextensions.c:2034: error: 'PyDict_Type' undeclared (first use in this function) storm/cextensions.c:2034: error: request for member 'tp_dealloc' in something not a structure or union storm/cextensions.c:2034: error: expected expression before ')' token storm/cextensions.c:2034: error: invalid operands to binary * (have 'char **' and 'char **') storm/cextensions.c:2034: error: called object '' is not a function storm/cextensions.c:2034: warning: statement with no effect storm/cextensions.c: At top level: storm/cextensions.c:2037: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ObjectInfo_methods' storm/cextensions.c:2047: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ObjectInfo_members' storm/cextensions.c:2056: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ObjectInfo_getset' storm/cextensions.c:2062: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyTypeObject' storm/cextensions.c:2107: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token storm/cextensions.c:2142: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cextensions_methods' storm/cextensions.c:2149: error: expected ')' before '*' token storm/cextensions.c:2168: warning: return type defaults to 'int' storm/cextensions.c: In function 'DL_EXPORT': storm/cextensions.c:2168: error: expected declaration specifiers before 'initcextensions' storm/cextensions.c:2192: error: expected '{' at end of input error: Setup script exited with error: command 'gcc' failed with exit status 1 An error occurred when trying to install storm 0.18. Look above this message for any errors that were output by easy_install. While: Installing. Getting section filetemplates. Initializing part filetemplates. Getting distribution for 'storm'. Error: Couldn't install: storm 0.18 root at domU-12-31-38-04-D8-62:/usr/local/mailman/src/mailman-3.0.0a7# bin/test -vv -bash: bin/test: No such file or directory From pabs3 at bonedaddy.net Sat Jul 2 07:57:46 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Sat, 2 Jul 2011 06:57:46 +0100 Subject: [Mailman-Developers] Install problems for mailman-3.0.0a7 on Debian Squeeze In-Reply-To: References: Message-ID: On Fri, Jul 1, 2011 at 11:25 PM, ardeshir wrote: > Don't know if this will help you, but I got the following errors while installing on my system, > Running Squeeze Debian ... > src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h: No such file or directory > src/zope/interface/_zope_interface_coptimizations.c:16:26: error: structmember.h: No such file or directory You need to install the Python headers (Debian package python-dev). > storm/cextensions.c:23:20: error: Python.h: No such file or directory > storm/cextensions.c:24:26: error: structmember.h: No such file or directory Same here. -- bye, pabs http://wiki.debian.org/PaulWise From pavlix at pavlix.net Wed Jul 6 17:29:19 2011 From: pavlix at pavlix.net (Pavel =?UTF-8?Q?=C5=A0imerda?=) Date: Wed, 06 Jul 2011 17:29:19 +0200 Subject: [Mailman-Developers] Mailman 2.x Virtual Hosting In-Reply-To: <20110624162925.373a8ed4@neurotica.wooz.org> References: <1308920783.3048.35.camel@traveller.pavlix.net> <20110624162925.373a8ed4@neurotica.wooz.org> Message-ID: <1309966159.2169.46.camel@traveller.pavlix.net> Hi Barry, I'm sorry I couldn't write earlier. On Fri, 2011-06-24 at 16:29 -0400, Barry Warsaw wrote: > Hi Pavel, thanks for writing this up for the benefit of other users. I just > want to comment on one thing. > > On Jun 24, 2011, at 03:06 PM, Pavel ?imerda wrote: > > >First thing that surprised me is that Mailman doesn't support virtual > >hosting. The second one was that documentation claimes it does. Even the > >simplest test, creation of lists with same names under different domains > >shows 2.x vhost support is simply broken. > > Can you point to where the documentation makes this claim? It's painfully > well-known that same-list-different-domains is not supported by default in > Mailman 2.x. If there's official documentation that claims otherwise, we need > to fix that. > The official documentation doesn't explicitly claim it. But there's a section about setting up virtual domains that doesn't warn that virtual domain implementation is incomplete: http://www.gnu.org/s/mailman/mailman-install/postfix-virtual.html I, as a seasoned user of Postfix, Apache, and other virtualized server software, but new user of Mailman, can confirm, that this documentation made me think mailman fully supports virtual hosting. Unfortunately, there are other resources on the web that are similarly confusing. With most of the patches already working, it doesn't look too hard to add full virtual domain support to Mailman 2.x via address rewriting. I fixed more issues on my installation myself. Any way, I'd be very pleased if the documentation is ?fixed?, even if its brokennes is not obvious to people who have lived with Mailman for long time. > >I would like to know if there's anyone else interested in getting > >Mailman 2.x to support a feature the documentation already claims to > >support. > > > >Testing, links to resources, code, and help with getting it official is > >welcome. > > I would oppose making this feature official in Mailman 2.x. It's much better > to help get Mailman 3 to releasable state. I think it's fine if you need a > solution right now, to work on, and publish unofficial patches for Mailman 2.x. If Mailman 3 is comming soon, I could stay with the current, semi-functional state (combination of Mailman 2.x, downloaded patches and some local fixes) and switch to Mailman 3 when it's ready (possibly help with bugreports and some fixes, as I know a bit of Python). Any timelines? Pavel > > Cheers, > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/pavlix%40pavlix.net > > Security Policy: http://wiki.list.org/x/QIA9 From pavlix at pavlix.net Wed Jul 6 17:32:03 2011 From: pavlix at pavlix.net (Pavel =?UTF-8?Q?=C5=A0imerda?=) Date: Wed, 06 Jul 2011 17:32:03 +0200 Subject: [Mailman-Developers] Install problems for mailman-3.0.0a7 on Debian Squeeze In-Reply-To: References: Message-ID: <1309966324.2169.48.camel@traveller.pavlix.net> Wouldn't it be nice to have some more reasonable way to present this info to the user? Pavel On Sat, 2011-07-02 at 06:57 +0100, Paul Wise wrote: > On Fri, Jul 1, 2011 at 11:25 PM, ardeshir wrote: > > > Don't know if this will help you, but I got the following errors while installing on my system, > > Running Squeeze Debian > ... > > src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h: No such file or directory > > src/zope/interface/_zope_interface_coptimizations.c:16:26: error: structmember.h: No such file or directory > > You need to install the Python headers (Debian package python-dev). > > > storm/cextensions.c:23:20: error: Python.h: No such file or directory > > storm/cextensions.c:24:26: error: structmember.h: No such file or directory > > Same here. > From pabs3 at bonedaddy.net Thu Jul 7 08:54:16 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Thu, 7 Jul 2011 08:54:16 +0200 Subject: [Mailman-Developers] Install problems for mailman-3.0.0a7 on Debian Squeeze In-Reply-To: <1309966324.2169.48.camel@traveller.pavlix.net> References: <1309966324.2169.48.camel@traveller.pavlix.net> Message-ID: On Wed, Jul 6, 2011 at 5:32 PM, Pavel ?imerda wrote: > Wouldn't it be nice to have some more reasonable way to present this > info to the user? Agreed. Does distutils have the equivalent of autoconf for checking for dependencies before starting the build? If so I assume mailman patches for this would be welcome. -- bye, pabs http://bonedaddy.net/pabs3/ From mark at msapiro.net Sat Jul 9 00:32:56 2011 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 08 Jul 2011 15:32:56 -0700 Subject: [Mailman-Developers] Mailman 2.x Virtual Hosting In-Reply-To: <1309966159.2169.46.camel@traveller.pavlix.net> References: <1308920783.3048.35.camel@traveller.pavlix.net> <20110624162925.373a8ed4@neurotica.wooz.org> <1309966159.2169.46.camel@traveller.pavlix.net> Message-ID: <4E178598.9060307@msapiro.net> On 7/6/2011 8:29 AM, Pavel ?imerda wrote: > > The official documentation doesn't explicitly claim it. But there's a > section about setting up virtual domains that doesn't warn that virtual > domain implementation is incomplete: > > http://www.gnu.org/s/mailman/mailman-install/postfix-virtual.html I have added a note to the above that attempts to clarify this. > I, as a seasoned user of Postfix, Apache, and other virtualized server > software, but new user of Mailman, can confirm, that this documentation > made me think mailman fully supports virtual hosting. Unfortunately, > there are other resources on the web that are similarly confusing. If any of those resources are under control of the GNU Mailman project, and you tell us where they are, I will attempt to clarify them too. > With most of the patches already working, it doesn't look too hard to > add full virtual domain support to Mailman 2.x via address rewriting. I > fixed more issues on my installation myself. It might not be hard. Perhaps you could tell us exactly what you did to give us something to work with. However, please keep in mind that Mailman 2.1 is at the end of its life. The development focus is currently on Mailman 3. It is not a good use of development resources to implement a significant new feature in 2.1 that would undoubtedly lead to additional bug reports that would need to be addressed. I think a better approach would be to incorporate whatever additional fixes are necessary into the existing branch, or for you to publish your changes as an alternative branch. > Any way, I'd be very pleased if the documentation is ?fixed?, even if > its brokennes is not obvious to people who have lived with Mailman > for long time. What do you think of the change I made? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From pavlix at pavlix.net Sat Jul 9 02:49:53 2011 From: pavlix at pavlix.net (Pavel =?UTF-8?Q?=C5=A0imerda?=) Date: Sat, 09 Jul 2011 02:49:53 +0200 Subject: [Mailman-Developers] Mailman 2.x Virtual Hosting In-Reply-To: <4E178598.9060307@msapiro.net> References: <1308920783.3048.35.camel@traveller.pavlix.net> <20110624162925.373a8ed4@neurotica.wooz.org> <1309966159.2169.46.camel@traveller.pavlix.net> <4E178598.9060307@msapiro.net> Message-ID: <1310172593.22519.41.camel@traveller.pavlix.net> On Fri, 2011-07-08 at 15:32 -0700, Mark Sapiro wrote: > On 7/6/2011 8:29 AM, Pavel ?imerda wrote: > > > > The official documentation doesn't explicitly claim it. But there's a > > section about setting up virtual domains that doesn't warn that virtual > > domain implementation is incomplete: > > > > http://www.gnu.org/s/mailman/mailman-install/postfix-virtual.html > > > I have added a note to the above that attempts to clarify this. You were quick, thank you very much. > > I, as a seasoned user of Postfix, Apache, and other virtualized server > > software, but new user of Mailman, can confirm, that this documentation > > made me think mailman fully supports virtual hosting. Unfortunately, > > there are other resources on the web that are similarly confusing. > > > If any of those resources are under control of the GNU Mailman project, > and you tell us where they are, I will attempt to clarify them too. I believe these other places were outside the Mailman project. > > With most of the patches already working, it doesn't look too hard to > > add full virtual domain support to Mailman 2.x via address rewriting. I > > fixed more issues on my installation myself. > > > It might not be hard. Perhaps you could tell us exactly what you did to > give us something to work with. Ok, but I haven't made proper patches (yet). And these are quick and dirty fixes I made directly in the installed *.py files. I've made some changes to /var/lib/mailman/Mailman/MTA/Postfix.py to fix badly generated alias files for postfix: 144 print >> fp, '# STANZA START:', listname 145 print >> fp, '# CREATED:', time.ctime(time.time()) 146 # Now add all the standard alias entries 147 #### Fixed by pavlix at pavlix.net 148 if (mlist.host_name): 149 for ext in ('', '-admin', '-bounces', '-confirm', '-join', '-leave', 150 '-owner', '-request', '-subscribe', '-unsubscribe'): 151 fqdnaddr = '%s%s@%s' % (mlist.real_name, ext, mlist.host_name) 152 target = '%s-%s%s' % (mlist.real_name, mlist.host_name, ext) 153 badfqdnaddr = '%s@%s' % (target, mlist.host_name) 154 # Format the text file nicely 155 print >> fp, fqdnaddr, ((fieldsz - len(target)) * ' '), target 156 print >> fp, badfqdnaddr, ((fieldsz - len(target)) * ' '), target 157 # Finish the text file stanza 158 print >> fp, '# STANZA END:', listname 159 print >> fp And I fixed apparently broken part of /usr/lib/mailman/Mailman/MailList.py to include the correct address inside the messages: 187 def getListAddress(self, extra=None): 188 #### pavlix at pavlix.net # return '%s-%s@%s' % (self.internal_name(), extra, self.host_name) 189 posting_addr = self.internal_name() 190 try: 191 posting_addr = self.real_name.lower() 192 except: 193 pass 194 if extra is None: 195 return '%s@%s' % (posting_addr, self.host_name) 196 return '%s-%s@%s' % (posting_addr, extra, self.host_name) Please don't forget that I made these changes to Debian's Mailman package using patches from: https://wiki.koumbit.net/VirtualMailman > However, please keep in mind that Mailman 2.1 is at the end of its life. > The development focus is currently on Mailman 3. It is not a good use of > development resources to implement a significant new feature in 2.1 that > would undoubtedly lead to additional bug reports that would need to be > addressed. > > I think a better approach would be to incorporate whatever additional > fixes are necessary into the existing > branch, or for you > to publish your changes as an alternative branch. It sounds like a good idea. I actually tried to download from this branch first, but it didn't work for me (I don't remember the details, but AFAIK even the basic commands like newlist failed). I'll try to look at your version history and see what can be done to merge our modifications, when I have a little bit more time. > > Any way, I'd be very pleased if the documentation is ?fixed?, even if > > its brokennes is not obvious to people who have lived with Mailman > > for long time. > > > What do you think of the change I made? It's perfect, IMO. Pavel From mark at msapiro.net Sun Jul 10 02:41:03 2011 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 09 Jul 2011 17:41:03 -0700 Subject: [Mailman-Developers] Mailman 2.x Virtual Hosting In-Reply-To: <1310172593.22519.41.camel@traveller.pavlix.net> References: <1308920783.3048.35.camel@traveller.pavlix.net> <20110624162925.373a8ed4@neurotica.wooz.org> <1309966159.2169.46.camel@traveller.pavlix.net> <4E178598.9060307@msapiro.net> <1310172593.22519.41.camel@traveller.pavlix.net> Message-ID: <4E18F51F.70705@msapiro.net> On 7/8/2011 5:49 PM, Pavel ?imerda wrote: > On Fri, 2011-07-08 at 15:32 -0700, Mark Sapiro wrote: > > Ok, but I haven't made proper patches (yet). And these are quick and > dirty fixes I made directly in the installed *.py files. > > I've made some changes to /var/lib/mailman/Mailman/MTA/Postfix.py to fix > badly generated alias files for postfix: > > 144 print >> fp, '# STANZA START:', listname > 145 print >> fp, '# CREATED:', time.ctime(time.time()) > 146 # Now add all the standard alias entries > 147 #### Fixed by pavlix at pavlix.net > 148 if (mlist.host_name): > 149 for ext in ('', '-admin', '-bounces', '-confirm', '-join', > '-leave', > 150 '-owner', '-request', '-subscribe', > '-unsubscribe'): > 151 fqdnaddr = '%s%s@%s' % (mlist.real_name, ext, > mlist.host_name) > 152 target = '%s-%s%s' % (mlist.real_name, mlist.host_name, > ext) > 153 badfqdnaddr = '%s@%s' % (target, mlist.host_name) > 154 # Format the text file nicely > 155 print >> fp, fqdnaddr, ((fieldsz - len(target)) * ' '), > target > 156 print >> fp, badfqdnaddr, ((fieldsz - len(target)) * ' > '), target > 157 # Finish the text file stanza > 158 print >> fp, '# STANZA END:', listname > 159 print >> fp > > And I fixed apparently broken part > of /usr/lib/mailman/Mailman/MailList.py to include the correct address > inside the messages: > > 187 def getListAddress(self, extra=None): > 188 #### pavlix at pavlix.net # return '%s-%s@%s' % > (self.internal_name(), extra, self.host_name) > 189 posting_addr = self.internal_name() > 190 try: > 191 posting_addr = self.real_name.lower() > 192 except: > 193 pass > 194 if extra is None: > 195 return '%s@%s' % (posting_addr, self.host_name) > 196 return '%s-%s@%s' % (posting_addr, extra, self.host_name) > > Please don't forget that I made these changes to Debian's Mailman > package using patches from: > > https://wiki.koumbit.net/VirtualMailman I have just pushed some changes to the branch. I don't think this branch ever had the issue you fixed in MailList.py. It turns out it did have an issue with MTA/Postfix.py caused by the merge of post 2.1.13 changes. I have now fixed that and merged additional 2.1 branch changes, and I think bin/genaliases together with Mailman/MTA/Postfix.py is working properly in the vhost branch at rev 848. >> I think a better approach would be to incorporate whatever additional >> fixes are necessary into the existing >> branch, or for you >> to publish your changes as an alternative branch. > > It sounds like a good idea. I actually tried to download from this > branch first, but it didn't work for me (I don't remember the details, > but AFAIK even the basic commands like newlist failed). newlist would have failed after creating a virtual domain list because of the problem with MTA/Postfix.py. Other than that, I think it worked OK, but it is somewhat awkward. To create a virtual domain list you must use bin/newlist listname at email.domain and if the list's web domain is not lists.email.domain, you must use bin/newlist -u web.domain listname at email.domain This is not explained well in the newlist help text. > I'll try to look at your version history and see what can be done to > merge our modifications, when I have a little bit more time. That would be great. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From pabs3 at bonedaddy.net Sun Jul 10 23:07:29 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Sun, 10 Jul 2011 23:07:29 +0200 Subject: [Mailman-Developers] MM3: less generic names for scripts in $PATH? Message-ID: Hi all, I was looking at Mailman 3 to see how many of the Indymedia patches for Mailman 2 would be still needed. The first thing that struck me was how generic the files that were installed in $PATH. I would really recommend mm-master, mm-runner, mm-onebounce or similar instead of the current master, runner, onebounce. Could that be changed? -- bye, pabs From pabs3 at bonedaddy.net Mon Jul 11 00:22:57 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Mon, 11 Jul 2011 00:22:57 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? Message-ID: Hi all, For the Indymedia Mailman 2 install, we have a patch that allowed list disabling (and later re-enabling). Disabled lists had their settings/archives saved, did not accept mail and were listed on a separate page to listinfo. For a long-lived large mailman server serving local groups in many locations, management of the complete list life cycle was and still is essential for us. AFAICT Mailman 3 doesn't yet support such a concept, is that the case? If not, would it be acceptable to add that? Any pointers if I were to try and add that? -- bye, pabs From barry at list.org Mon Jul 11 17:40:32 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 11 Jul 2011 11:40:32 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: Message-ID: <20110711114032.2e32a7ed@resist.wooz.org> On Jul 11, 2011, at 12:22 AM, Paul Wise wrote: >For the Indymedia Mailman 2 install, we have a patch that allowed list >disabling (and later re-enabling). Disabled lists had their >settings/archives saved, did not accept mail and were listed on a >separate page to listinfo. For a long-lived large mailman server >serving local groups in many locations, management of the complete >list life cycle was and still is essential for us. > >AFAICT Mailman 3 doesn't yet support such a concept, is that the case? I've thought about this on and off over the years and still think it's a good idea. No, MM3 does not have such a thing yet. >If not, would it be acceptable to add that? Yep, but I'd like to understand the semantics first. Do messages to the list get bounced, and if so, by Mailman or the MTA? Currently, deleting a list does remove its configuration, but (by default) retains its archives, which can be deleted later. A disabled list would always have its archives available I think. >Any pointers if I were to try and add that? I think the core feature would not be too hard to implement, but some specifics would depend on answering the main question above. Here's an outline of what you'd probably need to touch: - IMailingList interface to add a `enabled` flag, along with (possibly) methods to disable and re-enable a list. It's possible that the flag would be a property and just setting `mlist.enabled = False` would be enough. - mailman.sql to add that flag to the schema. - MailingList model to plumb the flag through and implement the switching logic. - Add a new command class, probably in cli_lists.py to expose disable/enable to `bin/mailman`. Perhaps implement this as options on the existing `remove` command. - Plumb this through to the REST API, either by extended the AList class in src/mailman/rest/lists.py, or by exposing the flag in the ListConfiguration class in src/mailman/rest/configuration.py. - Tests and documentation! It sounds like a lot, but I'd think it's only a day or two of work, and I'm happy to answer questions, review code, etc. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Mon Jul 11 17:47:51 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 11 Jul 2011 11:47:51 -0400 Subject: [Mailman-Developers] MM3: less generic names for scripts in $PATH? In-Reply-To: References: Message-ID: <20110711114751.3bca7779@resist.wooz.org> On Jul 10, 2011, at 11:07 PM, Paul Wise wrote: >I was looking at Mailman 3 to see how many of the Indymedia patches >for Mailman 2 would be still needed. > >The first thing that struck me was how generic the files that were >installed in $PATH. I would really recommend mm-master, mm-runner, >mm-onebounce or similar instead of the current master, runner, >onebounce. Could that be changed? MM3 is already way better than MM2 because as you observe, we only have 4 top-level commands now. Almost everything that was a separate command in MM2 now lives under the uber-command `bin/mailman`. I don't much like the `mm-` prefix. Also, `onebounce` is just a helper, and actually it should go away once I've completed the refactoring of the bounce detector into a separate library (this is ongoing, but getting close to a 1.0 release). `master` and `runner` are a bit more problematic because they are pretty handy as separate commands. I don't think they belong under `bin/mailman` and since they're of internal use only, I would never expect them to be installed into /usr/bin. More likely any vendor package would put them under /usr/lib/mailman/bin in an FHS world. I'm not sure MM3 can function with `master` and `runner` under /usr/lib/mailman/bin but I would accept patches that made that work. (Or at least file a bug with a mailman3 tag). Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From pabs3 at bonedaddy.net Mon Jul 11 18:37:59 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Mon, 11 Jul 2011 18:37:59 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110711114032.2e32a7ed@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > I've thought about this on and off over the years and still think it's a good > idea. ?No, MM3 does not have such a thing yet. ... > Yep Ok, great. > but I'd like to understand the semantics first. ?Do messages to the list > get bounced, and if so, by Mailman or the MTA? ?Currently, deleting a list > does remove its configuration, but (by default) retains its archives, which > can be deleted later. ?A disabled list would always have its archives > available I think. With our current setup the disabled (or "graveyarded") list is removed from the /var/lib/mailman/lists dir and the aliases regenerated, so the MTA bounces messages to it and the admin interface for it cannot be logged into. Disabled lists are listed in a separate page in the web interface to the normal listinfo page. Some disabled lists might get their archives removed and some not. I think bouncing at the MTA is slightly sub-optimal and that mailman could generate a more informative bounce indicating how to contact the server admin to get the list revived. Probably in the web interface there could be a "disabled lists" category. Server admins would probably want to be able to login to the disabled lists in the web interface, but maybe not the list admins. > I think the core feature would not be too hard to implement, but some > specifics would depend on answering the main question above. ?Here's an > outline of what you'd probably need to touch: Thanks for the pointers, I will try that this week. -- bye, pabs From pabs3 at bonedaddy.net Mon Jul 11 18:40:43 2011 From: pabs3 at bonedaddy.net (Paul Wise) Date: Mon, 11 Jul 2011 18:40:43 +0200 Subject: [Mailman-Developers] MM3: less generic names for scripts in $PATH? In-Reply-To: <20110711114751.3bca7779@resist.wooz.org> References: <20110711114751.3bca7779@resist.wooz.org> Message-ID: On Mon, Jul 11, 2011 at 5:47 PM, Barry Warsaw wrote: > `master` and `runner` are a bit more problematic because they are pretty handy > as separate commands. ?I don't think they belong under `bin/mailman` and since > they're of internal use only, I would never expect them to be installed into > /usr/bin. ?More likely any vendor package would put them under > /usr/lib/mailman/bin in an FHS world. > > I'm not sure MM3 can function with `master` and `runner` under > /usr/lib/mailman/bin but I would accept patches that made that work. ?(Or at > least file a bug with a mailman3 tag). I'll take a look at that this week too since currently they are installed in $prefix/bin. -- bye, pabs From barry at list.org Mon Jul 11 20:12:19 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 11 Jul 2011 14:12:19 -0400 Subject: [Mailman-Developers] Install problems for mailman-3.0.0a7 on Debian Squeeze In-Reply-To: References: <1309966324.2169.48.camel@traveller.pavlix.net> Message-ID: <20110711141219.77ffc923@resist.wooz.org> On Jul 07, 2011, at 08:54 AM, Paul Wise wrote: >On Wed, Jul 6, 2011 at 5:32 PM, Pavel ?imerda wrote: > >> Wouldn't it be nice to have some more reasonable way to present this >> info to the user? > >Agreed. > >Does distutils have the equivalent of autoconf for checking for >dependencies before starting the build? Probably not without writing some custom code for setup.py. I'm not psyched about that though because it could be fragile, and won't play well in a packaging/distuils2 world. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From clayton.brown at blueberry.co.za Mon Jul 11 10:32:23 2011 From: clayton.brown at blueberry.co.za (Clayton Brown) Date: Mon, 11 Jul 2011 10:32:23 +0200 Subject: [Mailman-Developers] How to unsubscribe @example.com Message-ID: <001401cc3fa5$1144ff70$33cefe50$@co.za> Good Morning I am a mailman user and thank you. I would like to remove @example.com from a list of mine. Meaning, I want to remove all the email addresses that has @example domain from that list. How do I do this, cause If I have would have to unsubscribe them manually it would take me days. Thank You in advance. Clayton From mark at msapiro.net Tue Jul 12 03:11:37 2011 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 11 Jul 2011 18:11:37 -0700 Subject: [Mailman-Developers] How to unsubscribe @example.com In-Reply-To: <001401cc3fa5$1144ff70$33cefe50$@co.za> Message-ID: Clayton Brown wrote: > >I would like to remove @example.com from a list of mine. > > > >Meaning, I want to remove all the email addresses that has @example domain >from that list. > > > >How do I do this, cause If I have would have to unsubscribe them manually it >would take me days. You can do this in several ways. If you have command line access to the server, you can run something like the following pipe: bin/list_members LISTNAME | grep "@example\.com$" | bin/remove_members -f - LISTNAME If you don't have command line access, see the FAQ at for ways to obtain a list of members. edit that list to remove all but the @example.com members and use the result as input to the web admin Membership Management... -> Mass Removal function, or just go to the Membership Management... -> Membership List page and search for example.com and check all the unsub boxes in the result and submit. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From iane at sussex.ac.uk Tue Jul 12 15:06:42 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 12 Jul 2011 13:06:42 +0000 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> > > I think bouncing at the MTA is slightly sub-optimal and that mailman > could generate a more informative bounce indicating how to contact the > server admin to get the list revived. Probably in the web interface > there could be a "disabled lists" category. Server admins would > probably want to be able to login to the disabled lists in the web > interface, but maybe not the list admins. Bouncing certainly is suboptimal, since it may create collateral spam. Better to reject the message at SMTP time with a 5xx response than to bounce. However, it's probably possible to do what you want by putting the list on emergency moderation, and changing the message, is it not? Or something similar? If that is possible, then what's required is simply a web interface to simplify that process. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From barry at list.org Tue Jul 12 17:10:42 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 12 Jul 2011 11:10:42 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: <20110712111042.16c7ea71@resist.wooz.org> On Jul 11, 2011, at 06:37 PM, Paul Wise wrote: >With our current setup the disabled (or "graveyarded") list is removed >from the /var/lib/mailman/lists dir and the aliases regenerated, so >the MTA bounces messages to it and the admin interface for it cannot >be logged into. Disabled lists are listed in a separate page in the >web interface to the normal listinfo page. Some disabled lists might >get their archives removed and some not. I think this approach would actually be fairly easy to implement in the core, with additional ui considerations in the new web ui. It could be a matter of just adding the .enabled flag to mailing lists, and re-running the MM3 moral equivalent of genaliases when that flag changes. All the data associated with the mailing list would remain in the database. The web ui would then look at the .enabled flag to decide where and how to display the mailing list information, and whether to allow logins, etc. But it would still be able to get (and probably set) attributes on the mailing list. >I think bouncing at the MTA is slightly sub-optimal and that mailman >could generate a more informative bounce indicating how to contact the >server admin to get the list revived. Probably in the web interface >there could be a "disabled lists" category. Server admins would >probably want to be able to login to the disabled lists in the web >interface, but maybe not the list admins. Should you still be able to contact a disabled list's owners? I think if you're just going to bounce messages addressed to mydisabledlist-*@example.com and the text is static, then it's probably best to point those aliases to a very simple replybot service (I have one I've been toying with) so it doesn't increase the load on Mailman. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Tue Jul 12 17:11:59 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 12 Jul 2011 11:11:59 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> Message-ID: <20110712111159.0568812a@resist.wooz.org> On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote: >Bouncing certainly is suboptimal, since it may create collateral spam. Better >to reject the message at SMTP time with a 5xx response than to bounce. That's an interesting take on it. The LMTP server in Mailman could reject messages addressed to disabled lists, and that 5xx error should propagate through the MTA. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From benedict.stein at googlemail.com Tue Jul 12 17:22:45 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Tue, 12 Jul 2011 17:22:45 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712111042.16c7ea71@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <20110712111042.16c7ea71@resist.wooz.org> Message-ID: <1310484165.8923.7.camel@vaio-fe31m> Hi Barry, it's just a matter of seconds to add this enabled flag to the django webui, just let me know once it is in core. Am Dienstag, den 12.07.2011, 11:10 -0400 schrieb Barry Warsaw: > On Jul 11, 2011, at 06:37 PM, Paul Wise wrote: > > >With our current setup the disabled (or "graveyarded") list is removed > >from the /var/lib/mailman/lists dir and the aliases regenerated, so > >the MTA bounces messages to it and the admin interface for it cannot > >be logged into. Disabled lists are listed in a separate page in the > >web interface to the normal listinfo page. Some disabled lists might > >get their archives removed and some not. > > I think this approach would actually be fairly easy to implement in the core, > with additional ui considerations in the new web ui. It could be a matter of > just adding the .enabled flag to mailing lists, and re-running the MM3 moral > equivalent of genaliases when that flag changes. All the data associated with > the mailing list would remain in the database. > > The web ui would then look at the .enabled flag to decide where and how to > display the mailing list information, and whether to allow logins, etc. But > it would still be able to get (and probably set) attributes on the mailing > list. > > >I think bouncing at the MTA is slightly sub-optimal and that mailman > >could generate a more informative bounce indicating how to contact the > >server admin to get the list revived. Probably in the web interface > >there could be a "disabled lists" category. Server admins would > >probably want to be able to login to the disabled lists in the web > >interface, but maybe not the list admins. > > Should you still be able to contact a disabled list's owners? I think if > you're just going to bounce messages addressed to mydisabledlist-*@example.com > and the text is static, then it's probably best to point those aliases to a > very simple replybot service (I have one I've been toying with) so it doesn't > increase the load on Mailman. > > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/benedict.stein%40googlemail.com > > Security Policy: http://wiki.list.org/x/QIA9 -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From p at state-of-mind.de Tue Jul 12 17:23:41 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 12 Jul 2011 17:23:41 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712111159.0568812a@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> Message-ID: <20110712152341.GC22903@state-of-mind.de> * Barry Warsaw : > On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote: > > >Bouncing certainly is suboptimal, since it may create collateral spam. Better > >to reject the message at SMTP time with a 5xx response than to bounce. > > That's an interesting take on it. The LMTP server in Mailman could reject > messages addressed to disabled lists, and that 5xx error should propagate > through the MTA. Is disabling a list a temporary measure? If it is, should the server reply a temporary error? 421 Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) Or is it permanent? 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) p at rick -- state of mind () Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From fmouse at fmp.com Tue Jul 12 17:44:35 2011 From: fmouse at fmp.com (Lindsay Haisley) Date: Tue, 12 Jul 2011 10:44:35 -0500 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712152341.GC22903@state-of-mind.de> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> Message-ID: <1310485475.1886.43.camel@ubuntu> On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote: > Is disabling a list a temporary measure? If it is, should the server reply a > temporary error? In my humble opinion, an intentionally disabled list should cause the mail system to generate a 500 class error (permanent error). 400 class errors (temporary errors) are generally reserved for situations where the _intention_ is that the mail should go through but is prevented from doing so by problems for which a solution is in progress. A 400 class error causes the originating system to cache and re-try delivery, so if a list returns a 400 class error, it's just "delayed", not truly "disabled". This may be a fine distinction, and if a list is disabled for technical reasons with the intention of bringing it back up in short order without losing traffic, then perhaps a 400 class error would be more appropriate. -- Lindsay Haisley | "We have met the enemy, and it is us." FMP Computer Services | 512-259-1190 | -- Pogo http://www.fmp.com | From p at state-of-mind.de Tue Jul 12 20:52:02 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 12 Jul 2011 20:52:02 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <1310485475.1886.43.camel@ubuntu> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> Message-ID: <20110712185202.GA2265@state-of-mind.de> * Lindsay Haisley : > On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote: > > Is disabling a list a temporary measure? If it is, should the server reply a > > temporary error? > > In my humble opinion, an intentionally disabled list should cause the > mail system to generate a 500 class error (permanent error). 400 class > errors (temporary errors) are generally reserved for situations where > the _intention_ is that the mail should go through but is prevented from > doing so by problems for which a solution is in progress. A 400 class > error causes the originating system to cache and re-try delivery, so if > a list returns a 400 class error, it's just "delayed", not truly > "disabled". This may be a fine distinction, and if a list is disabled ACK. Looking at the available codes I guess the best return code would probably be 550: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) p at rick -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From barry at list.org Tue Jul 12 22:39:55 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 12 Jul 2011 16:39:55 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712185202.GA2265@state-of-mind.de> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> Message-ID: <20110712163955.4838dcf1@resist.wooz.org> On Jul 12, 2011, at 08:52 PM, Patrick Ben Koetter wrote: > 550 Requested action not taken: mailbox unavailable (e.g., mailbox > not found, no access, or command rejected for policy reasons) > > Codes in Numeric Order> That would be my preference too. I recently had a use case for something like this. The import-sig on python.org was retired a few years ago, but I just resurrected it for the PEP 382 discussion. I probably would have used this feature for these sigs. It does lead me to think that "retired" might be a better term, and it makes me wonder whether actions like subscribing to a retired list would still be allowed. But maybe the OP has a different use case in mind and we could have a need for both a long-term, permanently failing retired lists, and shorter term, temporarily failing disabled lists. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Wed Jul 13 06:34:33 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 13 Jul 2011 13:34:33 +0900 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712163955.4838dcf1@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> Message-ID: <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > But maybe the OP has a different use case in mind and we could have a need for > both a long-term, permanently failing retired lists, and shorter term, > temporarily failing disabled lists. I don't really understand under what circumstances a list owner would want to disable the *whole list* and at the same time leave retries up to arbitrary MTAs out on the Internet. The poster may or may not get a DSN. Etc, etc. OTOH, I can imagine that for some purposes you might want a different status code, and I don't see any good reason for making that configurable and then restricting it to 5xx. Rather, document it as "this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with sufficient reason it could be a 4xx code, but we don't know of any examples offhand :-)." From iane at sussex.ac.uk Wed Jul 13 13:38:11 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 13 Jul 2011 11:38:11 +0000 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110712111159.0568812a@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> Message-ID: <8E1019EF-E258-4D94-B9D6-B703FC419452@sussex.ac.uk> On 12 Jul 2011, at 16:11, Barry Warsaw wrote: > On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote: > >> Bouncing certainly is suboptimal, since it may create collateral spam. Better >> to reject the message at SMTP time with a 5xx response than to bounce. > > That's an interesting take on it. The LMTP server in Mailman could reject > messages addressed to disabled lists, and that 5xx error should propagate > through the MTA. Yes, this should be used in combination with a call forward from the MTA at RCTP TO, so that it the MTA can determine the status of the mailing list *before* giving a reply to the sending MTA. > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/iane%40sussex.ac.uk > > Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From pabs at debian.org Wed Jul 13 16:51:04 2011 From: pabs at debian.org (Paul Wise) Date: Wed, 13 Jul 2011 16:51:04 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110711114032.2e32a7ed@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > It sounds like a lot, but I'd think it's only a day or two of work, and I'm > happy to answer questions, review code, etc. I would like to get the design right first, after reading the full thread a couple of times, some thoughts: By bounce I meant SMTP-time rejection, sounds like the LMTP stuff provides that (and mailman 2 doesn't use that IIRC). Temporarily failing lists were not an objective. The design of list objects seems to be heavily similar to how the UI is in mailman 2, I think it should be much more generic. For example: In the web UI turning on emergency moderation should set the first item in the receive pipeline to a hold() function. Disabling a list would set the first item in the receive pipeline to reject_disabled, set the first item in the subscription pipeline to reject_disabled, set the first item in the settings pipeline to admin_read_only etc. List objects should be flexible to support different kinds of lists, but the UI should hide most of that behind simple labels like "retired list", "public list", "private list" and the "emergency moderation" button. PS: Is there a Mailman UI yet? The link on the Mailman branches wiki page points to one with only one commit in it and no working code. PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm thinking configuration filenames, data directories etc should be named mailman3 instead of mailman. -- bye, pabs From benedict.stein at googlemail.com Wed Jul 13 17:20:27 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Wed, 13 Jul 2011 17:20:27 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: <1310570427.2500.69.camel@vaio-fe31m> HI Paul, or all others who want to get involved into mm3 WebUI development. I'm closly listening your dicsussion. The WebUI is work in progress and there is nothing stable yet. However if you're interested taking a look at the dev snippets take a look at the following branches: https://code.edge.launchpad.net/mailmanwebgsoc2011 Feel free to contact Flo or me on IRC (#benste) PS: Little tutorial on how to get it running: http://wiki.list.org/pages/viewpage.action?pageId=11960560 Please really keep in mind these are only suggested peaces of work which don't even cover all basic functionallity. Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise: > On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > > > It sounds like a lot, but I'd think it's only a day or two of work, and I'm > > happy to answer questions, review code, etc. > > I would like to get the design right first, after reading the full > thread a couple of times, some thoughts: > > By bounce I meant SMTP-time rejection, sounds like the LMTP stuff > provides that (and mailman 2 doesn't use that IIRC). > > Temporarily failing lists were not an objective. > > The design of list objects seems to be heavily similar to how the UI > is in mailman 2, I think it should be much more generic. > > For example: > > In the web UI turning on emergency moderation should set the first > item in the receive pipeline to a hold() function. > > Disabling a list would set the first item in the receive pipeline to > reject_disabled, set the first item in the subscription pipeline to > reject_disabled, set the first item in the settings pipeline to > admin_read_only etc. > > List objects should be flexible to support different kinds of lists, > but the UI should hide most of that behind simple labels like "retired > list", "public list", "private list" and the "emergency moderation" > button. > > PS: Is there a Mailman UI yet? The link on the Mailman branches wiki > page points to one with only one commit in it and no working code. > > PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm > thinking configuration filenames, data directories etc should be named > mailman3 instead of mailman. > -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From benedict.stein at googlemail.com Wed Jul 13 18:15:08 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Wed, 13 Jul 2011 18:15:08 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: <1310573708.2500.80.camel@vaio-fe31m> HI Paul, or all others who want to get involved into mm3 WebUI development. I'm closly listening your dicsussion. The WebUI is work in progress and there is nothing stable yet. However if you're interested taking a look at the dev snippets take a look at the following branches: https://code.edge.launchpad.net/mailmanwebgsoc2011 Feel free to contact Flo or me on IRC (#benste) PS: Little tutorial on how to get it running: http://wiki.list.org/pages/viewpage.action?pageId=11960560 Please really keep in mind th Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise: > On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > > > It sounds like a lot, but I'd think it's only a day or two of work, and I'm > > happy to answer questions, review code, etc. > > I would like to get the design right first, after reading the full > thread a couple of times, some thoughts: > > By bounce I meant SMTP-time rejection, sounds like the LMTP stuff > provides that (and mailman 2 doesn't use that IIRC). > > Temporarily failing lists were not an objective. > > The design of list objects seems to be heavily similar to how the UI > is in mailman 2, I think it should be much more generic. > > For example: > > In the web UI turning on emergency moderation should set the first > item in the receive pipeline to a hold() function. > > Disabling a list would set the first item in the receive pipeline to > reject_disabled, set the first item in the subscription pipeline to > reject_disabled, set the first item in the settings pipeline to > admin_read_only etc. > > List objects should be flexible to support different kinds of lists, > but the UI should hide most of that behind simple labels like "retired > list", "public list", "private list" and the "emergency moderation" > button. > > PS: Is there a Mailman UI yet? The link on the Mailman branches wiki > page points to one with only one commit in it and no working code. > > PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm > thinking configuration filenames, data directories etc should be named > mailman3 instead of mailman. > -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From clayton.brown at blueberry.co.za Thu Jul 14 10:18:03 2011 From: clayton.brown at blueberry.co.za (Clayton Brown) Date: Thu, 14 Jul 2011 10:18:03 +0200 Subject: [Mailman-Developers] A subscribe link Message-ID: <000b01cc41fe$8f93f9c0$aebbed40$@co.za> Good Morning Mailman Developers I would like to know the following: I want to send out an cleansing email to a list that I have, on the cleansing email there must be a subscribe link. When a recipient clicks on the subscribe link the recipient will automatically be transferred into a new list called subscriptions. Afterwards I have a subscriptions list and the old list which will be deleted. Alternatively is there some way Mailman can put the recipient's email address in a variable in the email the recipient is receiving. Example: There must be a link on the cleansing email that looks like this: Opt In It will be then easy for me to subscribe the recipient into a subscribe database and just create a list afterwards. The main point here is, that when the recipient clicks on the 'Opt-in' link their email address must automatically be captured, thus removing a step where they will be navigated to a page where they must first fill in their email address to be subscribed. I am in inexperience php developer, if there is a way that you know off where I can capture the email's headers please let me know. Please remember the way Mailman works in regards to posting an email. Does it allow for php in the code or only HTML? Thank You in advance Clayton Brown From mark at msapiro.net Fri Jul 15 01:22:06 2011 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 14 Jul 2011 16:22:06 -0700 Subject: [Mailman-Developers] A subscribe link In-Reply-To: <000b01cc41fe$8f93f9c0$aebbed40$@co.za> References: <000b01cc41fe$8f93f9c0$aebbed40$@co.za> Message-ID: <4E1F7A1E.70202@msapiro.net> On 7/14/2011 1:18 AM, Clayton Brown wrote: > > Example: There must be a link on the cleansing email that looks like this: > Opt In > It will be then easy for me to subscribe the recipient into a subscribe > database and just create a list afterwards. If the installation has set OWNERS_CAN_ENABLE_PERSONALIZATION = Yes in mm_cfg.py so that the 'personalize' settings appear on the list admin Non-digest options page and personalize is set to Yes, then either the replacement %(user_address)s or %(user_delivered_to)s can be used in either msg_header or msg_footer to receive either the user's lower-cased email address or case-preserved email address respectively. Those replacements work only in msg_header and msg_footer. They don't work in the message body and they don't work in digests. E.g. You could put Opt-in in msg_footer. This may or may not be rendered as an active link depending on the users MUA. You can't put an HTML tag in msg_header or msg_footer, because it will always be in a text/plain part of the message. [...] > I am in inexperience php developer, if there is a way that you know off > where I can capture the email's headers please let me know. Please remember > the way Mailman works in regards to posting an email. Does it allow for php > in the code or only HTML? I don't understand what you are asking here, but see the FAQs at and . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Fri Jul 15 21:12:59 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 15 Jul 2011 15:12:59 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20110715151259.71b9975b@resist.wooz.org> On Jul 13, 2011, at 01:34 PM, Stephen J. Turnbull wrote: >Barry Warsaw writes: > > > But maybe the OP has a different use case in mind and we could have a need for > > both a long-term, permanently failing retired lists, and shorter term, > > temporarily failing disabled lists. > >I don't really understand under what circumstances a list owner would >want to disable the *whole list* and at the same time leave retries up >to arbitrary MTAs out on the Internet. The poster may or may not get >a DSN. Etc, etc. I agree. I think I like the term "retire" better than "disable" to more clearly designate a step in a list's life between active and deleted. A retired list would still exist, and people could (maybe?) still subscribe to it, etc. I think the core wouldn't treat retired lists much different than active lists except to either omit its aliases from regeneration, or give the appropriate LMTP code. One thing to think about is how MTAs like Exim will work since they don't use an alias file. >OTOH, I can imagine that for some purposes you might want a different >status code, and I don't see any good reason for making that >configurable and then restricting it to 5xx. Rather, document it as >"this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with >sufficient reason it could be a 4xx code, but we don't know of any >examples offhand :-)." Do you really think it needs to be configurable? I mean, if we can't think of a reason to not make it 5xx, why not just wait for the first wishlist bug report? :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From p at state-of-mind.de Fri Jul 15 21:23:09 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Fri, 15 Jul 2011 21:23:09 +0200 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110715151259.71b9975b@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> <20110715151259.71b9975b@resist.wooz.org> Message-ID: <20110715192309.GB2544@state-of-mind.de> * Barry Warsaw : > >OTOH, I can imagine that for some purposes you might want a different > >status code, and I don't see any good reason for making that > >configurable and then restricting it to 5xx. Rather, document it as > >"this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with > >sufficient reason it could be a 4xx code, but we don't know of any > >examples offhand :-)." > > Do you really think it needs to be configurable? I mean, if we can't think of > a reason to not make it 5xx, why not just wait for the first wishlist bug > report? :) A configurable reply could provide a hint along the 550 like this: 550 See: http://list.example.com/550/listname The listname ressource could inform why the list was retired e.g. because it was relocated or closed or where to find the retired lists archives ... p at rick -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From barry at list.org Fri Jul 15 21:24:19 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 15 Jul 2011 15:24:19 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: References: <20110711114032.2e32a7ed@resist.wooz.org> Message-ID: <20110715152419.10bc890d@resist.wooz.org> On Jul 13, 2011, at 04:51 PM, Paul Wise wrote: >By bounce I meant SMTP-time rejection, sounds like the LMTP stuff >provides that (and mailman 2 doesn't use that IIRC). Correct. >Temporarily failing lists were not an objective. Cool, I think we're agreed on that. >The design of list objects seems to be heavily similar to how the UI >is in mailman 2, I think it should be much more generic. > >For example: > >In the web UI turning on emergency moderation should set the first >item in the receive pipeline to a hold() function. > >Disabling a list would set the first item in the receive pipeline to >reject_disabled, set the first item in the subscription pipeline to >reject_disabled, set the first item in the settings pipeline to >admin_read_only etc. This isn't exactly how MM3 works. In MM3, the incoming queue sends the message through a chain, where each link has a rule and an action. An action can be something like "jump to the `hold` chain", which is in fact exactly what happens in the default built-in chain: src/mailman/chains/builtin.py: _link_descriptions = ( ('approved', LinkAction.jump, 'accept'), ('emergency', LinkAction.jump, 'hold'), ... There really aren't "subscription" or "settings" pipelines, and I'm not sure they're the right way to implement what you have in mind. >List objects should be flexible to support different kinds of lists, >but the UI should hide most of that behind simple labels like "retired >list", "public list", "private list" and the "emergency moderation" >button. MM3 has list styles, which are composeable and extensible. A style is only applied at list creation time though. >PS: Is there a Mailman UI yet? The link on the Mailman branches wiki >page points to one with only one commit in it and no working code. I think we're still waiting for Florian and the GSoC students to propose branch merges into lp:mailmanweb. >PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm >thinking configuration filenames, data directories etc should be named >mailman3 instead of mailman. Maybe. I'd really like to not do that if it can be avoided. For example, the configuration system is so different I can't see how there would be much collision. The data directories, possibly, but I also think there are enough knobs to allow site admins or vendor packagers to set things up with the proper defaults. I don't think there will be any collisions on command line program names. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Jul 15 21:31:08 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 15 Jul 2011 15:31:08 -0400 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110715192309.GB2544@state-of-mind.de> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> <20110715151259.71b9975b@resist.wooz.org> <20110715192309.GB2544@state-of-mind.de> Message-ID: <20110715153108.56170715@resist.wooz.org> On Jul 15, 2011, at 09:23 PM, Patrick Ben Koetter wrote: >A configurable reply could provide a hint along the 550 like this: > > 550 See: http://list.example.com/550/listname > >The listname ressource could inform why the list was retired e.g. because it >was relocated or closed or where to find the retired lists archives ... That's not a bad idea. So, we'd definitely want to record a reason for the status change to "retired". -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Sat Jul 16 08:18:41 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 16 Jul 2011 15:18:41 +0900 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <20110715151259.71b9975b@resist.wooz.org> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> <20110715151259.71b9975b@resist.wooz.org> Message-ID: <87oc0usq7y.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > Do you really think it needs to be configurable? I mean, if we > can't think of a reason to not make it 5xx, why not just wait for > the first wishlist bug report? :) No, on second thought after reviewing the codes, the only appropriate 5xx code is 550. So there's no reason I can think of for configurability at this point. From clayton.brown at blueberry.co.za Mon Jul 18 11:54:11 2011 From: clayton.brown at blueberry.co.za (Clayton Brown) Date: Mon, 18 Jul 2011 11:54:11 +0200 Subject: [Mailman-Developers] FW: A subscribe link Message-ID: <003101cc4530$a827a920$f876fb60$@co.za> Hello Developers at Mailman Thank you for your advice below, this solves my problem but also creates a new problem. The mobility of %(user_delivered_to)s is the issue. Is there something like an msg_body, where you can compile the html letter and insert %(user_delivered_to)s. That would obv be perfect. Right now I have the issue of the msg_footer being inserted as an attachment, but I have found a solution for that on the internet. MIMEDefang... you obv know what I am talking about. Msg_header does not work in MS office, but that won't work either because it will be at the top of the emailer. See attachment. Please let me know what you think. Thanks in advance -----Original Message----- From: Mark Sapiro [mailto:mark at msapiro.net] Sent: 15 July 2011 01:22 AM To: Clayton Brown Cc: mailman-developers at python.org Subject: Re: [Mailman-Developers] A subscribe link On 7/14/2011 1:18 AM, Clayton Brown wrote: > > Example: There must be a link on the cleansing email that looks like this: > Opt In > It will be then easy for me to subscribe the recipient into a subscribe > database and just create a list afterwards. If the installation has set OWNERS_CAN_ENABLE_PERSONALIZATION = Yes in mm_cfg.py so that the 'personalize' settings appear on the list admin Non-digest options page and personalize is set to Yes, then either the replacement %(user_address)s or %(user_delivered_to)s can be used in either msg_header or msg_footer to receive either the user's lower-cased email address or case-preserved email address respectively. Those replacements work only in msg_header and msg_footer. They don't work in the message body and they don't work in digests. E.g. You could put Opt-in in msg_footer. This may or may not be rendered as an active link depending on the users MUA. You can't put an HTML tag in msg_header or msg_footer, because it will always be in a text/plain part of the message. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- A non-text attachment was scrubbed... Name: Opt-In-mailer.jpg Type: image/jpeg Size: 61930 bytes Desc: not available URL: From mark at msapiro.net Tue Jul 19 02:00:36 2011 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 18 Jul 2011 17:00:36 -0700 Subject: [Mailman-Developers] FW: A subscribe link In-Reply-To: <003101cc4530$a827a920$f876fb60$@co.za> Message-ID: Clayton Brown wrote: > >Thank you for your advice below, this solves my problem but also creates a >new problem. > >The mobility of %(user_delivered_to)s is the issue. Is there something like >an msg_body, where you can compile the html letter and insert >%(user_delivered_to)s. That would obv be perfect. No. There is no existing mechanism in Mailman to add replacements or insert text into HTML message bodies/parts. >Right now I have the issue of the msg_footer being inserted as an >attachment, but I have found a solution for that on the internet. >MIMEDefang... you obv know what I am talking about. Perhaps you have seen the FAQ at and the information linked from that about using MIMEDefang. >Msg_header does not work in MS office, but that won't work either because it >will be at the top of the emailer. See attachment. And will have the same issues as the 'attached' footer or worse will be treated by the MUA as the message body with the true message body treated as an attachment. >Please let me know what you think. If putting your link with replacements in msg_footer along with the MIMEDefang solution documented at works for you, then you have a solution. If not, there's not much else you can do without actually modifying the Mailman/Handlers/Decorate.py handler to modify the HTML message body per recipient. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From clayton.brown at blueberry.co.za Tue Jul 19 08:42:37 2011 From: clayton.brown at blueberry.co.za (Clayton Brown) Date: Tue, 19 Jul 2011 08:42:37 +0200 Subject: [Mailman-Developers] FW: A subscribe link, ATT Mark Sapiro In-Reply-To: References: <003101cc4530$a827a920$f876fb60$@co.za> Message-ID: <000301cc45df$0f8d6510$2ea82f30$@co.za> I understand your comments below and suspected such an answer. Let me ask you this, you know what our needs are. I we were to ask you to code/modify mailman to our needs, would you do this? -----Original Message----- From: Mark Sapiro [mailto:mark at msapiro.net] Sent: 19 July 2011 02:01 AM To: Clayton Brown; mailman-developers at python.org Subject: Re: [Mailman-Developers] FW: A subscribe link Clayton Brown wrote: > >Thank you for your advice below, this solves my problem but also creates a >new problem. > >The mobility of %(user_delivered_to)s is the issue. Is there something like >an msg_body, where you can compile the html letter and insert >%(user_delivered_to)s. That would obv be perfect. No. There is no existing mechanism in Mailman to add replacements or insert text into HTML message bodies/parts. >Right now I have the issue of the msg_footer being inserted as an >attachment, but I have found a solution for that on the internet. >MIMEDefang... you obv know what I am talking about. Perhaps you have seen the FAQ at and the information linked from that about using MIMEDefang. >Msg_header does not work in MS office, but that won't work either because it >will be at the top of the emailer. See attachment. And will have the same issues as the 'attached' footer or worse will be treated by the MUA as the message body with the true message body treated as an attachment. >Please let me know what you think. If putting your link with replacements in msg_footer along with the MIMEDefang solution documented at works for you, then you have a solution. If not, there's not much else you can do without actually modifying the Mailman/Handlers/Decorate.py handler to modify the HTML message body per recipient. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Wed Jul 20 05:22:02 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 19 Jul 2011 23:22:02 -0400 Subject: [Mailman-Developers] FW: A subscribe link, ATT Mark Sapiro In-Reply-To: <000301cc45df$0f8d6510$2ea82f30$@co.za> References: <003101cc4530$a827a920$f876fb60$@co.za> <000301cc45df$0f8d6510$2ea82f30$@co.za> Message-ID: <20110719232202.047670c4@resist.wooz.org> On Jul 19, 2011, at 08:42 AM, Clayton Brown wrote: >I understand your comments below and suspected such an answer. > >Let me ask you this, you know what our needs are. > >I we were to ask you to code/modify mailman to our needs, would you do this? It's something that I think would be an interesting add-on for Mailman 3. The way I've rewritten the delivery modules, I think it wouldn't be too hard to add a mail-merge type functionality, as a subclass of IndividualDelivery. The tricky parts would be enabling it on specific mailing lists (as opposed to across the board), and defining a configuration that merges what Mailman knows about the user, with some external database of additional personalized data. If you think you'd like to experiment with this, I'd be happy to flesh it out further. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mark at msapiro.net Wed Jul 20 05:36:57 2011 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 19 Jul 2011 20:36:57 -0700 Subject: [Mailman-Developers] FW: A subscribe link, ATT Mark Sapiro In-Reply-To: <000301cc45df$0f8d6510$2ea82f30$@co.za> References: <003101cc4530$a827a920$f876fb60$@co.za> <000301cc45df$0f8d6510$2ea82f30$@co.za> Message-ID: <4E264D59.1010101@msapiro.net> On 7/18/2011 11:42 PM, Clayton Brown wrote: > I understand your comments below and suspected such an answer. > > Let me ask you this, you know what our needs are. > > I we were to ask you to code/modify mailman to our needs, would you do this? Attached is the file Decorate.patch. If you apply this patch to Mailman/Handlers/Decorate.py and restart Mailman, you can then do the following: Create a file named 'body_template' in Mailman's lists/LISTNAME/ directory where LISTNAME is the name of a list that you want to add HTML text to. The contents of the 'body_template' file can contain the same replacements that can be used in msg_header or msg_footer. I.e. if and only if the list is personalized, you can use replacements like %(user_address)s and %(user_delivered_to)s. The contents of the 'body_template' file should be valid HTML and probably should be a
...
division. It should be us-ascii with non-ascii characters represented as HTML entities to avoid clashes with the character set of the message body. If you want a literal '%' character in the HTML, it must be doubled ('%%') in the 'body_template' file so as not to be misinterpreted as a replacement leadin. The group of the 'body_template' file should be Mailman's group and the file group readable. If you do that, the contents of the 'body_template' file with the replacements appropriately replaced will be appended to the first text/html part found in the message if there is one (or inserted in front of a tag if any). If the list has a msg_header or msg_footer, those will still be added to the message as separate MIME parts (unless the message is simple text/plain), so you probably want to empty those. Note that depending on the original HTML, there is no guarantee that this division will be rendered appropriately at the end of the message just because it is added at the end of the HTML. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Decorate.patch URL: From iane at sussex.ac.uk Wed Jul 20 12:38:23 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 20 Jul 2011 10:38:23 +0000 Subject: [Mailman-Developers] MM3: list disabling/enabling? In-Reply-To: <87oc0usq7y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20110711114032.2e32a7ed@resist.wooz.org> <6CBD386B-30E6-4F4C-9EC9-E8D1A277CF04@sussex.ac.uk> <20110712111159.0568812a@resist.wooz.org> <20110712152341.GC22903@state-of-mind.de> <1310485475.1886.43.camel@ubuntu> <20110712185202.GA2265@state-of-mind.de> <20110712163955.4838dcf1@resist.wooz.org> <87bowyu7c6.fsf@uwakimon.sk.tsukuba.ac.jp> <20110715151259.71b9975b@resist.wooz.org> <87oc0usq7y.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 16 Jul 2011, at 07:18, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> Do you really think it needs to be configurable? I mean, if we >> can't think of a reason to not make it 5xx, why not just wait for >> the first wishlist bug report? :) > > No, on second thought after reviewing the codes, the only appropriate > 5xx code is 550. So there's no reason I can think of for > configurability at this point. Sure, 550 is appropriate, but an rfc1893/2034 enhanced error code should be used, too. These might be useful: X.1.0 Other address status X.1.6 Destination mailbox has moved, No forwarding address X.2.1 Mailbox disabled, not accepting messages Also, there's a case for customising the text returned, if not the error code. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From benedict.stein at googlemail.com Wed Jul 20 17:32:42 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Wed, 20 Jul 2011 17:32:42 +0200 Subject: [Mailman-Developers] tomorrow - discussion on how / where to implement ACL Message-ID: <1311175962.6289.11.camel@vaio-fe31m> Hi, this IRC meeting will be about implementation of ACL which i do need for the mailmanwebUI. Everyone who is interested in this topic might be join the discussion on IRC tomorrow. https://www.google.com/calendar/event?action=TEMPLATE&tmeid=MGlzZm1tNjg5OGRuaXFvcHRtMG05azNybDAgYmVuZWRpY3Quc3RlaW5AbQ&tmsrc=benedict.stein%40gmail.com -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From barry at list.org Wed Jul 20 20:23:07 2011 From: barry at list.org (Barry Warsaw) Date: Wed, 20 Jul 2011 14:23:07 -0400 Subject: [Mailman-Developers] tomorrow - discussion on how / where to implement ACL In-Reply-To: <1311175962.6289.11.camel@vaio-fe31m> References: <1311175962.6289.11.camel@vaio-fe31m> Message-ID: <20110720142307.4c6f1e31@resist.wooz.org> On Jul 20, 2011, at 05:32 PM, Benedict Stein wrote: >Hi, >this IRC meeting will be about implementation of ACL which i do need for >the mailmanwebUI. >Everyone who is interested in this topic might be join the discussion on >IRC tomorrow. > >https://www.google.com/calendar/event?action=TEMPLATE&tmeid=MGlzZm1tNjg5OGRuaXFvcHRtMG05azNybDAgYmVuZWRpY3Quc3RlaW5AbQ&tmsrc=benedict.stein%40gmail.com Hi benste, Could you please confirm the time of the meeting in UTC? I've seen two different invites, and this Google event comes up in yet a third time slot. Are we on for 1330 UTC? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From benedict.stein at googlemail.com Thu Jul 21 17:42:09 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Thu, 21 Jul 2011 17:42:09 +0200 Subject: [Mailman-Developers] ACL,security - how we'll implement it Message-ID: <1311262929.14544.1.camel@vaio-fe31m> Dear Mailman Developers, we had a nice discussion this afternoon (13:00 - 15:00) UTC about this topic. I've written a small blogposts about the results which will be implemented in near future. http://benste.blogspot.com/2011/07/discussion-on-acls-using-mailman30-and.html Key aspects: Decided to use a Proxy which: * is responsible for exposing the user roles * using it's own DB * customizable to querry others - e.g. Launchpad * needs to be authenticated at the Core using REST-API (might get https) * similar API to REST, but requiring a username to each request * each request will be handled based on username is already authenticated - e.g in a web-session * will be able to raise HTTP401 (access denied) if user is not allowed to do this action / get this option * might authenticate users based on a request(user;pswd) Python Bindings for REST will be able to use both either Proxyed REST or direct access to Rest depending on wheter the UI decides to use it with a User object. direct REST-API Calls will only be able on localhost -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From barry at list.org Thu Jul 28 20:56:06 2011 From: barry at list.org (Barry Warsaw) Date: Thu, 28 Jul 2011 14:56:06 -0400 Subject: [Mailman-Developers] wiki.list.org license has been renewed Message-ID: <20110728145606.116e0b49@resist.wooz.org> I think I've managed to get our Confluence license renewed, so those of you with write privileges to wiki.list.org should be able to save pages again. If not, please let me know. I haven't heard much about the Moin conversion lately, but hopefully that will happen before the next time our license runs out. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From bjdean at bjdean.id.au Fri Jul 29 01:23:09 2011 From: bjdean at bjdean.id.au (Bradley Dean) Date: Fri, 29 Jul 2011 09:23:09 +1000 Subject: [Mailman-Developers] [Mailman-Announce] wiki.list.org license has been renewed In-Reply-To: <20110728145606.116e0b49@resist.wooz.org> References: <20110728145606.116e0b49@resist.wooz.org> Message-ID: <4E31EF5D.7050509@bjdean.id.au> Hi folks, On 29/07/11 04:56, Barry Warsaw wrote: > I haven't heard much about the Moin conversion lately, but hopefully that will > happen before the next time our license runs out. Still working through it - sorry it's taking longer than hoped but the confluence XML is, well, interesting: * http://lists.bjdean.id.au/pipermail/mmwiki/2011q3/000067.html * http://lists.bjdean.id.au/pipermail/mmwiki/2011q3/000068.html * http://moinmo.in/ConfluenceConverter/DevelopmentNotes/TransformProcess#Confluence_Dump_XML We've also had a little less input from members of the assembled team. Now that I think I've got the XML structure pinned down I'll get stuck in to the content extraction and transformation. Cheerio, Brad -- Bradley Dean Email: bjdean at bjdean.id.au Skype: skype at bjdean.id.au Mobile(Aus): +61-413014395 WWW: http://bjdean.id.au/ From barry at list.org Fri Jul 29 01:34:31 2011 From: barry at list.org (Barry Warsaw) Date: Thu, 28 Jul 2011 19:34:31 -0400 Subject: [Mailman-Developers] [Mailman-Announce] wiki.list.org license has been renewed In-Reply-To: <4E31EF5D.7050509@bjdean.id.au> References: <20110728145606.116e0b49@resist.wooz.org> <4E31EF5D.7050509@bjdean.id.au> Message-ID: <20110728193431.5d0df560@resist.wooz.org> On Jul 29, 2011, at 09:23 AM, Bradley Dean wrote: >On 29/07/11 04:56, Barry Warsaw wrote: >> I haven't heard much about the Moin conversion lately, but hopefully that will >> happen before the next time our license runs out. > >Still working through it - sorry it's taking longer than hoped but the confluence XML is, well, interesting: > > * http://lists.bjdean.id.au/pipermail/mmwiki/2011q3/000067.html > * http://lists.bjdean.id.au/pipermail/mmwiki/2011q3/000068.html > * http://moinmo.in/ConfluenceConverter/DevelopmentNotes/TransformProcess#Confluence_Dump_XML > >We've also had a little less input from members of the assembled team. Now that I think I've got the XML structure pinned down I'll get stuck in to the content extraction and transformation. Thanks for the update! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: