Re: [Mailman-Users] Somebody could not subscribe to pypy-...@python.org

[Laura Creighton]

In a message of Tue, 21 Apr 2015 16:31:46 -0700, Mark Sapiro writes:
>On 04/21/2015 03:55 PM, Laura Creighton wrote:
>> Forwarded message here.  He just tried to subscribe as ben.jol...@xad.com
>> but apparantly can only subscribe if he leaves the password field blank.
>> 
>> It is, of course, working just fine for me.
>
>
>And it has nothing to do with the password being blank.

Thank you Mark.  Maybe we need a longer, more descriptive error message
for when that happens?

Laura
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Somebody could not subscribe to pypy-...@python.org

[Mark Sapiro]

On 04/21/2015 03:55 PM, Laura Creighton wrote:
> Forwarded message here.  He just tried to subscribe as ben.jol...@xad.com
> but apparantly can only subscribe if he leaves the password field blank.
> 
> It is, of course, working just fine for me.


And it has nothing to do with the password being blank.


>>> Upon hitting the ŒSubscribe¹ form button, the browser goes to
>>> https://mail.python.org/mailman/subscribe/pypy-dev
>>> with the response HTML containing:
>>> pypy-dev Subscription resultsYou must GET the form before
>>> submitting it.


This says that the form he's submitting either is not the form at
 or he got (http GET)
the form either more than 1 hour before or less than 5 seconds before
submitting it.

This is because of the fix for
. The feature is
described at
,
lines 497-505 and was implemented for the python.org lists with the
recent 2.1.19 upgrade.

There are a number of recent POST requests to
 in the logs at
mail.python.org, so I can't absolutely confirm the scenario, but I
suspect it went something like this:

1) POST an old form with a password and get the error.

2) go back in the browser and try again, still with an old form and
still get the error

3) reget a fresh listinfo page, fill in and submit the form, this time
with no password and it works, not because no password, but because it
was a fresh form.


-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Somebody could not subscribe to pypy-...@python.org

[Laura Creighton]

Forwarded message here.  He just tried to subscribe as ben.jol...@xad.com
but apparantly can only subscribe if he leaves the password field blank.

It is, of course, working just fine for me.

Laura

--- Forwarded Message

Return-Path: 
Received: from na01-bl2-obe.outbound.protection.outlook.com 
(mail-bl2on0081.outbound.protection.outlook.com [65.55.169.81])
by theraft.openend.se (8.14.4/8.14.4/Debian-4) with ESMTP id 
t3LMPjWl005823
(version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=OK)
for ; Wed, 22 Apr 2015 00:25:48 +0200
Received: from CO2PR0601MB0949.namprd06.prod.outlook.com (25.160.10.21) by
 CO2PR0601MB0951.namprd06.prod.outlook.com (25.160.10.23) with Microsoft SMTP
 Server (TLS) id 15.1.136.25; Tue, 21 Apr 2015 22:25:37 +
Received: from CO2PR0601MB0949.namprd06.prod.outlook.com ([25.160.10.21]) by
 CO2PR0601MB0949.namprd06.prod.outlook.com ([25.160.10.21]) with mapi id
 15.01.0136.014; Tue, 21 Apr 2015 22:25:38 +
From: Ben Jolitz 
To: Laura Creighton 
CC: Maciej Fijalkowski ,
"pypy-dev-ow...@python.org"

Subject: Re: cannot subscribe to pypy-dev
Thread-Topic: cannot subscribe to pypy-dev
Thread-Index: AQHQfF3QMj8aywLr/US+oe9lL0sZLZ1XxyCAgAAWCqD//7juAA==
Date: Tue, 21 Apr 2015 22:25:37 +
Message-ID: 
References: 
 
 <201504211914.t3ljebcg007...@fido.openend.se>
 
 <201504211939.t3ljdayr008...@fido.openend.se>
In-Reply-To: <201504211939.t3ljdayr008...@fido.openend.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: openend.se; dkim=none (message not signed)
 header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.205.11.76]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB0951;
x-microsoft-antispam-prvs: 

x-forefront-antispam-report: 
BMV:1;SFV:NSPM;SFS:(10009020)(6009001)(479174004)(51704005)(377454003)(24454002)(2656002)(92566002)(106116001)(50986999)(76176999)(15975445007)(102836002)(87936001)(295011)(122556002)(46102003)(290011)(93886004)(110136001)(19580405001)(36756003)(19580395003)(66066001)(86362001)(551544002)(77156002)(99286002)(54356999)(4013)(62966003);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR0601MB0951;H:CO2PR0601MB0949.namprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: 
BCL:0;PCL:0;RULEID:(601004)(5005006)(5002010);SRVR:CO2PR0601MB0951;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB0951;
x-forefront-prvs: 0553CBB77A
Content-Type: text/plain; charset="utf-8"
Content-ID: 
MIME-Version: 1.0
X-OriginatorOrg: xad.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2015 22:25:37.5384
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 980bda08-f5bc-4d93-93e0-06e14b5a94a5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0951
X-Greylist: Sender succeeded STARTTLS authentication, not delayed by 
milter-greylist-4.3.9 (theraft.openend.se [89.233.217.130]); Wed, 22 Apr 2015 
00:25:48 +0200 (CEST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by theraft.openend.se id 
t3LMPjWl005823
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Wed Apr 22 00:26:07 2015
X-DSPAM-Confidence: 0.9993
X-DSPAM-Probability: 0.
X-DSPAM-Signature: 5536ce7e58301256564919

Nope. Since I got an auto generated password, I can say the one I tried to
use, which was “duhton” (without the quotes).

Any other password also failed, including “1234”

Leaving the password field blank just worked.

Ben

On 4/21/15, 12:39 PM, "Laura Creighton"  wrote:

>In a message of Tue, 21 Apr 2015 19:22:41 -, Ben Jolitz writes:
>>I opened a new tab and tried to subscribe with ben.jol...@xad.com as my
>>email address, only ASCII characters.
>>
>>Upon hitting the ŒSubscribe¹ form button, the browser goes to
>>https://mail.python.org/mailman/subscribe/pypy-dev
>>with the response HTML containing:
>>pypy-dev Subscription resultsYou must GET the form before
>>submitting it.
>>
>>
>>
>>And I figured out where you need to look. By omitting the ³Pick a
>>password², ³Reenter password² fields on the subscribe form, Mailman
>>successfully subscribes me.
>>
>>While I am now subscribed to the list, others may not become desperate
>>enough to leave the password fields empty.
>>
>>Cheers,
>>Ben
>
>Did you have non-ascii chars in the password you tried to use?
>
>Laura
>


--- End of Forwarded Message
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Carl Zwanzig]

On 4/21/2015 1:38 PM, Danil Smirnov wrote:

Using 'service' scripts to control ALL server's services

[...]

Considering this 'packagers related' stuff as not important and insisting
on 'native' way to use cron has less sense for me than the opposite. Why
standard control of Mailman service in very popular distribution family
has no reflection in Mailman documentation you mentioned and sometimes
considers like 'artefacts'?


What 'service' scripts?

On 4/21/2015 2:17 PM, Danil Smirnov wrote:

You described cron entries copying procedure as 'artifacts' - if init.d
script supports fully the same functionality, I must agree that 'packager stuff'
are really artifacts...


See, here's the thing- my systems don't have /etc/init.d/; I put the mailman 
startup in /etc/rc.local. (I use some very popular bsd distros, which are 
rather different from other *nix distros, which are rather different from 
other other *nix distros. It's a lot of work to keep track of all of them.) 
If the MM doc needs to be updated, I'm sure the offer would be well-received.


z!

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Mark Sapiro]

On 04/21/2015 02:17 PM, Danil Smirnov wrote:
> 
> You described cron entries copying procedure as 'artifacts'


Yes, I described the specific content of your init.d/mailman script as
an artifact[1] if your package.


>> Do we have a communication disconnect of some kind here?
> 
> Perhaps. :)


I use the word 'artifact in the sense of definition 6 at
, i.e. "any feature
that is not naturally present but is a product of an extrinsic agent,
method, or the like:". In this case, some content that would not be
there if you had never installed the package, but had installed from
source following the procedures in our manual at
. Thus, that content is
an artifact of your package install.

Clearly this word means something pejorative to you, but I had no such
intent.

Whether it is preferable to install Mailman's crontab as a user or
system crontab is a matter of taste. Whether it is appropriate to
disable Mailman's cron jobs when mailman is not running is arguable. If
it works for you, fine, but it seems to me that you would only want to
do this on a production server if you decided to shut Mailman down
entirely and permanently. If mailman was only going to be stopped for a
short period for some reason, would you really want to not run the
checkdbs, disabled, senddigests or mailpasswds cron jobs just because
their time was in that window. Maybe that would be the case for you, but
it is not a decision the I would feel comfortable making for all
installations that use Mailman.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Danil Smirnov]

2015-04-22 0:05 GMT+03:00 Mark Sapiro :
> The source distribution also includes an init.d script at
> scripts/mailman and instructions for installing it are in comments at
> its beginning and in the installation manual at
> , so you can see, we
> definitely support 'service' scripts.

Is it also support cron entries to remove them when stopping?
This is the main topic of the discussion.

You described cron entries copying procedure as 'artifacts' - if init.d
script supports fully the same functionality, I must agree that 'packager stuff'
are really artifacts...

> Do we have a communication disconnect of some kind here?

Perhaps. :)

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Mark Sapiro]

On 04/21/2015 01:38 PM, Danil Smirnov wrote:
> 
> Using 'service' scripts to control ALL server's services (Mailman IS a
> service irrespective of its version, right?) isn't absurd or
> non-sense. I think one should respect distribution structure and keep
> things work as distribution creator's intended.


Mailman is not a service on your server if you don't install it either
from source or a package. Your /etc/init.d/mailmnan script was installed
by your Mailman package. It wasn't there before you installed the package.

The source distribution also includes an init.d script at
scripts/mailman and instructions for installing it are in comments at
its beginning and in the installation manual at
, so you can see, we
definitely support 'service' scripts.


> Considering this 'packagers related' stuff as not important and
> insisting on 'native' way to use cron has less sense for me than the
> opposite. Why standard control of Mailman service in very popular
> distribution family has no reflection in Mailman documentation you
> mentioned and sometimes considers like 'artefacts'?


See the above. The only thing I'm calling 'packagers related' is the
specific content of the init.d script, not the concept.


> May be this attitude has some influence on that fact that there is so
> old version of Mailman in last Centos release?...


You would have to as Red Hat about that? I don't see what "attitude" you
are talking about here that would affect the version that Red Hat and
hence CentOS chooses to include in a particular distro.

Do we have a communication disconnect of some kind here?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Danil Smirnov]

2015-04-21 23:10 GMT+03:00 Mark Sapiro :
> They are things that are in some sense left over from a prior install of
> a distro's Mailman package. Had you just installed Mailman from source
> without ever installing the package, you would not be aware of them.
> Thus, they are artifacts left over from the package.

Using 'service' scripts to control ALL server's services (Mailman IS a
service irrespective of its version, right?) isn't absurd or
non-sense. I think one should respect distribution structure and keep
things work as distribution creator's intended.

Considering this 'packagers related' stuff as not important and
insisting on 'native' way to use cron has less sense for me than the
opposite. Why standard control of Mailman service in very popular
distribution family has no reflection in Mailman documentation you
mentioned and sometimes considers like 'artefacts'?

May be this attitude has some influence on that fact that there is so
old version of Mailman in last Centos release?...

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources

[Mark Sapiro]

On 04/21/2015 12:18 PM, Danil Smirnov wrote:
> 2015-04-21 21:23 GMT+03:00 Mark Sapiro :
>> But this raises the question, if you are installing Mailman from source,
>> why do you still have artifacts from the distro's package still in your
>> installation.
> 
> Why you name them 'artefacts'? I consider them very convenient technology
> working great for Mailman 2.1.18-1 also. I can stop and start Mailman service
> with 'service' tool and I don't need to worry about crontab entries.


They are things that are in some sense left over from a prior install of
a distro's Mailman package. Had you just installed Mailman from source
without ever installing the package, you would not be aware of them.
Thus, they are artifacts left over from the package.


> Give me a reason why I wouldn't do this.


If you know exactly what you are doing and how things that remain from
the package interact with your source install/upgrade, that's fine, and
if you like those specific things you continue to use, there's no reason
not to.

But those conditions don't apply to everyone and people sometimes get
themselves in trouble when they knowingly or unknowingly mix things from
a package with things from the source distribution that may not be
compatible in the ways that they do things.

For example, your packages /etc/init.d/mailman script copies
(apparently) /opt/local/share/mailman/cron/crontab.in or maybe
/(var|usr)/lib/mailman/cron/crontab.in to /etc/cron.d/mailman.

If in the process of installing/upgrading your installation from the
source distribution you had copied the source cron/crontab.in to
whatever crontab.in the /etc/init.d/mailman script copies from, it would
not work because the source cron/crontab.in is a 'user' crontab and
doesn't have 'mailman' as the 6th field in the entries.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources (was: Cron command?)

[Danil Smirnov]

2015-04-21 21:23 GMT+03:00 Mark Sapiro :
> But this raises the question, if you are installing Mailman from source,
> why do you still have artifacts from the distro's package still in your
> installation.

Why you name them 'artefacts'? I consider them very convenient technology
working great for Mailman 2.1.18-1 also. I can stop and start Mailman service
with 'service' tool and I don't need to worry about crontab entries.

Give me a reason why I wouldn't do this.

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] packages vs sources (was: Cron command?)

[Mark Sapiro]

On 04/21/2015 10:37 AM, Danil Smirnov wrote:
> 
> Many people rely on their distribution packagers - is this bad?
> 
> I always prefer to use yum/apt-get instead of compiling software from source.
> The reasons are obvious (all they are in any package system mission 
> statement).
> 
> Mailman is one of the few exception of this rule on my servers because of
> importance of its new versions and rare packages updates. :(
> (It's shame that they include 2.1.15 in the new Centos7 distribution!)


You have answered your own question.


> But if we 'use supplied tools' and lost distribution integration - like
> removing cron entries automatically when 'service mailman stop' -
> does this make sense at all?


The OP (and I) were only referring to using the 'crontab' command to
install/edit a crontab rather than directly copying/editing files.

In the case of a package which installs/removes Mailman's crontab as
part of it's init.d script, this translates to "if you want to edit
Mailman's crontab, edit the source file, not the /etc/cron.d/mailman
file. And, in this case, it is incumbent on the packager to make this
clear in the package documentation.

But this raises the question, if you are installing Mailman from source,
why do you still have artifacts from the distro's package still in your
installation.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] sync_members

[Marco Stoecker]

On 04/21/2015 07:03 PM, Mark Sapiro wrote:

This looks like  which
was initially addressed in Mailman 2.1.17 and further fixed in 2.1.18.
Your's appears to be a pre 2.1.17 version. A patch is attached.



Thx Mark, works perfect now :-D
BR
Marco
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] packages vs sources (was: Cron command?)

[Danil Smirnov]

2015-04-21 19:47 GMT+03:00 Mark Sapiro :
> This is a packager thing (RHEL/CentOS ?). Mailman as distributed by the
> GNU Mailman project does not do this (never did). Our docs are
>  and recommend
> installing our crontab as a user crontab with the crontab command.

...

>> The bottom line is that it's best, as always, to install a component
>> such as a crontab using the supplied tools rather trying to second-guess
>> the tool set and copying files directly.
>
> +1

Many people rely on their distribution packagers - is this bad?

I always prefer to use yum/apt-get instead of compiling software from source.
The reasons are obvious (all they are in any package system mission statement).

Mailman is one of the few exception of this rule on my servers because of
importance of its new versions and rare packages updates. :(
(It's shame that they include 2.1.15 in the new Centos7 distribution!)

But if we 'use supplied tools' and lost distribution integration - like
removing cron entries automatically when 'service mailman stop' -
does this make sense at all?

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] sync_members

[Marco Stoecker]

On 04/21/2015 07:03 PM, Mark Sapiro wrote:

This looks like  which
was initially addressed in Mailman 2.1.17 and further fixed in 2.1.18.
Your's appears to be a pre 2.1.17 version. A patch is attached.


Hi Mark,
in fact I use Debian wheezy which provided Mailman 2.1.15.
I'll try your patch and I'll let you know ;-)
BR
Marco
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Mark Sapiro]

On 04/21/2015 09:42 AM, Adam McGreggor wrote:
> 
> This makes me wonder if it might be useful to have two files in the
> Mailman source:
> 
> mailman/cron/crontab.in-system
> mailman/cron/crontab.in-user
> 
> with -system including the 'user' column?


Why? Our distribution works when installed per our docs. Downstream
packages also tend to do the right thing. Problems tend to occur only
when users of packages try to follow our documentation rather that the
packager's.


> Were the 'offical' source for Mailman be GitHub, there'd be a PR
> already, handling that.


Just FYI and not addressing the issue of, PRs vs. branches vs. bzr merge
proposals, Mailman 3 will probably use GitLabs as it's official
repository. We're not there yet, but we recognize that Bazaar lost the war.

We can't use GitHub because GitHub uses proprietary software and as a
GNU project, we get into issues with FSF if our complete stack is not
open source.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] sync_members

[Mark Sapiro]

On 04/21/2015 06:59 AM, Marco Stoecker wrote:
> 
> indeed it throws an exception:
> 
> user@machine:~# ./mailinglist_sync.sh
> Traceback (most recent call last):
>   File "/usr/sbin/sync_members", line 288, in 
> main()
>   File "/usr/sbin/sync_members", line 259, in main
> s = email.Utils.formataddr((name, addr)).encode(enc, 'replace')
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 8:
> ordinal not in range(128)


This looks like  which
was initially addressed in Mailman 2.1.17 and further fixed in 2.1.18.
Your's appears to be a pre 2.1.17 version. A patch is attached.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
=== modified file 'bin/sync_members'
--- bin/sync_members2008-02-29 17:47:36 +
+++ bin/sync_members2013-12-01 21:06:45 +
@@ -1,6 +1,6 @@
 #! @PYTHON@
 #
-# Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
+# Copyright (C) 1998-2013 by the Free Software Foundation, Inc.
 #
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License
@@ -256,6 +256,10 @@
 try:
 if not dryrun:
 mlist.ApprovedAddMember(userdesc, welcome, notifyadmin)
+# Avoid UnicodeError if name can't be decoded
+if isinstance(name, str):
+name = unicode(name, errors='replace')
+name = name.encode(enc, 'replace')
 s = email.Utils.formataddr((name, addr)).encode(enc, 'replace')
 print _('Added  : %(s)s')
 except Errors.MMAlreadyAMember:
@@ -276,6 +280,10 @@
 # reasons is in the database.  Use a lower level remove to
 # get rid of this member's entry
 mlist.removeMember(addr)
+# Avoid UnicodeError if name can't be decoded
+if isinstance(name, str):
+name = unicode(name, errors='replace')
+name = name.encode(enc, 'replace')
 s = email.Utils.formataddr((name, addr)).encode(enc, 'replace')
 print _('Removed: %(s)s')
 

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Adam McGreggor]

On Tue, Apr 21, 2015 at 11:32:48AM -0500, Lindsay Haisley wrote:
> The bottom line is that it's best, as always, to install a component
> such as a crontab using the supplied tools rather trying to second-guess
> the tool set and copying files directly.

This makes me wonder if it might be useful to have two files in the
Mailman source:

mailman/cron/crontab.in-system
mailman/cron/crontab.in-user

with -system including the 'user' column?

Were the 'offical' source for Mailman be GitHub, there'd be a PR
already, handling that.

-- 
"Youth cannot know how age thinks and feels. But old men
 are guilty if they forget what it was to be young"
-- JK Rowling ('Harry Potter and the Order of the Phoenix')
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Mark Sapiro]

On 04/21/2015 09:32 AM, Lindsay Haisley wrote:
> On Tue, 2015-04-21 at 18:46 +0300, Danil Smirnov wrote:
>> # This file is copied to /etc/cron.d/mailman from
>> # /usr/lib/mailman/cron/crontab.in when the mailman service is started via 
>> its
>> # init.d script and the file /etc/cron.d/mailman is removed when the
>> # service is stopped.  Therefore any edits made directly to
>> # /etc/cron.d/mailman will be lost anytime the mailman service
>> # restarts.
> 
> I think this needs to be revisited.  I don't believe Mailman does this
> anymore.  Mark, does a bug need to be filed on this?


This is a packager thing (RHEL/CentOS ?). Mailman as distributed by the
GNU Mailman project does not do this (never did). Our docs are
 and recommend
installing our crontab as a user crontab with the crontab command.


...
> The bottom line is that it's best, as always, to install a component
> such as a crontab using the supplied tools rather trying to second-guess
> the tool set and copying files directly.

+1

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Lindsay Haisley]

On Tue, 2015-04-21 at 18:46 +0300, Danil Smirnov wrote:
> # This file is copied to /etc/cron.d/mailman from
> # /usr/lib/mailman/cron/crontab.in when the mailman service is started via its
> # init.d script and the file /etc/cron.d/mailman is removed when the
> # service is stopped.  Therefore any edits made directly to
> # /etc/cron.d/mailman will be lost anytime the mailman service
> # restarts.

This text isn't included in crontab.in in recent versions of Mailman.  I
think this is obsolete.  Did you find it somewhere else?

-- 
Lindsay Haisley   | "The only unchanging certainty
FMP Computer Services |is the certainty of change"
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Lindsay Haisley]

On Tue, 2015-04-21 at 18:46 +0300, Danil Smirnov wrote:
> # This file is copied to /etc/cron.d/mailman from
> # /usr/lib/mailman/cron/crontab.in when the mailman service is started via its
> # init.d script and the file /etc/cron.d/mailman is removed when the
> # service is stopped.  Therefore any edits made directly to
> # /etc/cron.d/mailman will be lost anytime the mailman service
> # restarts.

I think this needs to be revisited.  I don't believe Mailman does this
anymore.  Mark, does a bug need to be filed on this?

The documentation in the docs directory in the Mailman source which I
think is definitive, says to use the command, as root (or sudo root)
similar to the following, assuming mailman has an entry in /etc/passwd:

crontab -u mailman ~mailman/cron/crontab.in

This will place the Mailman crontab in the crontab spool directory.

According to the cron(8) man page /etc/cron.d/ is a Debian-ism and may
or may not be supported on other Linux variants such as RH or on other
similar platforms such as BSD.

I mis-spoke about having to use an editor.  The crontab command accepts
a filename as an argument in lieu of the -e option and will install the
named file.  Sorry!

The bottom line is that it's best, as always, to install a component
such as a crontab using the supplied tools rather trying to second-guess
the tool set and copying files directly.
> 
-- 
Lindsay Haisley   | "The only unchanging certainty
FMP Computer Services |is the certainty of change"
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Mark Sapiro]

This thread is getting too convoluted for me to parse, but here's the
complete story:

There are two possible places where Mailman's crontab can be installed.
For purposes of discussion, assume the Mailman user on your server is
'mailman'.

- The crontab can be a user crontab in /var/spool/cron/mailman or maybe
/var/spool/cron/crontabs/mailman. This can be installed by

sudo cp /path/to/mailman/cron/crontab.in /var/spool/cron/mailman

(or to /var/spool/cron/crontabs/mailman after verifying the place) or
better because you don't need to know the destination

sudo crontab -u mailman < /path/to/mailman/cron/crontab.in

- the crontab can be a system crontab in /etc/cron.d/. The file name is
not important but is usually 'mailman' for documentation reasons.
Because these crontabs do not have a user context, the format is
different. There is an additional field between the days/times and the
command which is the user under which to run the command. Mailman's
cron/crontab.in (as distributed by the GNU Mailman project) does not
have this field. Thus, if you were to install
/path/to/mailman/cron/crontab.in directly in say /etc/cron.d/mailman you
would need to edit it to change lines like

0 8 * * * /usr/bin/python -S /var/MM/21/cron/checkdbs

to

0 8 * * * mailman /usr/bin/python -S /var/MM/21/cron/checkdbs

The important thing is there should be only one of these two possible
crontabs. It doesn't really matter which, but if you have both, you'll
run all the crons twice which will result in duplicate emails being sent
to users and list owners.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Lindsay Haisley]

On Tue, 2015-04-21 at 18:46 +0300, Danil Smirnov wrote:
> 2015-04-21 17:43 GMT+03:00 Danil Smirnov :
> > 2015-04-21 17:24 GMT+03:00 Lindsay Haisley :
> >> so a direct copy of the
> >> Mailman crontab to this directory can't be done without modifying the
> >> file.
> 
> You are right but not because of improper format of crontab.in file:

Files in /etc/cron.d/ require an additional field, the user account to
which the crontab file belongs.  From the man page for cron(8) for
Ubuntu:

Additionally,  in  Debian,  cron reads the files in
the /etc/cron.d
directory.  cron treats the files in /etc/cron.d as in the same
way
as  the  /etc/crontab  file (they follow the special format of
that
file, i.e. they include the user field).

Records in mailman.in don't have the user field, e.g.

27 3 * * * /usr/bin/python
-S /usr/lib64/mailman/cron/nightly_gzip

It could be manually added, but the best way to incorporate the Mailman
crontab is to pull it into the crontab editor (crontab -e), which will
put them in the cron spool directory.

"Improper" is perhaps to strong a word.  "Incorrect" might have been a
better choice.

> 
> # This file is copied to /etc/cron.d/mailman from
> # /usr/lib/mailman/cron/crontab.in when the mailman service is started via its
> # init.d script and the file /etc/cron.d/mailman is removed when the
> # service is stopped.  Therefore any edits made directly to
> # /etc/cron.d/mailman will be lost anytime the mailman service
> # restarts.
> #
> # To make changes edit the master copy /usr/lib/mailman/cron/crontab.in and 
> then
> # restart the service to pick up the changes (/sbin/service mailman restart).
> #
> # The reason this is done this way is because the mailman cron jobs
> # should only be invoked if the mailman service is enabled and not
> # just as a consequence of installing the rpm as was the case
> # previously. The file /etc/cron.d/mailman cannot simply be linked to
> # the master copy in /usr/lib/mailman/cron because for security reasons cron
> # will not process crontab files that are links or writeable by
> # anybody else but root, thus the file must be copied into /etc/cron.d
> # with the right ownership and permissions.
> 
> Danil
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: 
> https://mail.python.org/mailman/options/mailman-users/fmouse%40fmp.com

-- 
Lindsay Haisley   | "The only unchanging certainty
FMP Computer Services |is the certainty of change"
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Danil Smirnov]

2015-04-21 17:43 GMT+03:00 Danil Smirnov :
> 2015-04-21 17:24 GMT+03:00 Lindsay Haisley :
>> so a direct copy of the
>> Mailman crontab to this directory can't be done without modifying the
>> file.

You are right but not because of improper format of crontab.in file:

# This file is copied to /etc/cron.d/mailman from
# /usr/lib/mailman/cron/crontab.in when the mailman service is started via its
# init.d script and the file /etc/cron.d/mailman is removed when the
# service is stopped.  Therefore any edits made directly to
# /etc/cron.d/mailman will be lost anytime the mailman service
# restarts.
#
# To make changes edit the master copy /usr/lib/mailman/cron/crontab.in and then
# restart the service to pick up the changes (/sbin/service mailman restart).
#
# The reason this is done this way is because the mailman cron jobs
# should only be invoked if the mailman service is enabled and not
# just as a consequence of installing the rpm as was the case
# previously. The file /etc/cron.d/mailman cannot simply be linked to
# the master copy in /usr/lib/mailman/cron because for security reasons cron
# will not process crontab files that are links or writeable by
# anybody else but root, thus the file must be copied into /etc/cron.d
# with the right ownership and permissions.

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Danil Smirnov]

2015-04-21 17:24 GMT+03:00 Lindsay Haisley :
> The crontab provided with Mailman in ~mailman/cron/crontab.in is not in
> the proper format for use in /etc/cron.d/ so a direct copy of the
> Mailman crontab to this directory can't be done without modifying the
> file.

I have absolutely identical files
/etc/cron.d/mailman
and
/(var|usr)/lib/mailman/cron/crontab.in
on my Centos 6.6 and Centos 7 boxes.

And I never see that Mailman cron commands were installed directly
in the 'mailman' user crontab on my servers. Everytime it was through
/etc/cron.d.

Danil
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Lindsay Haisley]

Your old notes are incorrect.  First, the proper command on modern Unix
or Unix-ish systems such as Linux is simply:

sudo crontab -e -u mailman

Copy and paste the crontab provided with Mailman in the ~mailman/cron
directory into the edit window opened by this command.

The crontab provided with Mailman in ~mailman/cron/crontab.in is not in
the proper format for use in /etc/cron.d/ so a direct copy of the
Mailman crontab to this directory can't be done without modifying the
file.  The directory /etc/cron.d/ is Debian-specific (which includes
Debian derivatives such as Ubuntu and Mint) and a direct copy to cron's
spool directory, /var/spool/cron/, is advised against in the cron man
page.  It's best to go through the UI provided by crontab and use your
CLI editor (vim, pico, emacs or whatever) to manage the crontab.

See the man page for cron(8) and crontab(1)

On Tue, 2015-04-21 at 11:56 +0300, Danil Smirnov wrote:
> Check if you already have /etc/cron.d/mailman, if not just
> 
> cp /opt/local/share/mailman/cron/crontab.in /etc/cron.d/mailman
> 
> with sufficient rights.
> 
> 2015-04-21 8:21 GMT+03:00 Bill Christensen :
> > Hi all,
> >
> > I recently updated and my digests stopped going out (I was able to push out
> > the waiting digest manually by doing
> > /opt/local/share/mailman/cron/senddigests so I know the function is
> > working).  My old notes tell me the command for cron is:
> >
> > sudo /opt/local/share/mailman/cron/crontab -u mailman crontab.in
> >
> > I also tried
> >
> > sudo /opt/local/share/mailman/cron -u mailman crontab.in
> >
> > since that appears to be the current location of crontab.in
> >
> > but that's getting me 'command not found' and
> >
> >   cron: illegal option -- u
> >
> >  usage: cron [-s] [-o] [-x debugflag[,...]]
> >
> >  debugflags: ext sch proc pars load misc test bit
> >
> > Any ideas on this?
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: 
> https://mail.python.org/mailman/options/mailman-users/fmouse%40fmp.com

-- 
Lindsay Haisley   | "The only unchanging certainty
FMP Computer Services |is the certainty of change"
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] sync_members

[Marco Stoecker]

On 04/17/2015 04:57 PM, Mark Sapiro wrote:
> How does it fail? Does it throw an exception? If so, please provide a
> traceback. If not, what does it do?
> 
> What is the list's preferred_language?
> 

Hi Mark

late answer, my laptop crashed.

the default language for this list is German:
preferred_language = 'de'

indeed it throws an exception:

user@machine:~# ./mailinglist_sync.sh
Traceback (most recent call last):
  File "/usr/sbin/sync_members", line 288, in 
main()
  File "/usr/sbin/sync_members", line 259, in main
s = email.Utils.formataddr((name, addr)).encode(enc, 'replace')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 8:
ordinal not in range(128)

any glue?

BR
Marco
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[Danil Smirnov]

Check if you already have /etc/cron.d/mailman, if not just

cp /opt/local/share/mailman/cron/crontab.in /etc/cron.d/mailman

with sufficient rights.

2015-04-21 8:21 GMT+03:00 Bill Christensen :
> Hi all,
>
> I recently updated and my digests stopped going out (I was able to push out
> the waiting digest manually by doing
> /opt/local/share/mailman/cron/senddigests so I know the function is
> working).  My old notes tell me the command for cron is:
>
> sudo /opt/local/share/mailman/cron/crontab -u mailman crontab.in
>
> I also tried
>
> sudo /opt/local/share/mailman/cron -u mailman crontab.in
>
> since that appears to be the current location of crontab.in
>
> but that's getting me 'command not found' and
>
>   cron: illegal option -- u
>
>  usage: cron [-s] [-o] [-x debugflag[,...]]
>
>  debugflags: ext sch proc pars load misc test bit
>
> Any ideas on this?
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cron command?

[E Kogler]

>Hi all,

> I recently updated and my digests stopped going out (I was able to push out
> the waiting digest manually by doing
> /opt/local/share/mailman/cron/senddigests so I know the function is
> working).  My old notes tell me the command for cron is:

> sudo /opt/local/share/mailman/cron/crontab -u mailman crontab.in

Maybe "sudo /usr/bin/crontab -u mailman /opt/local/share/mailman/crontab.in" ?


[...]

  
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org