From mentor@alb-net.com  Thu Jun  1 04:03:42 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 31 May 2000 23:03:42 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS; multiple message approval
Message-ID: <Pine.GSO.4.21.0005312300430.20966-100000@alb-net.com>

There seems to be a problem when approving multiple messages in the latest
CVS (this evening). When approving multiple messages at least one of them
will disappear. logs/vette shows the messages as approved, however the
messages never makes it to the archives and it does not get distributed. 

I tried this with 2 and three messages waiting for approval.

Hope this helps to resolve a possible problem.

thanks,
mentor



From bwarsaw@python.org  Thu Jun  1 04:03:49 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 31 May 2000 23:03:49 -0400 (EDT)
Subject: [Mailman-Developers] approved messages in 2.0beta3 not archived
References: <Pine.GSO.4.21.0005311223310.16287-100000@alb-net.com>
Message-ID: <14645.53909.340540.557299@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> Some testing with 2.0beta3 revealed that the approved message
    MC> are not being archived properly. Actually, the messages get
    MC> into the list.mbox file but they are missing the "From " line
    MC> and therefore do not show on the archive page.

This will (finally) be fixed in the released 2.0beta3.

-Barry


From bigdog@dogpound.vnet.net  Thu Jun  1 05:17:19 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 00:17:19 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
Message-ID: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>

hate to bring this up again..  but i tried the followin..

1.  current cvs code + patch Harald fixed up
2.  current cvs code - patch Harald fixed up

Both give the same problem I was having before..  Here's the rundown..

1.  I goto the 'view other subscriptions' page with correct password an NO
lock file (no lock/davis.lock).
2.  the error comes right up with the following traceback.

Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 89, in run_main
    main()
  File "/home/mailman/Mailman/Cgi/handle_opts.py", line 80, in main
    mlist.Save()
  File "/home/mailman/Mailman/MailList.py", line 867, in Save
    self.__lock.refresh()
  File "/home/mailman/Mailman/LockFile.py", line 204, in refresh
    raise NotLockedError
NotLockedError: 

&

<< -- start lock log -- >>
Jun 01 00:03:58 2000 (6084) davis.lock laying claim
Jun 01 00:03:58 2000 (6084) davis.lock got the lock
Jun 01 00:03:58 2000 (6084) davis.lock laying claim
Jun 01 00:03:58 2000 (6084) davis.lock already locked
<< -- stop lock log -- >>

3.  Well..  I hit refresh and there is now a davis.lock file.  And it
waits (probably until 

Jun 01 00:04:24 2000 (6095) davis.lock laying claim
Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:24 2000 (6095) davis.lock waiting for claim
Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:25 2000 (6095) davis.lock unexpected linkcount <> 2: 1

<snip>  (you get the idea..)

Jun 01 00:04:51 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:53 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:05 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:05 2000 (6095) davis.lock waiting for claim
Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:08 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:08 2000 (6095) davis.lock lifetime has expired, breaking
Jun 01 00:06:08 2000 (6095) davis.lock got the lock
Jun 01 00:06:08 2000 (6095) davis.lock laying claim
Jun 01 00:06:08 2000 (6095) davis.lock already locked

The other weird thing is i'm using the same Lockfile.py as the one you
edited.  at least diff didnt see any differences.

PLUS i can view other subscriptions on python.org.  Is python.org using
current CVS code from sourceforge?

PS.  I'm willin to be a guinie pig again :)

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

The severity of the itch is proportional to the reach.





From bwarsaw@python.org  Thu Jun  1 05:30:54 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:30:54 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
References: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>
Message-ID: <14645.59134.480861.387333@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Is python.org using current CVS code from sourceforge?

No.  I've just fixed the qrunner problem Mentor posted about, and this
LockFile issue is probably the last one I must fix before I update
python.org's copy to CVS.  I don't think I'll get to it tonight
though.

    MD> PS.  I'm willin to be a guinie pig again :)

Mwah, ha, ha!
-Barry


From bigdog@dogpound.vnet.net  Thu Jun  1 05:42:13 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 00:42:13 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
In-Reply-To: <14645.59134.480861.387333@anthem.python.org>
Message-ID: <Pine.LNX.4.21.0006010040060.5724-100000@dogpound.vnet.net>

On Thu, 1 Jun 2000, Barry A. Warsaw wrote:

> No.  I've just fixed the qrunner problem Mentor posted about, and this
> LockFile issue is probably the last one I must fix before I update
> python.org's copy to CVS.  I don't think I'll get to it tonight
> though.

Thanks!

>     MD> PS.  I'm willin to be a guinie pig again :)
> 
> Mwah, ha, ha!

Be easy...

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

REALITY.SYS corrupted- reboot Universe (Y/N)?





From bwarsaw@python.org  Thu Jun  1 05:45:32 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:45:32 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS; multiple message approval
References: <Pine.GSO.4.21.0005312300430.20966-100000@alb-net.com>
Message-ID: <14645.60012.91457.847125@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> There seems to be a problem when approving multiple messages
    MC> in the latest CVS (this evening). When approving multiple
    MC> messages at least one of them will disappear. logs/vette shows
    MC> the messages as approved, however the messages never makes it
    MC> to the archives and it does not get distributed.

    MC> I tried this with 2 and three messages waiting for approval.

    MC> Hope this helps to resolve a possible problem.

Yes, thanks.  The current CVS should have the patch for this.  Time
for sleep.

-Barry


From bwarsaw@python.org  Thu Jun  1 05:56:08 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:56:08 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
References: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>
Message-ID: <14645.60648.221646.191537@anthem.python.org>

Good news.  I know what the problem is, but I'm too tired to fix it
tonight.


From ricardo@rixhq.nu  Thu Jun  1 11:04:34 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 1 Jun 2000 12:04:34 +0200
Subject: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
In-Reply-To: <14645.16782.684941.668474@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 12:45:02PM -0400
References: <20000531114024.A17471@orwell.bok.net> <20000531171248.A17843@miss-janet.com> <14645.16782.684941.668474@anthem.python.org>
Message-ID: <20000601120434.B717@miss-janet.com>

On Wed, May 31, 2000 at 12:45:02PM -0400, Barry A. Warsaw wrote:
> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
>     RK> wow this is my dream come true... now i can stop bugging Barry
>     RK> about implementing this ... ;) i can't wait to get home and
>     RK> install the new cvs...  Our list relies heavily on approving
>     RK> messages so I'll report my experiences with it asap...
> Excellent, please do.  I'm on a bent to get beta3 out (and after that,
> clear my freakin' mailman-dev inbox ;).

I've installed the patch and approved about 15 posts (had to discard a lot of crap ;()
and qrunner is doing the postings now... it seems to work ok so far...
but I do notice that when I go to the admin URL while qrunner is doing it's job, it
takes more than a minute before the page is displayed... does this have something to
do with locking or it's because my server has a load average of 3+ (which isn't very
uncommon considering the hardware performance though)

> Btw, it was a one line change :)

cool :)

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From ricardo@rixhq.nu  Thu Jun  1 11:08:03 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 1 Jun 2000 12:08:03 +0200
Subject: [Mailman-Developers] logs
Message-ID: <20000601120803.C717@miss-janet.com>

Hi,

I was just looking into my logs directory and I noticed a
10mb bounce log file... maybe we should consider using something like
log rotating? ie log.0, log.1.gz, log.2.gz etc...
or should this be left as a task for the admin and/or distibution maintainer?
another option would be to set a maximum log size

Ricardo.

--



From thomas@xs4all.net  Thu Jun  1 11:19:46 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 1 Jun 2000 12:19:46 +0200
Subject: [Mailman-Developers] pipermail/hypermail mbox-archive
In-Reply-To: <14645.29500.819830.122398@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 04:17:00PM -0400
References: <20000327211501.F25139@xs4all.nl> <14645.29500.819830.122398@anthem.python.org>
Message-ID: <20000601121945.L469@xs4all.nl>

On Wed, May 31, 2000 at 04:17:00PM -0400, Barry A. Warsaw wrote:

>     TW> There was a short discussion a month or so ago about the
>     TW> hyperarch 'mbox' archives having the wrong kind of date in the
>     TW> 'From ' lines... 'unixfrom' lines should have a very specific
>     TW> dateformat, namely that which 'time.ctime' returns. The
>     TW> following patch fixes Archiver/HyperArch.py. However, I'm not
>     TW> entirely sure if it will work correctly in other
>     TW> locales... can anyone test that, and propose a
>     TW> locale-independant way of producing this format ?

> I didn't see a followup so I'm going to check this change in.

For the record, you can disregard the locale remark. ctime() is *exactly*
how the From_ line should store its date, regardless of locale or what not.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Thu Jun  1 11:23:44 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 1 Jun 2000 12:23:44 +0200
Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries
In-Reply-To: <14645.27097.449110.777191@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 03:36:57PM -0400
References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> <20000328231400.B8665@xs4all.nl> <14645.22297.479926.425407@anthem.python.org> <14645.24708.529869.456008@anthem.python.org> <14645.27097.449110.777191@anthem.python.org>
Message-ID: <20000601122344.M469@xs4all.nl>

On Wed, May 31, 2000 at 03:36:57PM -0400, Barry A. Warsaw wrote:

> >>>>> "BAW" == Barry A Warsaw <bwarsaw@python.org> writes:

>     BAW> SMTPDirect.py uses str(msg) too and inclusion of From_ in the
>     BAW> body of the message seems to give at least Postfix all manner
>     BAW> of willies.  Maybe the thing to do is include another Message
>     BAW> method which returns just the headers and body, sans the
>     BAW> unixfrom, and use this in SMTPDirect and Sendmail?

> Is it too much of a kludge to make __repr__() return the entire
> message, including the From_ header, and make __str__() return just
> the rfc822 headers and body?  I.e.

> repr(msg) == msg.unixfrom + str(msg)

Yeah, this works. My initial reserve against making str(msg) return the
unixfrom line as well was that it broke 'compatibility' with the regular
rfc822.Message. The SMTPDirect breakage shows that, I guess ;-) Using repr
is a good idea, I think, but it's missing one thing: if unixfrom is empty,
the mailbox will still be fawlty. I think __repr__ should reproduce a
.unixfrom line if it's missing. I'll post a patch later today, I have to run
off to a huge sale at the local bookstore ;-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From bwarsaw@python.org  Thu Jun  1 15:38:23 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:38:23 -0400 (EDT)
Subject: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
References: <20000531114024.A17471@orwell.bok.net>
 <20000531171248.A17843@miss-janet.com>
 <14645.16782.684941.668474@anthem.python.org>
 <20000601120434.B717@miss-janet.com>
Message-ID: <14646.30047.980591.36124@anthem.python.org>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I've installed the patch and approved about 15 posts (had to
    RK> discard a lot of crap ;() and qrunner is doing the postings
    RK> now... it seems to work ok so far...  but I do notice that
    RK> when I go to the admin URL while qrunner is doing it's job, it
    RK> takes more than a minute before the page is displayed... does
    RK> this have something to do with locking or it's because my
    RK> server has a load average of 3+ (which isn't very uncommon
    RK> considering the hardware performance though)

Maybe a bit of both.  qrunner is careful to keep the lock only long
enough to deliver a single message.  If there are multiple messages
destined for the same list, it will release and acquire the lock in
between each delivery.  Still, for large lists, this can take a while.

One of the things to eventually do is audit the cgi scripts so that
they're locking the list only during those operations that require
it.  I.e. a listinfo probably doesn't need the lock, and setting user
options probably only needs the lock for a very short amount of time.

Won't all this just work better with a real transaction based db
underneath?  ;)

-Barry


From bwarsaw@python.org  Thu Jun  1 15:38:58 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:38:58 -0400 (EDT)
Subject: [Mailman-Developers] logs
References: <20000601120803.C717@miss-janet.com>
Message-ID: <14646.30082.513809.105235@anthem.python.org>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I was just looking into my logs directory and I noticed a 10mb
    RK> bounce log file... maybe we should consider using something
    RK> like log rotating?

Yes.


From bwarsaw@python.org  Thu Jun  1 15:39:25 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:39:25 -0400 (EDT)
Subject: [Mailman-Developers] pipermail/hypermail mbox-archive
References: <20000327211501.F25139@xs4all.nl>
 <14645.29500.819830.122398@anthem.python.org>
 <20000601121945.L469@xs4all.nl>
Message-ID: <14646.30109.127864.263705@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> For the record, you can disregard the locale remark. ctime()
    TW> is *exactly* how the From_ line should store its date,
    TW> regardless of locale or what not.

Thanks.


From bwarsaw@python.org  Thu Jun  1 15:43:15 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:43:15 -0400 (EDT)
Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries
References: <14560.59360.933438.313871@anthem.cnri.reston.va.us>
 <20000328213635.A8665@xs4all.nl>
 <14561.3922.358917.646194@anthem.cnri.reston.va.us>
 <20000328231400.B8665@xs4all.nl>
 <14645.22297.479926.425407@anthem.python.org>
 <14645.24708.529869.456008@anthem.python.org>
 <14645.27097.449110.777191@anthem.python.org>
 <20000601122344.M469@xs4all.nl>
Message-ID: <14646.30339.118196.198174@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Yeah, this works. My initial reserve against making str(msg)
    TW> return the unixfrom line as well was that it broke
    TW> 'compatibility' with the regular rfc822.Message.

I think the only place where concrete rfc822.Message objects are used
(as opposed to Mailman.Message.Message objects or derived), is in the
bounce detector.  At least, everything else /should/ use Mailman's own
Message class or one derived from there.  So I'm not worried about b/w
compatibility.
    
    TW> Using repr is a good idea, I think, but it's missing one
    TW> thing: if unixfrom is empty, the mailbox will still be
    TW> fawlty. I think __repr__ should reproduce a .unixfrom line if
    TW> it's missing. I'll post a patch later today, I have to run off
    TW> to a huge sale at the local bookstore ;-)

Cool.
-Barry


From claw@kanga.nu  Thu Jun  1 17:24:18 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 01 Jun 2000 09:24:18 -0700
Subject: [Mailman-Developers] logs
In-Reply-To: Message from Ricardo Kustner <ricardo@rixhq.nu>
 of "Thu, 01 Jun 2000 12:08:03 +0200." <20000601120803.C717@miss-janet.com>
References: <20000601120803.C717@miss-janet.com>
Message-ID: <10315.959876658@kanga.nu>

On Thu, 1 Jun 2000 12:08:03 +0200 
Ricardo Kustner <ricardo@rixhq.nu> wrote:

> I was just looking into my logs directory and I noticed a 10mb
> bounce log file... maybe we should consider using something like
> log rotating? ie log.0, log.1.gz, log.2.gz etc...  or should this
> be left as a task for the admin and/or distibution maintainer?

This should be left as a task for the Admin/packager, tho it should
be noted in the README.  Depending on the list environment,
sometimes that log data can also be legal data...

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Thu Jun  1 17:29:12 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 01 Jun 2000 09:29:12 -0700
Subject: [Mailman-Developers] logs
In-Reply-To: Message from bwarsaw@python.org (Barry A. Warsaw)
 of "Thu, 01 Jun 2000 10:38:58 EDT." <14646.30082.513809.105235@anthem.python.org>
References: <20000601120803.C717@miss-janet.com>  <14646.30082.513809.105235@anthem.python.org>
Message-ID: <10382.959876952@kanga.nu>

On Thu, 1 Jun 2000 10:38:58 -0400 (EDT) 
Barry A Warsaw <bwarsaw@python.org> wrote:

>>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

RK> I was just looking into my logs directory and I noticed a 10mb
RK> bounce log file... maybe we should consider using something like
RK> log rotating?

> Yes.

No.

Apache doesn't do its own log rotation, Sendmail, Postfix, and Exim
don't do their own log rotation (tho they provide tools to do it
"properly").  And all of them, like MailMan, maintain their own logs
rather than running thru syslogd.

I see no reason for Mailman to be anny different.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@python.org  Thu Jun  1 17:31:12 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 12:31:12 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005121946020.20246-100000@dogpound.vnet.net>
Message-ID: <14646.36816.721480.344363@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Using current cvs code (as of May 12 2000 19:50 EST) I get the
    MD> following error when I hit the 'view other subscriptions'
    MD> option with the correct password.

    MD> Sometimes it would take a while (maybe a minute or 2) for it
    MD> to even display this.  And i know the system is not loaded
    MD> down.

The problem turned out to be the use of map_maillists() in
handle_opts.py when viewing other subscriptions.  This had a
side-effect of unlocking the list, so when Save() tried to refresh the
lock, it bombed.  See my recent checkin for the fix.

-Barry


From bwarsaw@python.org  Thu Jun  1 22:49:47 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 17:49:47 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
Message-ID: <14646.55931.299948.492757@anthem.python.org>

Hi Harald,

I've finally gotten around to looking at your LockFile.py changes.
Note that I checked in a different change to fix the actual problem
with "view other subscriptions", but I still want to comment on your
diffs.

    HM>  The above strangeness was probably caused by a buglet in the
    HM> current CVS LockFile.py; I believe it gets the order of
    HM> unlink() calls wrong.

    HM> As I see it, it is more important for the lock file to never
    HM> have a link count that is neither 0 or 2 than it is to make
    HM> sure there are no tempfile turds.  This implies that the real
    HM> lock file should be unlink()ed before the tempfile, and not
    HM> the other way around.  Here's a (untested) patch (which also
    HM> touches on some other issues I noticed while I was at it :):

Thinking about this more, I disagree.  I think it is perfectly fine to
expect the linkcount to be 0, 1, or 2, but never greater than 2.
Let's look at each in detail.  Remember we're talking about the link
count of the shared global file, not the process specific tmp files.

Linkcount == 0: this just means that lockfile doesn't exist, so we
don't actually ever get here (we'd get an ENOENT instead).

Linkcount == 1: One way this can happen is due to a race condition
between proc1 which is in the middle of unlocking and proc2 which has
just laid claim to the lock.  Here's how this goes:

    -- proc1 had a valid lock and is now in unlock().  It unlinks its
       tmpfname, leaving lockfile's linkcount == 1

    -- proc2 comes along and links lockfile to /its/ tmpfname.  This
       fails because lockfile already exists, but linkcount == 1.  I
       believe we can just ignore this case and loop around to attempt
       acquisition again next time.

    -- proc1 now unlinks lockfile, relinquishing the lock

    -- proc2 loops and attempts to link lockfile -> tmpfname

This situation was broken but only because the big if/else in the
OSError clause in lock() didn't take this race condition into account.
I think the better fix is to just catch the linkcount==1 case, and
essentially ignore it.  To me, the more important invariant is that if
the global lockfile exists, somebody else has the lock.  Changing the
order of unlinks breaks this invariant.

Linkcount == 2: Somebody's got a valid lock.

Linkcount > 2: Somebody's messing with us.  I cannot see any situation
where linkcount would be > 2 without "outside influences".

Okay, now to specific changes in your patch.  Apologies for the ugly
nature of the citations.

    | +                    # HM: I don't understand why the tempfile should be
    | +                    # unlinked in this situation.  I think that all it w
    | +                    # is confuse things, so I've commented it out.
    | +                    ## os.unlink(self.__tmpfname)

You're right, this should not remove the tmpfname.  This would be like
only half giving up the lock!  I've removed this unlink() call.

    | -        NotLockedError, unless optional `unconditional' is true.
    | +        NotLockedError, unless optional `unconditionally' is true.

Applied.

    | -        islocked = 0
    | -        try:
    | -            islocked = self.locked()
    | -        except OSError, e:
    | -            if e.errno <> errno.ENOENT: raise
    | +        islocked = self.locked()

Applied.

    | -        try:
    | -            winner = self.__read()
    | -            if winner:
    | -                os.unlink(winner)
    | -        except OSError, e:
    | -            if e.errno <> errno.ENOENT: raise
    | +        # Try finding the name of the old winner's temp file.  We're ass
    | +        # the winner process has hung or died, so we should try cleaning
    | +        # their mess.
    | +        winner = self.__read()

Applied.
    
        HM> I noticed another apparent inconsistency in LockFile.py,
        HM> too: The comment at the start of __break() seems to imply
        HM> that calling __touch() will totally remove the race
        HM> condition, while I believe all it does is make the race
        HM> condition a little less likely.

You're right of course.  I've updated the comment, but not changed the
code because I think we're adequately defensive in the face of this
race condition.  __break() doesn't acquire a lock and it doesn't
matter if two processes attempt to break the same lock at the same
time.

Thanks very much for looking at all this.  I'm about to check in a new
version of LockFile.py which also contains a slightly revised unit
test.

Cheers,
-Barry


From bigdog@dogpound.vnet.net  Fri Jun  2 00:49:27 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 19:49:27 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: <14646.55931.299948.492757@anthem.python.org>
Message-ID: <Pine.LNX.4.21.0006011942340.6933-100000@dogpound.vnet.net>

On Thu, 1 Jun 2000, Barry A. Warsaw wrote:

> Thanks very much for looking at all this.  I'm about to check in a new
> version of LockFile.py which also contains a slightly revised unit
> test.

Bingo :)  Thanks you 2.  For whatever you did its working just fine.

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

Spelling checkers at maximum!  Fire!




From bwarsaw@python.org  Fri Jun  2 04:15:17 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Thu, 1 Jun 2000 23:15:17 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <14646.55931.299948.492757@anthem.python.org>
 <Pine.LNX.4.21.0006011942340.6933-100000@dogpound.vnet.net>
Message-ID: <14647.9925.965238.902419@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Bingo :) Thanks you 2.  For whatever you did its working just
    MD> fine.

Excellent!


From bwarsaw@python.org  Fri Jun  2 05:24:25 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 00:24:25 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <chuqui@plaidworks.com>
 <p04310101b553a3d1f7b7@[209.239.169.197]>
 <E12vFPl-0007n9-00@rioja.localnet>
Message-ID: <14647.14073.539894.758106@anthem.python.org>

Wonderful discussion guys!  Very deep, and there's plenty of good
ideas to keep a dozen clones of each of us busy for years.  And all
packed into 24 messages.

I'll try to respond in more detail over the next several days, but I
haven't seen anything that is either critical or doable for 2.0beta3,
and probably not for 2.0 final.  One possible exception is the
batching algorithm for #recipts > SMTP_MAX_RCPTS.

G'night,
-Barry


From Nigel.Metheringham@VData.co.uk  Fri Jun  2 17:53:38 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 02 Jun 2000 17:53:38 +0100
Subject: [Mailman-Developers] Old bug, new recurrance.... archiver gets some dates wrong
Message-ID: <E12xuhW-0006pW-00@rioja.localnet>

I thought I had nailed this bug before... but its back to haunt me in 
2.0b2 - I know it was fixed in my version previously and thought it had 
made it to CVS :-)

In some cases, basically when timezones on incoming messages conspire 
with the start of the month, the archiver gets the archive date not 
quite right - specifically it gets the day of the month negative and 
the month one up on what it should be.

For an example look at:-
  http://www.exim.org/pipermail/exim-users/

and admire the archive for -2 June 2000.

I'll find and fix this when I have a moment (over the w/e).  I would be 
interested if someone can tell me a better way of fixing the archive 
that delete and rebuild - that archive is huge and doing a rebuild 
takes lots of time.

	Nigel.

-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From bwarsaw@python.org  Fri Jun  2 21:38:18 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 2 Jun 2000 16:38:18 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
Message-ID: <14648.6970.199791.120070@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> The important thing is to work on optimizing dropping mail
    CVR> into the MTA, and then letting the MTA do its job (and tune
    CVR> it!). In my work, the biggest problems is the way MLMs drop
    CVR> mail off for delivery -- usually by doing nothing more than a
    CVR> single-threaded drop sorted by a reversed address. That puts
    CVR> domain names together (but really ought to be a sort by MX
    CVR> instead, it's quite sub-optimal, especially with big
    CVR> domain-hosting sites like iname.com), but still limits
    CVR> delivery to how fast the MTA will accept addresses, and
    CVR> that's limited by DNS, since sendmail resolves addresses as
    CVR> it accepts mail...

This is very interesting.  I've just added some code to SMTPDirect.py
to support multiple MTA drop-off threads.  I actually see worse
performance with this code, which either means I screwed up the
implementation or Something Else Is Going On.

i set up a 25k+ list and timed the drop-off.  With sequential, single
threaded delivery, I could deliver a small message to Postfix in about
41 seconds.  Chunking the recips to 500 gave me about 50 chunks, and
if I give each chunk it's own thread, I'm seeing no better than 58
seconds for delivery.

I have a suspicion about what else might be happening, but I'm not
sure.  Currently, Python has a fairly limited threading model.  There
is a global interpreter lock which only allows a single thread to be
running Python code at any time.  This works well if you're doing a
lot of I/O, but not so well for other cpu intensive calculations.
Eventually, Python will probably support "free threading" which will
allow multiple threads running Python code.

Now to my eyes, the drop-off part is mostly I/O, shoving data across
the socket, so I dunno.  And maybe based on what Chuq says above, the
threading approach would work better for Sendmail than for Postfix.
So I think I will keep the code, but disable it by default and let you
guys play with it.  Please note that not all Python interpreters are
built with threading enabled.  It looks like the latest RH rpms are
built with threading, but if you've built Python 1.5.2 from source,
you'll have to explicitly configure --with-threads (I hope to change
that for Python 1.6).

An alternative would be to fork off separate processes, but that seems
too heavyweight, and makes collating the failures from the
subprocesses more difficult.

    CVR> I'd guess you can get the first 90% simply by setting up
    CVR> mailman to deliver using four threads: .com, .net,
    CVR> .edu/.us/.ca and everything else, and allowing people to
    CVR> configure extra threads if the capacity allows (and I'd do
    CVR> that by splitting each feed in half), and then coming up with
    CVR> guides on how to tune the MTA for fast delivery (I'm just
    CVR> starting to figure out sendmail 8.10, but it looks like a
    CVR> nice improvement over earlier releases).

So with the next check-in, the chunking algorithm is to create 4
buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
back-filled.

Eventually we'll need to separate out the entire hand-off process from
the main process, but that's not currently feasible.  I think this is
the best I can do for 2.0.

-Barry


From bwarsaw@python.org  Fri Jun  2 22:11:15 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 17:11:15 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
Message-ID: <14648.8947.346431.40404@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> True, but a one page README.<mlm> page in the disto for each
    CVR> reasonably supported MLM isn't a bad thing, and better than
    CVR> what anyone has.

Did you typo here or am I misunderstanding?  Mailman has README's for
Qmail and Sendmail.  They could probably be elaborated on, and other
MTAs could be added, but is this what you were looking for?

-Barry


From bwarsaw@python.org  Fri Jun  2 22:17:05 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 17:17:05 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
 <23919.959230369@kanga.nu>
Message-ID: <14648.9297.305732.107780@anthem.python.org>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    JCL> While I really have no say here, were I Barry and Co I'd be
    JCL> comfortable with targetting Mailman as able to handle a
    JCL> mid/high 6digit subscriber base list on mid-range PC-class
    JCL> hardware given suitable system configuration.  That wouldn't
    JCL> be the target of course, just the "it must be physically able
    JCL> to work here" metric.

Bingo.

    JCL> Were delivery to the MTA seperated from the receipt or CGI
    JCL> process (ie mail is received, the RCPT list attached to it,
    JCL> and the tuple placed on a queue for background processing via
    JCL> forked process or cron job), we wouldn't be having this
    JCL> discussion.  Its a fairly invasive change to the current
    JCL> Mailman architecture, but making the whole reciept/broadcast
    JCL> aspect asynchronous offers some really pleasant future
    JCL> avenues.

Yes.

    JCL> Just been poking around there and noticed that your archives
    JCL> seem to be inop (dead disk).  If you're interested I've been
    JCL> messing about with MHonArc and PHP in my spare time and have
    JCL> almost finished getting a setup that:

    JCL>   -- Allows archived messages to be replied to on the web via
    JCL> the archive page (replies post to the list).

    JCL>   -- Templates (PHPLIB) the entire archive appearance.  All
    JCL> MHonArc does is the parsing and data extraction.

    JCL>   -- Supports archive searching by MessageID.  I've an MTA
    JCL> hack that inserts a MessageID-based URL into all outgoing
    JCL> Mailman list traffic so the user can just hit the URL and be
    JCL> taken to that message in the archives (searches the MHonArc
    JCL> DB, useful for thread reference etc).

    JCL> Hopefully I'll get something worth public viewing sometime
    JCL> next week.

Please do, these sound very cool.  One of the things high on my list
is to templatize the UI for the web interface so it can be integrated
into existing sites more seamlessly.  I know some guys who are doing a
cool project in Python that might provide the necessary functionality,
but on the other hand PHP might be fun to look into to.

-Barry


From coolo@kde.org  Fri Jun  2 22:35:06 2000
From: coolo@kde.org (Stephan Kulow)
Date: Fri, 02 Jun 2000 23:35:06 +0200
Subject: [Mailman-Developers] listing subscriptions by domain
Message-ID: <3938288A.5E0C9565@kde.org>

Hi!

As the bounce detecter can't detect all bounces correctly
(which is obviously not its fault, but those not following
any standard ;( it would be from time to time very useful
beeing able to sort the members after the domain. With the
>600 subscriptions on one of our lists it can get very hairy
to find the subscription from the domain saying "the user
you wrote to doesn't exist" without saying what user.

Greetings, Stephan

-- 
... but you ain't had mine


From mentor@alb-net.com  Sat Jun  3 01:16:52 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Fri, 2 Jun 2000 20:16:52 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
Message-ID: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>

Just updated the CVS tree to the latest (@ 19:31 EST).

Below is the error I get. I sent a message to the test list (on different
installation then the production one) and got many many copies of the same
messages. They just kept coming and coming. Different date stamp with
bunch coming with the same date/time stamp. Only ne copy goes into the
archives though, with approval or without.

To stop the messages coming, I had to delete all the files in /qfiles .

later,
mentor

---
Jun 02 19:59:16 2000 (8724) Delivery exception: LogMsg
Jun 02 19:59:16 2000 (8724) Traceback (innermost last):
  File "/opt/home/mmtest/Mailman/Handlers/HandlerAPI.py", line 74, in
DeliverTo$
    func(mlist, msg, msgdata)
  File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 53, in
process
    failures = deliver(mlist, msg, chunk)
  File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 128, in
deliver
    mlist.LogMsg('smtp',
AttributeError: LogMsg




From Dan Mick <Dan.Mick@West.Sun.COM>  Sat Jun  3 01:23:01 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Fri, 2 Jun 2000 17:23:01 -0700 (PDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
Message-ID: <200006030023.RAA24087@utopia.west.sun.com>

Oops.  Looks like SMTPDirect.py didn't get the "LogMsg becomes syslog()"
fix applied to it.

> Just updated the CVS tree to the latest (@ 19:31 EST).
> 
> Below is the error I get. I sent a message to the test list (on different
> installation then the production one) and got many many copies of the same
> messages. They just kept coming and coming. Different date stamp with
> bunch coming with the same date/time stamp. Only ne copy goes into the
> archives though, with approval or without.
> 
> To stop the messages coming, I had to delete all the files in /qfiles .
> 
> later,
> mentor
> 
> ---
> Jun 02 19:59:16 2000 (8724) Delivery exception: LogMsg
> Jun 02 19:59:16 2000 (8724) Traceback (innermost last):
>   File "/opt/home/mmtest/Mailman/Handlers/HandlerAPI.py", line 74, in
> DeliverTo$
>     func(mlist, msg, msgdata)
>   File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 53, in
> process
>     failures = deliver(mlist, msg, chunk)
>   File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 128, in
> deliver
>     mlist.LogMsg('smtp',
> AttributeError: LogMsg
> 
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers




From chuqui@plaidworks.com  Sat Jun  3 01:13:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 2 Jun 2000 17:13:00 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.8947.346431.40404@anthem.python.org>
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>	<p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>	<p04310106b5523d17e16c@[209.239.169.197]>
 <14648.8947.346431.40404@anthem.python.org>
Message-ID: <p04310102b55dfdeb8610@[209.239.169.197]>

>     CVR> True, but a one page README.<mlm> page in the disto for each
>     CVR> reasonably supported MLM isn't a bad thing, and better than
>     CVR> what anyone has.
>
>Did you typo here or am I misunderstanding?  Mailman has README's for
>Qmail and Sendmail.  They could probably be elaborated on, and other
>MTAs could be added, but is this what you were looking for?

Yes, that's what I'm suggesting -- adding to or elaborating on these 
READMEs to discuss how to set them up and optimize them.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Sat Jun  3 01:18:34 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 2 Jun 2000 17:18:34 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.6970.199791.120070@anthem.python.org>
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
 <14648.6970.199791.120070@anthem.python.org>
Message-ID: <p04310103b55dfe5ba031@[209.239.169.197]>

At 4:38 PM -0400 6/2/2000, bwarsaw@python.org wrote:

>This is very interesting.  I've just added some code to SMTPDirect.py
>to support multiple MTA drop-off threads.  I actually see worse
>performance with this code, which either means I screwed up the
>implementation or Something Else Is Going On.

Are you talking about performance loading into the MTA? Or delivery?

I'll bet one thing in the Something Else category is disk I/O. That's 
what usually nukes MTA's first (and foremost).

>the socket, so I dunno.  And maybe based on what Chuq says above, the
>threading approach would work better for Sendmail than for Postfix.


I really, really need to sit down and beat postfix into a pulp. But 
I've got four sites to ship before I can (two of them based on 
mailman). I'm typing as fast as I can... but I really want to get a 
handle on postfix....

>So I think I will keep the code, but disable it by default and let you
>guys play with it.

Very fair. It's nice the hooks are there, and IMHO, figuring out how 
to use it properly, tune is and all of that stuff sounds like a 
perfect reason for a 2.1 release. I sure wouldn't hold up other parts 
of 2.0 for this...

>Eventually we'll need to separate out the entire hand-off process from
>the main process, but that's not currently feasible.  I think this is
>the best I can do for 2.0.

I think this is a great start, and I agree -- there's enough going on 
with 2.0 that we don't want to wait for this to release it. It'll 
give us time to sit down and research the beast in different 
environments more, too.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bwarsaw@python.org  Sat Jun  3 05:12:49 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:12:49 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
References: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>
Message-ID: <14648.34241.919800.925959@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> Just updated the CVS tree to the latest (@ 19:31 EST).

Yikes!  Sorry, we had a bunch of thunderstorms so I had to shut my
machine down (don't have an ups yet) before I could finish checking
things in.  I'll finish it up now.  Let's see if that fixes things for
you.

-Barry


From bwarsaw@python.org  Sat Jun  3 05:14:47 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Sat, 3 Jun 2000 00:14:47 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
 <14648.8947.346431.40404@anthem.python.org>
 <p04310102b55dfdeb8610@[209.239.169.197]>
Message-ID: <14648.34359.712339.289069@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    >>  Did you typo here or am I misunderstanding?  Mailman has
    >> README's for Qmail and Sendmail.  They could probably be
    >> elaborated on, and other MTAs could be added, but is this what
    >> you were looking for?

    CVR> Yes, that's what I'm suggesting -- adding to or elaborating
    CVR> on these READMEs to discuss how to set them up and optimize
    CVR> them.

Great idea, and I eagerly await contributions! :)

-Barry


From bwarsaw@python.org  Sat Jun  3 05:31:26 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Sat, 3 Jun 2000 00:31:26 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
 <14648.6970.199791.120070@anthem.python.org>
 <p04310103b55dfe5ba031@[209.239.169.197]>
Message-ID: <14648.35358.861812.161122@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    >> This is very interesting.  I've just added some code to
    >> SMTPDirect.py to support multiple MTA drop-off threads.  I
    >> actually see worse performance with this code, which either
    >> means I screwed up the implementation or Something Else Is
    >> Going On.

    CVR> Are you talking about performance loading into the MTA? Or
    CVR> delivery?

Loading into the MTA.

    CVR> I'll bet one thing in the Something Else category is disk
    CVR> I/O. That's what usually nukes MTA's first (and foremost).

Yes.  I didn't even mention the times I was getting before shutting
off syslogd for mail.* -- it was much worse.  But the times I quoted
are (AFAICT) just the I/O that Postfix does.  Mailman isn't doing any
different I/O for threaded delivery than for sequential delivery.

    CVR> I really, really need to sit down and beat postfix into a
    CVR> pulp.

Ooo, can I watch? :)
    
    CVR> But I've got four sites to ship before I can (two of them
    CVR> based on mailman). I'm typing as fast as I can... but I
    CVR> really want to get a handle on postfix....

Cool.

    >> So I think I will keep the code, but disable it by default and
    >> let you guys play with it.

    CVR> Very fair. It's nice the hooks are there, and IMHO, figuring
    CVR> out how to use it properly, tune is and all of that stuff
    CVR> sounds like a perfect reason for a 2.1 release. I sure
    CVR> wouldn't hold up other parts of 2.0 for this...

    >> Eventually we'll need to separate out the entire hand-off
    >> process from the main process, but that's not currently
    >> feasible.  I think this is the best I can do for 2.0.

    CVR> I think this is a great start, and I agree -- there's enough
    CVR> going on with 2.0 that we don't want to wait for this to
    CVR> release it. It'll give us time to sit down and research the
    CVR> beast in different environments more, too.

That's a plan then.  I have one more thing I want to play with for
SMTPDirect.py and then that should be it.  Guido's getting married
this weekend so I'll be mostly off-line.  Figure 2.0b3 early next week
and then fast track toward 2.0 final.  I'm ready to move on.

Cheers,
-Barry


From bwarsaw@python.org  Sat Jun  3 05:49:36 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:49:36 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
References: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>
 <14648.34241.919800.925959@anthem.python.org>
Message-ID: <14648.36448.545779.386139@anthem.python.org>

>>>>> "BAW" == Barry A Warsaw <bwarsaw@python.org> writes:

    BAW> Yikes!  Sorry, we had a bunch of thunderstorms so I had to
    BAW> shut my machine down (don't have an ups yet) before I could
    BAW> finish checking things in.  I'll finish it up now.  Let's see
    BAW> if that fixes things for you.

All done now.


From claw@kanga.nu  Sat Jun  3 06:20:47 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 02 Jun 2000 22:20:47 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from bwarsaw@python.org
 of "Sat, 03 Jun 2000 00:31:26 EDT." <14648.35358.861812.161122@anthem.python.org>
References: <14634.46608.820841.306190@localhost.localdomain> <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es> <14635.15647.180980.890136@localhost.localdomain> <p04310100b551090293c0@[17.216.27.193]> <14648.6970.199791.120070@anthem.python.org> <p04310103b55dfe5ba031@[209.239.169.197]>  <14648.35358.861812.161122@anthem.python.org>
Message-ID: <13005.960009647@kanga.nu>

On Sat, 3 Jun 2000 00:31:26 -0400 (EDT) 
bwarsaw  <bwarsaw@python.org> wrote:

>>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

> Yes.  I didn't even mention the times I was getting before
> shutting off syslogd for mail.* -- it was much worse.  

Just setting syslog to not sync on every message can boost
performance enourmously.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From thomas@xs4all.net  Sat Jun  3 23:39:00 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 4 Jun 2000 00:39:00 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.9297.305732.107780@anthem.python.org>; from bwarsaw@python.org on Fri, Jun 02, 2000 at 05:17:05PM -0400
References: <E12ucWi-0003Qo-00@rioja.localnet> <18431.959208098@kanga.nu> <p04310104b5521cbd4b6f@[209.239.169.197]> <20932.959218689@kanga.nu> <p04310106b5523d17e16c@[209.239.169.197]> <23919.959230369@kanga.nu> <14648.9297.305732.107780@anthem.python.org>
Message-ID: <20000604003900.S469@xs4all.nl>

On Fri, Jun 02, 2000 at 05:17:05PM -0400, Barry A. Warsaw wrote:

[ JC Lawrence about archive/database/php ]

>     JCL> Hopefully I'll get something worth public viewing sometime
>     JCL> next week.

> Please do, these sound very cool.  One of the things high on my list
> is to templatize the UI for the web interface so it can be integrated
> into existing sites more seamlessly.  I know some guys who are doing a
> cool project in Python that might provide the necessary functionality,
> but on the other hand PHP might be fun to look into to.

Not that I disagree (oh, no! It sounds cool! :) but wasn't there something
about Mailman had to be coded in Python ? Or is a PHP frontend OK ? Or only
if it's optional, or not included in the distribution ?

I am still looking at HyperMail/pipermail, but if these things are in the
running, I might just do some cleanup and fix some of the performance
problems. (Like Hypermail choking on attachements and stuff.) So it's still
useable for the bare-bones kind of server ;) If not, well, I'll take some
more time and not worry too much about features such as searchable indexes
and such.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From chuqui@plaidworks.com  Sun Jun  4 07:59:11 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sat, 3 Jun 2000 23:59:11 -0700
Subject: [Mailman-Developers] failure upgrading to current CVS
Message-ID: <p04310109b55fadaf2bcd@[209.239.169.197]>

I tried to move to the current CVS tonight, and ran into a glitch.

I copied a fresh copy of mailman from CVS, copied over the 
config.status and ran it, then ran "make install". Everything went 
fine until it tried to compile versions.py, then:

Compiling /home/mailman/Mailman/versions.py ...
Upgrading from version 0x20000b2 to 0x20000b3
Updating mailing list:  test
Traceback (innermost last):
   File "bin/update", line 282, in ?
     dolist(list)
   File "bin/update", line 77, in dolist
     l = MailList.MailList(list)
   File "/home/mailman/Mailman/MailList.py", line 74, in __init__
     self.Lock()
   File "/home/mailman/Mailman/MailList.py", line 1350, in Lock
     self.__lock.lock(timeout)
   File "/home/mailman/Mailman/LockFile.py", line 284, in lock
     self.__break()
   File "/home/mailman/Mailman/LockFile.py", line 408, in __break
     os.unlink(winner)
OSError: [Errno 2] No such file or directory: '27659 
/home/mailman/locks/test.lo
ck.newboy.plaidworks.com.27659 960076921.049111\012'


I went into the locks subdir and there were a bunch of locks, some 
new, some old. I deleted everything, and ran make install again. That 
time, it worked.

Looks like b2 left something around that caused the ugprade to lurch. 
It might make sense ot have some kind of cron job that deletes locks 
older than N days, just to be safe?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From Nigel.Metheringham@VData.co.uk  Sun Jun  4 20:29:10 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Sun, 04 Jun 2000 20:29:10 +0100
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Fri, 02 Jun 2000 17:13:00 PDT." <p04310102b55dfdeb8610@[209.239.169.197]>
Message-ID: <E12yg58-0002Y3-00@rioja.localnet>

chuqui@plaidworks.com said:
> Yes, that's what I'm suggesting -- adding to or elaborating on these
> READMEs to discuss how to set them up and optimize them. 

The exim information has now got a set of boilerplate recommendations 
on how I configure exim for what I hope is optimal handling of largish 
lists on my limited machine.  I can dump that into a text file if you 
wish for a distribution based document.

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Nigel.Metheringham@VData.co.uk  Sun Jun  4 20:39:23 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Sun, 04 Jun 2000 20:39:23 +0100
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from bwarsaw@python.org (Barry A. Warsaw)
 of "Fri, 02 Jun 2000 17:17:05 EDT." <14648.9297.305732.107780@anthem.python.org>
Message-ID: <E12ygF1-0002Yr-00@rioja.localnet>

There is a problem that its hard to come up with metrics for best large 
recipient list delivery that work across a range of MTAs.

My own feeling (experience based feeling, but I haven't specifically 
sat down and benchmarked/analysed its behaviour) for exim is that I 
would tend to have a maximum number of recipients for a single SMTP 
transaction of ~500 recipients.  I would tend to keep simultaneous 
injects down to around 4 at a time... although this has even less basis 
that the 500 recipients limit.  Exim will take advantage of multiple 
recipients on the same MX, but you can basically assume it will not 
take advantage of multiple queued messages going to the same MX (except 
under particular circumstances).  Hence I would in general do the 
sort/clump by reversed domain name thing since that should win in many 
cases.


bwarsaw@python.org said:
> So with the next check-in, the chunking algorithm is to create 4
> buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
> these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
> back-filled. 

Thats a very parochial view of the world (he says tongue firmly in 
cheek).  Us UK based people would probably find a different balance 
would work better for us :-)

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Harald.Meland@usit.uio.no  Sun Jun  4 21:34:12 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 22:34:12 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Nigel Metheringham's message of "Sun, 04 Jun 2000 20:29:10 +0100"
References: <E12yg58-0002Y3-00@rioja.localnet>
Message-ID: <d6dd7lxdw3f.fsf@octarine.uio.no>

[Nigel Metheringham]

> chuqui@plaidworks.com said:
> > Yes, that's what I'm suggesting -- adding to or elaborating on these
> > READMEs to discuss how to set them up and optimize them. 
> 
> The exim information has now got a set of boilerplate
> recommendations on how I configure exim for what I hope is optimal
> handling of largish lists on my limited machine.  I can dump that
> into a text file if you wish for a distribution based document.

That would be great, please do.
-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 21:48:03 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 22:48:03 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Nigel Metheringham's message of "Sun, 04 Jun 2000 20:39:23 +0100"
References: <E12ygF1-0002Yr-00@rioja.localnet>
Message-ID: <d6d8zwldvgc.fsf@octarine.uio.no>

[Nigel Metheringham]

> bwarsaw@python.org said:
> > So with the next check-in, the chunking algorithm is to create 4
> > buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
> > these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
> > back-filled. 
> 
> Thats a very parochial view of the world (he says tongue firmly in 
> cheek).  Us UK based people would probably find a different balance 
> would work better for us :-)

I had to look up "parochial".  Having done so, I believe that Norway
based people would tend to agree :-)

For most people, I guess that doing this the merkin way is good enough
-- it keeps the .com/.net/.org addresses separated from their more
frequent CTLD addresses.

But: What was the reason for not simply doing a sort on reversed
domain?
-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 22:15:58 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 23:15:58 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: bwarsaw@python.org's message of "Thu, 1 Jun 2000 17:49:47 -0400 (EDT)"
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
Message-ID: <d6d4s79du5t.fsf@octarine.uio.no>

--=-=-=

[Barry A. Warsaw]

>     HM> As I see it, it is more important for the lock file to never
>     HM> have a link count that is neither 0 or 2 than it is to make
>     HM> sure there are no tempfile turds.  This implies that the real
>     HM> lock file should be unlink()ed before the tempfile, and not
>     HM> the other way around.  Here's a (untested) patch (which also
>     HM> touches on some other issues I noticed while I was at it :):
> 
> Thinking about this more, I disagree.  I think it is perfectly fine
> to expect the linkcount to be 0, 1, or 2, but never greater than 2.

I still don't see why there's a need for the "intermediate" state
(neither fully locked nor fully unlocked) with the shared lockfile
having a link count of 1.  I think it just makes the locking logic
more complicated to understand.

Also keep in mind that calling __linkcount() is not an atomic
operation.  Doing state tests on the return value of multiple calls to
this method makes my race-condition-meter howl rather irritatingly. :)

> To me, the more important invariant is that if the global lockfile
> exists, somebody else has the lock.  Changing the order of unlinks
> breaks this invariant.

Does it?  The shared lockfile is, in the current CVS code, unlinked
from two places.

Obviously, it needs to be unlinked when someone calls unlock().  By
doing the unlink of the shared lockfile before unlinking the tempfile,
you release the lock a tad earlier -- but that's not of any
consequence, as you were going to release the lock before returning
anyway.

The other method that currently unlinks the shared lockfile is
__break().  The purpose of that method is to remove lockfiles that
some other process has failed to release within the lock's lifetime.
Thus, this method breaks the invariant you mention *by design*.

By reversing the order of unlinks, we reduce the number of lock
failure modes.  In my book, that's a good thing. :)

Here's a quick patch to illustrate how I believe things could be
changed without breaking the "lockfile exists <=> lock is taken"
invariant:


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline

Index: LockFile.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/LockFile.py,v
retrieving revision 1.18
diff -u -r1.18 LockFile.py
--- LockFile.py	2000/06/01 22:08:10	1.18
+++ LockFile.py	2000/06/04 21:14:12
@@ -300,18 +300,21 @@
         islocked = self.locked()
         if not islocked and not unconditionally:
             raise NotLockedError
-        # Remove our tempfile
-        try:
-            os.unlink(self.__tmpfname)
-        except OSError, e:
-            if e.errno <> errno.ENOENT: raise
         # If we owned the lock, remove the global file, relinquishing it.
+        # By removing the lockfile before the tempfile, we ensure that
+        # the link count of the lockfile always will be either 0 or 2,
+        # and thus reduce the number of lock failure modes.
         if islocked:
             try:
                 os.unlink(self.__lockfile)
             except OSError, e:
                 if e.errno <> errno.ENOENT: raise
         self.__writelog('unlocked')
+        # Remove our tempfile
+        try:
+            os.unlink(self.__tmpfname)
+        except OSError, e:
+            if e.errno <> errno.ENOENT: raise
 
     def locked(self):
         """Returns 1 if we own the lock, 0 if we do not.
@@ -399,18 +402,19 @@
             self.__touch(self.__lockfile)
         except OSError, e:
             if e.errno <> errno.EPERM: raise
+        # Try getting the name of the old winner's temp file.
+        winner = self.__read()
+        # Remove the global lockfile.  This actually breaks the lock.
+        try:
+            os.unlink(self.__lockfile)
+        except OSError, e:
+            if e.errno <> errno.ENOENT: raise
         # Try to remove the old winner's temp file, since we're assuming the
         # winner process has hung or died.  Don't worry too much if we can't
         # unlink their temp file -- this doesn't wreck the locking algorithm,
         # but will leave temp file turds laying around, a minor inconvenience.
-        winner = self.__read()
         if winner:
             os.unlink(winner)
-        # Now remove the global lockfile, which actually breaks the lock.
-        try:
-            os.unlink(self.__lockfile)
-        except OSError, e:
-            if e.errno <> errno.ENOENT: raise
 
     def __sleep(self):
         interval = random.random() * 2.0 + 0.01

--=-=-=
Content-Disposition: inline

-- 
Harald

--=-=-=--


From Harald.Meland@usit.uio.no  Sun Jun  4 23:02:00 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 05 Jun 2000 00:02:00 +0200
Subject: [Mailman-Developers] .nfs* lock files
In-Reply-To: bwarsaw@python.org's message of "Wed, 31 May 2000 18:38:30 -0400 (EDT)"
References: <20000517130456.J17215@hendrix.amd.com>
 <d6dbt23ho0y.fsf@octarine.uio.no>
 <14645.37990.379956.828785@anthem.python.org>
Message-ID: <d6dzop1cdgn.fsf@octarine.uio.no>

[Barry A. Warsaw]

> >>>>> "HM" == Harald Meland <Harald.Meland@usit.uio.no> writes:
> 
>     HM> Cheap shot at making this post on-topic: Should there be a
>     HM> cron script (possibly cron/checkdbs will do) to warn the site
>     HM> admin about lists that have been corrupted?
> 
> I could probably elaborate on the mechanism in MailList.Load() --
> see the CVS tree -- where if config.db is missing, it'll fallback to
> config.db.last.  If it falls back, then it shutil.copy()'s
> config.db.last to config.db so the logic in Save() doesn't need to
> be changed.

Yup, nice work!

I'm wondering whether it would be possible to take things one step
further, though.

No matter how foolproof we try making Save(), the ultimate test is
really whether Load() succeeds.  Thus, why not let Load() be the one
to do the config.db -> config.db.last rotation?

I'm thinking of a mechanism along these lines:

  Save():
    1. Write new db to tempfile, e.g. config.db.<pid>.<host>
    2. If successful, rename() tempfile on top of config.db

  Load():
    1. Try loading config.db
    2. If successful, make config.db.last a hardlink to current
       config.db (overwriting previous config.db.last)
    3. If loading config.db failed, try loading config.db.last
    4. If loading of config.db.last was successful, make config.db a
       hardlink to config.db.last
    5. Failure.  Maybe notify someone?

There are some locking issues that would have to be resolved (Load()
can be used with unlocked lists), but I think this is doable.  If it
is, we'd gain a "last known good configuration" mechanism.

> We could probably do the same thing if the unmarshalling of
> config.db fails.  But why you'd get a MemoryError is beyond me,
> unless the corruption tickles a bug in Python.

The (current) representation of some marshalled objects are on the
form

  type identifier (a single character, e.g. 's' for string)
  size of the object (a 32-bit integer, e.g. '\003\000\000\000')
  contents of the object (e.g. 'foo')

By changing the size field in a marshalled string, it is quite easy to
produce a MemoryError (assuming your machine doesn't have huge amounts
(in the example below: 1GB) of memory available, in which case
executing the statements below might not be a very good idea :)

  $ python
  Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> import marshal
  >>> marshal.loads('s\000\000\000\100')
  Traceback (innermost last):
    File "<stdin>", line 1, in ?
  MemoryError

-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 23:41:13 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 05 Jun 2000 00:41:13 +0200
Subject: [Mailman-Developers] SMTPDirect.py and logs/post
In-Reply-To: Nigel Metheringham's message of "Wed, 31 May 2000 12:14:13 +0100"
References: <E12x6Rx-0002k6-00@rioja.localnet>
Message-ID: <d6dvgzpcbna.fsf@octarine.uio.no>

[Nigel Metheringham]

> bwarsaw@python.org said:
> > Sendmail.py logs the list name, the sender and the message size.  What
> > information would you like to add?  All of those? 
> 
> The SMTP response from the trailing . of the DATA section would be
> useful - that contains the MTA queue id on many systems.

I agree, although that isn't easily accessible information when using
the smtplib.SMTP.sendmail() interface.

Looking at smtplib.py, I think one might argue that the data() method
could store the text part of it's final response for later perusal,
along the same lines as is done in the ehlo() and helo() methods.

If such change isn't deemed general enough to go into smtplib.py, we
could get this behaviour of data() by making a simple subclass of
smtplib.SMTP for Mailman use.

Should I try knocking together a patch?

> If this can't be done, the message-id would be useful.

I'd say both those things can be pretty useful.
-- 
Harald


From marc_news@valinux.com  Mon Jun  5 03:07:27 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 4 Jun 2000 19:07:27 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
Message-ID: <20000604190526.A6923@marc.merlins.org>

make install fails with:
---
Compiling /var/local/mailman/Mailman/versions.py ...
Traceback (innermost last):
  File "bin/update", line 30, in ?
    from Mailman import MailList
  File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.ListAdmin import ListAdmin
  File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
    from Mailman.Handlers import HandlerAPI
  File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
    from Mailman.Logging.Syslog import syslog
ImportError: No module named Syslog
---

I was running last week's CVS before that and it worked reasonably well.

I upgraded my python (to 1.5.2-10), just in case, but that didn't help

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From marc_news@valinux.com  Mon Jun  5 05:34:41 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 4 Jun 2000 21:34:41 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
Message-ID: <20000604190526.A6923@marc.merlins.org>

make install fails with:
---
Compiling /var/local/mailman/Mailman/versions.py ...
Traceback (innermost last):
  File "bin/update", line 30, in ?
    from Mailman import MailList
  File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.ListAdmin import ListAdmin
  File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
    from Mailman.Handlers import HandlerAPI
  File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
    from Mailman.Logging.Syslog import syslog
ImportError: No module named Syslog
---

I was running last week's CVS before that and it worked reasonably well.

I upgraded my python (to 1.5.2-10), just in case, but that didn't help

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From fil@orwell.bok.net  Mon Jun  5 11:29:52 2000
From: fil@orwell.bok.net (Fil)
Date: Mon, 5 Jun 2000 12:29:52 +0200
Subject: [Mailman-Developers] mailman cvs fails precompile
In-Reply-To: <20000604190526.A6923@marc.merlins.org>; from marc_news@valinux.com on Sun, Jun 04, 2000 at 07:07:27PM -0700
References: <20000604190526.A6923@marc.merlins.org>
Message-ID: <20000605122952.H2349@orwell.bok.net>

Did you 'configure' anew? I had the same problem until I thought of redoing
'configure' and all went smoothly afterwards...


* Marc MERLIN (marc_news@valinux.com) écrivait :
> make install fails with:
> ---
> Compiling /var/local/mailman/Mailman/versions.py ...
> Traceback (innermost last):
>   File "bin/update", line 30, in ?
>     from Mailman import MailList
>   File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
>     from Mailman.ListAdmin import ListAdmin
>   File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
>     from Mailman.Handlers import HandlerAPI
>   File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
>     from Mailman.Logging.Syslog import syslog
> ImportError: No module named Syslog
> ---


From mentor@alb-net.com  Mon Jun  5 14:56:21 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Mon, 5 Jun 2000 09:56:21 -0400 (EDT)
Subject: [Mailman-Developers] rejected notice not sent out (latest CVS)
Message-ID: <Pine.GSO.4.21.0006050954530.24203-100000@alb-net.com>

In a case of rejecting a message, the rejected notice is not sent out with
the latest CVS. This happens independently if the messages it changed or
not.

later,
mentor



From bwarsaw@python.org  Mon Jun  5 15:46:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 10:46:59 -0400 (EDT)
Subject: [Mailman-Developers] mailman cvs fails precompile
References: <20000604190526.A6923@marc.merlins.org>
 <20000605122952.H2349@orwell.bok.net>
Message-ID: <14651.48483.398908.760108@anthem.python.org>

>>>>> "F" == Fil  <fil@orwell.bok.net> writes:

    F> Did you 'configure' anew? I had the same problem until I
    F> thought of redoing 'configure' and all went smoothly
    F> afterwards...

Right, because the Makefile changed you must run config.status or
configure again.

-Barry


From bwarsaw@python.org  Mon Jun  5 15:53:17 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 10:53:17 -0400 (EDT)
Subject: [Mailman-Developers] failure upgrading to current CVS
References: <p04310109b55fadaf2bcd@[209.239.169.197]>
Message-ID: <14651.48861.463804.818286@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> I tried to move to the current CVS tonight, and ran into a
    CVR> glitch.

Patch appended.

    CVR> Looks like b2 left something around that caused the ugprade
    CVR> to lurch.  It might make sense ot have some kind of cron job
    CVR> that deletes locks older than N days, just to be safe?

I don't think so.  The old locks shouldn't do more than take up a
little disk space, and you can just rm them easily enough.

-Barry

Index: LockFile.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/LockFile.py,v
retrieving revision 1.18
retrieving revision 1.19
diff -c -r1.18 -r1.19
*** LockFile.py	2000/06/01 22:08:10	1.18
--- LockFile.py	2000/06/05 14:49:39	1.19
***************
*** 404,411 ****
          # unlink their temp file -- this doesn't wreck the locking algorithm,
          # but will leave temp file turds laying around, a minor inconvenience.
          winner = self.__read()
!         if winner:
!             os.unlink(winner)
          # Now remove the global lockfile, which actually breaks the lock.
          try:
              os.unlink(self.__lockfile)
--- 404,414 ----
          # unlink their temp file -- this doesn't wreck the locking algorithm,
          # but will leave temp file turds laying around, a minor inconvenience.
          winner = self.__read()
!         try:
!             if winner:
!                 os.unlink(winner)
!         except OSError, e:
!             if e.errno <> errno.ENOENT: raise
          # Now remove the global lockfile, which actually breaks the lock.
          try:
              os.unlink(self.__lockfile)


From marc_news@valinux.com  Mon Jun  5 17:13:22 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 5 Jun 2000 09:13:22 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
In-Reply-To: <14651.48483.398908.760108@anthem.python.org>; from bwarsaw@python.org on lun, jun 05, 2000 at 10:46:59 -0400
References: <20000604190526.A6923@marc.merlins.org> <20000605122952.H2349@orwell.bok.net> <14651.48483.398908.760108@anthem.python.org>
Message-ID: <20000605091322.A6070@marc.merlins.org>

On lun, jun 05, 2000 at 10:46:59 -0400, Barry A. Warsaw wrote:
> 
> >>>>> "F" == Fil  <fil@orwell.bok.net> writes:
> 
>     F> Did you 'configure' anew? I had the same problem until I
>     F> thought of redoing 'configure' and all went smoothly
>     F> afterwards...
> 
> Right, because the Makefile changed you must run config.status or
> configure again.

Duh!

Works much better now, thank you :-)

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From bwarsaw@python.org  Mon Jun  5 17:36:37 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 12:36:37 -0400 (EDT)
Subject: [Mailman-Developers] rejected notice not sent out (latest CVS)
References: <Pine.GSO.4.21.0006050954530.24203-100000@alb-net.com>
Message-ID: <14651.55061.111860.255989@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> In a case of rejecting a message, the rejected notice is not
    MC> sent out with the latest CVS. This happens independently if
    MC> the messages it changed or not.

Do you have dont_respond_to_post_requests turned on?  Try this patch.
I don't believe that Mailman should be conditionalizing on this
variable for reject notices (it is, and should be in Hold.py for the
actual hold message).

-Barry


Index: ListAdmin.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/ListAdmin.py,v
retrieving revision 1.37
diff -c -r1.37 ListAdmin.py
*** ListAdmin.py	2000/06/02 23:07:33	1.37
--- ListAdmin.py	2000/06/05 16:35:21
***************
*** 188,196 ****
          elif value == 1:
              # Rejected
              rejection = 'Refused'
!             if not self.dont_respond_to_post_requests:
!                 self.__refuse('Posting of your message titled "%s"' % subject,
!                               sender, comment or '[No reason given]')
          else:
              assert value == 2
              # Discarded
--- 188,195 ----
          elif value == 1:
              # Rejected
              rejection = 'Refused'
!             self.__refuse('Posting of your message titled "%s"' % subject,
!                           sender, comment or '[No reason given]')
          else:
              assert value == 2
              # Discarded


From thomas@xs4all.net  Mon Jun  5 17:55:56 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 18:55:56 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
Message-ID: <20000605185556.Y469@xs4all.nl>

I'm [almost] ready to post a couple of new patches, a minor fix and a medium
new feature, and perhaps maybe a minor new feature, but I'm wondering what
the Right Method is, now that Mailman has moved to Sourceforge. Should I
post the patches here, or to the patch-manager at sourceforge, or both ? :)

I used the patch-manager for the previous patches, but mostly because I'd
posted them here before, and wanted to remind people they were around. But
what's the easiest way for the developers, to accept patches ? I'm not
familiar with the admin-side of the patch manager at all, so I dont know if
it's easy to use.

As for the patches, the small one fixes the admin Membership Management
screen so that when subscribing new users, Mailman doesn't complain about
empty lines. In fact, it's so small, I've attached it :)

The medium new feature is held-unsubscribe-requests, and I'm going to test
it a bit more before I post it. It also touches quite a lot of files.

And another thing I thought up earlier today, while rejecting a few messages
on one of our lists: It would be nice to have a 'redirect' in the admindb
interface, to bounce a mail to someone else. 'redirect' as in 'MUA-bounce',
not 'Eudora-Redirect-and-mess-with-the-headers' or 'mailer-daemon-bounce'.
Currently, you have to either approve or reject the message, which can be a
bit harsh in some cases. I'll write up a patch for that later today, I hope
;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Mon Jun  5 17:57:14 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 18:57:14 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
In-Reply-To: <20000605185556.Y469@xs4all.nl>; from thomas@xs4all.net on Mon, Jun 05, 2000 at 06:55:56PM +0200
References: <20000605185556.Y469@xs4all.nl>
Message-ID: <20000605185714.A469@xs4all.nl>

--dc+cDN39EJAMEtIO
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 05, 2000 at 06:55:56PM +0200, Thomas Wouters wrote:

> As for the patches, the small one fixes the admin Membership Management
> screen so that when subscribing new users, Mailman doesn't complain about
> empty lines. In fact, it's so small, I've attached it :)

Err, no I did not. Now I did :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

--dc+cDN39EJAMEtIO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fix.diff"

diff -urN --exclude=CVS --exclude=Makefile mailman-cvs/Mailman/Cgi/admin.py mailman-new-cvs/Mailman/Cgi/admin.py
--- mailman-cvs/Mailman/Cgi/admin.py	Sat Jun  3 00:25:52 2000
+++ mailman-new-cvs/Mailman/Cgi/admin.py	Mon Jun  5 10:02:00 2000
@@ -857,7 +861,7 @@
     if cgi_info.has_key('subscribees'):
 	name_text = cgi_info['subscribees'].value
         name_text = string.replace(name_text, '\r', '')
-	names = map(string.strip, string.split(name_text, '\n'))
+	names = filter(None, map(string.strip, string.split(name_text, '\n')))
         send_welcome_msg = string.atoi(
             cgi_info["send_welcome_msg_to_this_batch"].value)
         digest = 0

--dc+cDN39EJAMEtIO--


From bwarsaw@python.org  Mon Jun  5 18:50:26 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 13:50:26 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
Message-ID: <14651.59490.620176.355049@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> I'm [almost] ready to post a couple of new patches, a minor
    TW> fix and a medium new feature, and perhaps maybe a minor new
    TW> feature, but I'm wondering what the Right Method is, now that
    TW> Mailman has moved to Sourceforge. Should I post the patches
    TW> here, or to the patch-manager at sourceforge, or both ? :)

I think in general, post the patches to SF and send an explanation and
pointer to this list.  I think using the SF database will help ensure
stuff doesn't just get buried in my inbox. ;/

The patch manager is a bit bogus though, because I marked both your
patches as Accepted, and now they are gone!  I can't find them in
either the Open, Postponed, or Closed patch categories.  They seem to
have just disappeared.

I've submitted a SF request on the matter.

-Barry


From bwarsaw@python.org  Mon Jun  5 18:52:24 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 13:52:24 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
 <20000605185714.A469@xs4all.nl>
Message-ID: <14651.59608.210274.540216@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    >> As for the patches, the small one fixes the admin Membership
    >> Management screen so that when subscribing new users, Mailman
    >> doesn't complain about empty lines. In fact, it's so small,
    >> I've attached it :)

    TW> Err, no I did not. Now I did :)

Applied.  Thanks.

-Barry


From bwarsaw@python.org  Mon Jun  5 19:00:01 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 14:00:01 -0400 (EDT)
Subject: [Mailman-Developers] forwarded message from tnorth
Message-ID: <14651.60065.205981.887416@anthem.python.org>

Interesting, eh?
-Barry

- ---------- Forwarded message ----------
Date: Sat, 3 Jun 2000 21:18:29 +0200
From: Wichert Akkerman <wichert@cistron.nl>
Reply-To: security@debian.org
To: debian-security-announce@lists.debian.org
Subject: [SECURITY] Majordomo will be removed
Resent-Date: Sat,  3 Jun 2000 15:22:52 -0400 (EDT)
Resent-From: debian-security-announce@lists.debian.org

- -----BEGIN PGP SIGNED MESSAGE-----

- - ------------------------------------------------------------------------
Debian Security Advisory                             security@debian.org
http://www.debian.org/security/                         Wichert Akkerman
June  3, 2000
- - ------------------------------------------------------------------------


Package        : majordomo
Problem type   : local exploit
Debian-specific: no

The majordomo package as shipped in the non-free section accompanying
Debian GNU/Linux 2.1/slink allows any local user to trick majordomo into
executing arbitrary code or to create or write files as the majordomo user
anywhere on the filesystem.

This is a documented issue and the advised work around it to either have
no untrusted users on a system running majordomo or to use a setuid
wrapper that the MTA delivery agent can run. 
suboptimal solution.

We feel that those options are not a good solution, but unfortunately the
majordomo license does not allow us to fix these problems and distribute a
fixed version. As a result we have decided to remove majordomo from our
archives.

If you are using majordomo we recommend that you replace it with one
of the many other mailing-list tools available such as fml, mailman
or smartlist.

- - -- 
- - ----------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable updates
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates
Mailing list: debian-security-announce@lists.debian.org

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBOTlZ/6jZR/ntlUftAQFQ6QL/XyB4EprpjY4D2eusMd9PR+UKKh0jI7Zi
IMWf0Avik9wN6HWba64kODvePxKChnh7z2jvG3hz8CIZr6siYsTuFWtu2UkVhdZj
THnYqB87Sqp7XIdO46R7qjnLU0KibPqQ
=w/uo
- -----END PGP SIGNATURE-----


- --  
To UNSUBSCRIBE, email to debian-security-announce-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------- end -------


From thomas@xs4all.net  Mon Jun  5 19:50:43 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 20:50:43 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
In-Reply-To: <14651.59490.620176.355049@anthem.python.org>; from bwarsaw@python.org on Mon, Jun 05, 2000 at 01:50:26PM -0400
References: <20000605185556.Y469@xs4all.nl> <14651.59490.620176.355049@anthem.python.org>
Message-ID: <20000605205043.B469@xs4all.nl>

On Mon, Jun 05, 2000 at 01:50:26PM -0400, Barry A. Warsaw wrote:

> The patch manager is a bit bogus though, because I marked both your
> patches as Accepted, and now they are gone!  I can't find them in
> either the Open, Postponed, or Closed patch categories.  They seem to
> have just disappeared.

I noticed the same thing.

> I've submitted a SF request on the matter.

Lets hope their bug machine doesn't exhibit the same problem :-)

Thanx for applying the blank line subscribe fix.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From bwarsaw@python.org  Mon Jun  5 20:39:52 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 15:39:52 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
 <14651.59490.620176.355049@anthem.python.org>
 <20000605205043.B469@xs4all.nl>
Message-ID: <14652.520.650981.562964@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> I noticed the same thing.

Looks like rejected patches just get zapped.  I have no idea (and the
SF admins didn't tell me) what happens to accepted patches.

    TW> Thanx for applying the blank line subscribe fix.

No prob.


From thomas@xs4all.net  Mon Jun  5 23:50:51 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 6 Jun 2000 00:50:51 +0200
Subject: [Mailman-Developers] unsubscription-approval
Message-ID: <20000606005050.D469@xs4all.nl>

I've just uploaded a patch to Sourceforge which adds
unsubscription-request-approval. This mirrors subscription-approval in that
unsubscribe requests get held for admin approval. This is configurable per
list, of course, just like subscribe-approval, and also has to be explicitly
enabled by the site-admin -- the default is to disallow the setting.

Some small notes:

- If a site-admin changes the default from allow to disallow, lists
which have it set need to be manually reset. This may be seen as a bug, but
it allows some lists to have it defined without allowing other list admins
to turn on the feature. I dont rely on it, though, so if someone gets
inspiration to fix it, please do ;)

- I didn't update the DATA_FILE_VERSION.

- I didn't test this particular patch overly well, since it's kind of tricky
to get a decent diff without 'cvs diff', and I couldn't use 'cvs diff'
because the patch adds a file. ('cvs diff' doesn't 'create' files, and patch
with POSUXLY_CORRECT defined (which is necessary to apply cvs-diffs) will
not create new files regardless.) I *might* have forgotten a part of the
patch, but I went over it a few times, so I dont think so.

- I had to use some trickstery to only optionally add the
unsubscription-approval feature to the list-options dictionary. This works
just fine, but I'm not sure if it's the optimal solution.

The patch should be easy to find, as it's the only patch, currently ;)

Oh, I also have two other small patches lying around, but I'm not sure if
they're suitable for inclusion. One is a 'posters-file' config setting,
which is a string containing the full path to a file with email addresses,
which gets appended to the posters list. It's very useful to us, because we
have a lot of employees with a *lot* of aliases, and they post from every
one ;) but it's not particularly secure, currently.

The other patch is a very rudementary Archive access restriction: We send a
lot of private information over the lists, and it wouldn't do for someone
from, say, a competing company to guess an employee's mailman password and
thus gain access to the list archives. However, I do want to use mailman
password checking for the archives, so I can't use a 'public' archive with a
normal .htaccess restriction.

So I've added a list of strings (containing (parts of) ipaddresses or
networks) which are matched against the REMOTE_ADDR environment, which
should contain the ipaddress of the requester. To do that, I've also added a
StringList field type, which is like the EmailList field type, stripping and
filtering the list of strings, but without the Email validation check.

Let me know if anyone wants to see those patches.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From chuqui@plaidworks.com  Tue Jun  6 00:03:03 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Mon, 5 Jun 2000 16:03:03 -0700
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
References: <20000606005050.D469@xs4all.nl>
Message-ID: <p04310109b561e1abc513@[17.216.27.193]>

At 12:50 AM +0200 6/6/2000, Thomas Wouters wrote:

>Oh, I also have two other small patches lying around, but I'm not sure if
>they're suitable for inclusion. One is a 'posters-file' config setting,
>which is a string containing the full path to a file with email addresses,
>which gets appended to the posters list. It's very useful to us,

This is a very useful thing in any number of situations. I use it on 
my lists a lot. It's quite nice if you have automatically generated 
email or gateways feeding content, where you don't really want to 
subscribe something and turn on nomail. And it' prevents some joker 
from playing with those nomailed subscriptions beyhind your back...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bigdog@dogpound.vnet.net  Tue Jun  6 00:06:22 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Mon, 5 Jun 2000 19:06:22 -0400 (EDT)
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
Message-ID: <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>

On Tue, 6 Jun 2000, Thomas Wouters wrote:

> Oh, I also have two other small patches lying around, but I'm not sure if
> they're suitable for inclusion. One is a 'posters-file' config setting,
> which is a string containing the full path to a file with email addresses,
> which gets appended to the posters list. It's very useful to us, because we
> have a lot of employees with a *lot* of aliases, and they post from every
> one ;) but it's not particularly secure, currently.

How is this edited?  Manually with 'pico' or whatever?  or via the web?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Why do they tell us to watch "The Today Show" tomorrow?
----------------------------------------------------------------
Monday, June 05, 2000 / 07:05PM



From thomas@xs4all.net  Tue Jun  6 00:16:58 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 6 Jun 2000 01:16:58 +0200
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>; from bigdog@dogpound.vnet.net on Mon, Jun 05, 2000 at 07:06:22PM -0400
References: <20000606005050.D469@xs4all.nl> <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>
Message-ID: <20000606011658.E469@xs4all.nl>

On Mon, Jun 05, 2000 at 07:06:22PM -0400, Matt Davis wrote:
> On Tue, 6 Jun 2000, Thomas Wouters wrote:

> > Oh, I also have two other small patches lying around, but I'm not sure if
> > they're suitable for inclusion. One is a 'posters-file' config setting,
> > which is a string containing the full path to a file with email addresses,
> > which gets appended to the posters list. It's very useful to us, because we
> > have a lot of employees with a *lot* of aliases, and they post from every
> > one ;) but it's not particularly secure, currently.

> How is this edited?  Manually with 'pico' or whatever?  or via the web?

It's currently manually edited, through joe or vi usually, but most of it is
probably going to be automatically generated from our database soonish.
(hopefully, anyway :P) The patch to Mailman only handles configuring the
filename, and opening the file and appending the list of addresses to the
poster_list at the appropriate moment, not the actual editing.

This is very much a hack. A much better solution would be for lists to be
'slaved' to another, so that anyone on the master list can post to the slave
list, and subscribe to the slave list without approval, etc. Then you'd only
have to update the master lists' poster_list, and it'd also fix some of my
other problems ;) (but those are probably very rare, anyway.) The alias
problem would also go away if we had a true user database, of course, and a
means of accessing and altering it from other programs ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From troy@akropolys.com  Tue Jun  6 02:55:41 2000
From: troy@akropolys.com (Troy Morrison)
Date: Mon, 5 Jun 2000 18:55:41 -0700 (PDT)
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
Message-ID: <Pine.LNX.4.21.0006051840270.9575-100000@exeter.akropolys.com>

| The other patch is a very rudementary Archive access restriction: We send a
| lot of private information over the lists, and it wouldn't do for someone
| from, say, a competing company to guess an employee's mailman password and
| thus gain access to the list archives. However, I do want to use mailman
| password checking for the archives, so I can't use a 'public' archive with a
| normal .htaccess restriction.

I could be completely missing the point of this, but I run a small list,
mostly for friends and such, where the subscribers wanted archives, but
didn't want 'public' archives.  I wanted MIME/attachment support.  I
started out using pipermail/Mailman's archives, but didn't like them (and
this was back when they were CPU intensive too), so I switch to an
external archiver.

I'm using qmail, so I created an "archives" user, and gave him a
".qmail-default" file like:

|preline /usr/local/bin/hypermail [ ... ]
|preline cat >> ./$DEFAULT-`date +"%m-%Y" && exit 0

And then I subscribe "archives-<listname>" to each list.

Anyway, the point that's specifically relevant to what Thomas said was
that I wanted these decidedly non-Mailman archives to be accessible to
subscribers only via their list password.  So I hacked up this (probably
very ugly -- I didn't know Python and really still don't) script to
generate my .htaccess files in a cron job:

---------8< snip 8<------------
#!/usr/bin/env python

import sys, whrandom, crypt

sys.path.insert(0, '/home/mailman');
from Mailman import MailList, Utils;

passwdfile=open('/home/archives/public_html/list1/.htpasswd', 'w')
list1=MailList.MailList('list1', lock=0)
generator = whrandom.whrandom()

for x in list1.passwords.keys():
	pw = list1.passwords[x]
	passwdcrypt = crypt.crypt(pw, "L1")
	passwdfile.write(x + ":" + passwdcrypt + "\n")

passwdfile.close()

# <repeat for each list>

---------8< snip 8<------------

There is a delay between when someone subscribes or changes their password
and the corresponding update to the archives password file, which is
probably not the best thing, but I've just made sure that everyone is
aware of the delay.

So, anyway, I just thought that the idea might be useful to others using
Mailman...

Troy



From brett@iclick.com  Tue Jun  6 05:26:51 2000
From: brett@iclick.com (Brett Dikeman)
Date: Tue, 6 Jun 2000 00:26:51 -0400
Subject: [Mailman-Developers] num_spawns not used in v2.0?
Message-ID: <p04320404b56228a3e448@[192.168.111.3]>

As the little old lady says, "where's the beef?"

In 1.1, Deliverer.py used num_spawns, but v2.0 doesn't use it 
anywhere.  So, the end result is that my system isn't doing any 
splitting.  This is causing mail delivery problems(specifically, it's 
taking 30 minutes when it used to take 2-3 when I was running 1.1)

This was based on a quick look/search by a friend and I; we know next 
to nothing about Python, so I may not have things exactly right, but 
we know when we can't find a variable in use anywhere and we're 
pretty sure on that part :-)

What's the scoop?  When will this feature be re-enabled?

Thx,
Brett
-- 
----
Brett Dikeman				Systems Engineer
iClick, Inc					914-872-8043
120 Bloomingdale Rd.			914-872-8100(fax)
White Plains, NY 10605			http://www.iclick.com


From marc_news@valinux.com  Tue Jun  6 06:51:36 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 5 Jun 2000 22:51:36 -0700
Subject: [Mailman-Developers] Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue
Message-ID: <20000605225136.C7529@marc.merlins.org>

I just upgraded to 2000/06/05's CVS and I'm getting those now:

5 of these:
----- Forwarded message from Cron Daemon <root@marc.merlins.org> -----

Subject: Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue

Traceback (innermost last):
  File "/var/local/mailman/cron/run_queue", line 46, in ?
    main()
  File "/var/local/mailman/cron/run_queue", line 43, in main
    lockfile.unlock()
  File "/var/local/mailman/Mailman/LockFile.py", line 302, in unlock
    raise NotLockedError
Mailman.LockFile.NotLockedError

----- End forwarded message -----

1 of those:
----- Forwarded message from Cron Daemon <root@marc.merlins.org> -----

Subject: Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue

Traceback (innermost last):
  File "/var/local/mailman/cron/run_queue", line 46, in ?
    main()
  File "/var/local/mailman/cron/run_queue", line 39, in main
    lockfile.lock()
  File "/var/local/mailman/Mailman/LockFile.py", line 284, in lock
    self.__break()
  File "/var/local/mailman/Mailman/LockFile.py", line 408, in __break
    if winner:
OSError: [Errno 2] No such file or directory: '/var/local/mailman/locks/mmqueue_run.lock.marc.merlins.org.29127'

----- End forwarded message -----

-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From gpoo@ubiobio.cl  Tue Jun  6 16:29:52 2000
From: gpoo@ubiobio.cl (German Poo Caaman~o)
Date: Tue, 6 Jun 2000 12:29:52 -0300 (ADT)
Subject: [Mailman-Developers] Multilingual support
Message-ID: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>

I've downloaded Mailman-2.0b2 and I'v translated the templates files
to spanish, but it wasn't enough.  Some web pages appears with
english and spanish words.

Are there some language support on mind?   May be, a language file
where reside all words used on the interface (buttons, messages,
etc.).

--
German Poo Caaman~o
mailto:gpoo@ubiobio.cl
http://www.ubiobio.cl/~gpoo/chilelindo.html




From andrea@integra-italia.com  Wed Jun  7 15:21:06 2000
From: andrea@integra-italia.com (Andrea Paparelli)
Date: Wed, 7 Jun 2000 16:21:06 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
Message-ID: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>

Bug in Mailman version 1.1

We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of
this page to the webmaster for this site with a description of what
happened. Thanks!

Traceback:


Traceback (innermost last):
  File "/home/staff/mailman/scripts/driver", line 112, in run_main
    main()
  File "/home/staff/mailman/Mailman/Cgi/admin.py", line 103, in main
    is_auth = lst.WebAuthenticate(password=adminpw,
  File "/home/staff/mailman/Mailman/SecurityManager.py", line 83, in
WebAuthenticate
    return self.CheckCookie(cookie_key)
  File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
CheckCookie
    if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
IndexError: string index out of range





----------------------------------------------------------------------------
----

Environment variables:
Variable Value
DOCUMENT_ROOT  /home/httpd/docs
HTTP_ACCEPT_ENCODING  gzip, deflate
SERVER_PORT  80
PATH_TRANSLATED  /home/httpd/docs/dbsee
HTTP_ACCEPT_LANGUAGE  it
GATEWAY_INTERFACE  CGI/1.1
SERVER_NAME  mailman.starlink.it
HTTP_CONNECTION  Keep-Alive
HTTP_USER_AGENT  Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
HTTP_ACCEPT  */*
REQUEST_URI  /mailman/admin.cgi/dbsee
PATH  /sbin:/usr/sbin:/bin:/usr/bin
QUERY_STRING
SCRIPT_FILENAME  /home/staff/mailman/cgi-bin/admin.cgi
PATH_INFO  /dbsee
HTTP_HOST  mailman.starlink.it
REQUEST_METHOD  GET
SERVER_SIGNATURE
SCRIPT_NAME  /mailman/admin.cgi
SERVER_ADMIN  root@localhost
SERVER_SOFTWARE  Apache/1.3.3 (Unix) (Red Hat/Linux)
PYTHONPATH  /home/staff/mailman
HTTP_COOKIE  PUPALANGID=1
SERVER_PROTOCOL  HTTP/1.1
REMOTE_PORT  2868



From mentor@alb-net.com  Wed Jun  7 17:45:12 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 7 Jun 2000 12:45:12 -0400 (EDT)
Subject: [Mailman-Developers] multifile.Error :  sudden EOF in MultiFile.readline()
Message-ID: <Pine.GSO.4.21.0006071244180.25061-100000@alb-net.com>

FYI...

Jun 07 11:52:27 2000 post(22115): Traceback (innermost last):
post(22115):   File "/opt/home/mailman/scripts/mailowner", line 89, in ?
post(22115):      main()
post(22115):   File "/opt/home/mailman/scripts/mailowner", line 68, in main
post(22115):      if BouncerAPI.ScanMessages(mlist, msg):
post(22115):   File "/opt/home/mailman/Mailman/Bouncers/BouncerAPI.py",line 50$
post(22115):      addrs = func(msg)
post(22115):   File "/opt/home/mailman/Mailman/Bouncers/Postfix.py", line46, i$
post(22115):      s = StringIO(mfile.read())
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 118, inread
post(22115):      return string.joinfields(self.readlines(), '')
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 112, inreadl$
post(22115):      line = self.readline()
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 77, inreadli$
post(22115):      raise Error, 'sudden EOF in MultiFile.readline()'
post(22115): multifile.Error :  sudden EOF in MultiFile.readline()



From mentor@alb-net.com  Wed Jun  7 17:54:53 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 7 Jun 2000 12:54:53 -0400 (EDT)
Subject: [Mailman-Developers] again..... duplicated messages to 7356!!!! (fwd)
Message-ID: <Pine.GSO.4.21.0006071253410.25061-200000@alb-net.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-959030623-960272479=:25061
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.GSO.4.21.0006071253451.25061@alb-net.com>


I think it happened again.....

A messages sent to a list of 2000+ subscribers got distributed twice...

later,
mentor

---------- Forwarded message ----------
Date: Tue, 6 Jun 2000 02:21:19 -0400 (EDT)
From: Mentor Cana <mentor@alb-net.com>
To: "Barry A. Warsaw" <bwarsaw@python.org>
Subject: duplicated messages to 7356!!!!
Message-ID: <Pine.GSO.4.21.0006060213030.25061-200000@alb-net.com>
Organization: "http://www.alb-net.com/"
X-Loop: MENTOR
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
    BOUNDARY="-559023410-959030623-960272479=:25061"

Barry,

Tonight, using the latest CVS (6/5 afternoon), thinking that everything is
fine, I e-mailed a message to one of my lists with 7400+ users.

After some time I saw the following in my logs/smtp
---
Jun 06 00:57:18 2000 (21787) smtp for 7356 recips, completed in 387.864 seconds
Jun 06 01:01:09 2000 (22111) smtp for 1 recips, completed in 46.683 seconds
Jun 06 01:09:46 2000 (20628) smtp for 7356 recips, completed in 2249.145 seconds
---

Obviously, the message was supposed to be delivered only once. Instead, it
went out twice. When I saw this, I cleaned all the files related to
kcc-news list in the qfile/ dir. This stopped from sending any further
messages. Maybe even without my deletion of the /qfile would not have sent
any additional messages. Just to be on the safe side. 

Anyways, attached is the related portion of the logs/error file to help you
troubshoot the issue. You wold agree, this should not be happening...

the cron/qrunner was set to run every minute.....

The error file says that the kcc-news list file was corrupted, however, it
seems to be just fine.

Let me know if you need further info to troubshoot the problem. 

later,
mentor
P.S. time to get some sleep...


---559023410-959030623-960272479=:25061
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=error-1
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.21.0006060221190.25061@alb-net.com>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME=error-1

SnVuIDA2IDAwOjAyOjAyIDIwMDAgcXJ1bm5lcigyMDA4Myk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjIwOjAzIDIwMDAg
cXJ1bm5lcigyMDY1MCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjIxOjAyIDIwMDAgcXJ1bm5lcigyMDY4MCk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjIyOjAxIDIw
MDAgcXJ1bm5lcigyMDcxNSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjIzOjAzIDIwMDAgcXJ1bm5lcigyMDc0MCk6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI0OjAx
IDIwMDAgcXJ1bm5lcigyMDc3Mik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjI1OjAyIDIwMDAgcXJ1bm5lcigyMDc5Mik6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI2
OjAyIDIwMDAgcXJ1bm5lcigyMDgxMSk6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI3OjAyIDIwMDAgcXJ1bm5lcigyMDg0
MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAw
OjI4OjAxIDIwMDAgcXJ1bm5lcigyMDg3Mik6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI5OjAxIDIwMDAgcXJ1bm5lcigy
MDg5OCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAwOjMwOjA1IDIwMDAgcXJ1bm5lcigyMDkzNyk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjMxOjAzIDIwMDAgcXJ1bm5l
cigyMDk4MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAwOjMyOjAxIDIwMDAgcXJ1bm5lcigyMTAwNik6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjMzOjAxIDIwMDAgcXJ1
bm5lcigyMTAxNSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0K
SnVuIDA2IDAwOjM0OjAyIDIwMDAgcXJ1bm5lcigyMTA1OCk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM1OjAzIDIwMDAg
cXJ1bm5lcigyMTE0NCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjM2OjAyIDIwMDAgcXJ1bm5lcigyMTE5OCk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM3OjAyIDIw
MDAgcXJ1bm5lcigyMTIyMyk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjM4OjAyIDIwMDAgcXJ1bm5lcigyMTMzNSk6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM5OjAy
IDIwMDAgcXJ1bm5lcigyMTQwMCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjQwOjAxIDIwMDAgcXJ1bm5lcigyMTQ0Nyk6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQx
OjAyIDIwMDAgcXJ1bm5lcigyMTQ3MCk6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQyOjAyIDIwMDAgcXJ1bm5lcigyMTU2
MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAw
OjQzOjAyIDIwMDAgcXJ1bm5lcigyMTYxNSk6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ0OjAyIDIwMDAgcXJ1bm5lcigy
MTY1Nik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAwOjQ1OjAyIDIwMDAgcXJ1bm5lcigyMTY2MCk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ2OjAyIDIwMDAgcXJ1bm5l
cigyMTY4Nik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAwOjQ3OjAyIDIwMDAgcXJ1bm5lcigyMTcyOCk6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ4OjAzIDIwMDAgcXJ1
bm5lcigyMTc1MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0K
SnVuIDA2IDAwOjQ5OjAyIDIwMDAgcXJ1bm5lcigyMTc1Nyk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjUxOjAyIDIwMDAg
cXJ1bm5lcigyMTg0MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjUyOjAxIDIwMDAgcXJ1bm5lcigyMTkwNyk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjUzOjAzIDIw
MDAgcXJ1bm5lcigyMTk5NSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjU0OjE0IDIwMDAgcXJ1bm5lcigyMjEwMik6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU1OjAz
IDIwMDAgcXJ1bm5lcigyMjE1Myk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjU2OjIwIDIwMDAgcXJ1bm5lcigyMjIwMik6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU4
OjMzIDIwMDAgcXJ1bm5lcigyMjMxMik6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU4OjMzIDIwMDAgcXJ1bm5lcigyMjI0
OSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAx
OjAxOjExIDIwMDAgcG9zdCgyMjM2NCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMjM2NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIy
MzY0KTogICAgICBtYWluKCkNCnBvc3QoMjIzNjQpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyMjM2NCk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIy
MzY0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjIzNjQpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMjM2NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDIyMzY0KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyMjM2NCk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6MDE6MTIgMjAwMCBwb3N0KDIy
MTExKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMTEx
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIxMTEpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjExMSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIyMTExKTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjIxMTEpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyMjExMSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDIyMTExKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjIxMTEpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIy
MTExKTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTowMToyOSAyMDAwICgyMjQ3OCkga2NjLW5ld3MgZGIgZmlsZSB3
YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFu
L2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MDE6
MzAgMjAwMCAoMjI0ODkpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQs
IHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2Mt
bmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjAxOjMxIDIwMDAgKDIy
NDg5KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVw
DQpKdW4gMDYgMDE6MDE6MzIgMjAwMCAoMjI0NzgpIGtjYy1uZXdzIGZhbGxi
YWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTowMTo0NiAy
MDAwIHBvc3QoMjIwMTcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjIwMTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjAxNyk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyMDE3KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjIwMTcpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyMDE3KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjAxOjU1IDIwMDAgcG9zdCgyMjAzNik6IFRyYWNlYmFjayAoaW5uZXJt
b3N0IGxhc3QpOg0KcG9zdCgyMjAzNik6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMDM2KTogICAgICBtYWluKCkNCnBvc3QoMjIwMzYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjAzNik6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIwMzYpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6MDI6MDEgMjAwMCAoMjI1NDYpIGtjYy1uZXdzIGRi
IGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUv
bWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2
IDAxOjAyOjAxIDIwMDAgKDIyNTYwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBj
b3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlz
dHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTowMjowMSAy
MDAwICgyMjU1NCkga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNp
bmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdz
L2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MDI6MDEgMjAwMCAoMjI1NTgp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjAyOjAxIDIwMDAgKDIyNTQ0KSBrY2MtbmV3cyBk
YiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21l
L21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAw
NiAwMTowMjowMiAyMDAwICgyMjU0Nikga2NjLW5ld3MgZmFsbGJhY2sgd2Fz
IGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjAyOjAyIDIwMDAgKDIy
NTYwKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVw
DQpKdW4gMDYgMDE6MDI6MDIgMjAwMCAoMjI1NDQpIGtjYy1uZXdzIGZhbGxi
YWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTowMjowMiAy
MDAwICgyMjU1OCkga2NjLW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdp
dmluZyB1cA0KSnVuIDA2IDAxOjAyOjAzIDIwMDAgKDIyNTU0KSBrY2MtbmV3
cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6
MDI6MDMgMjAwMCBwb3N0KDIyNTQ2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDI6
MDMgMjAwMCBwb3N0KDIyNTQ0KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVy
IGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDI6MTQg
MjAwMCBwb3N0KDIyMDgwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIyMDgwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIwODApOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMjA4MCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIyMDgwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMjA4MCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAw
NiAwMTowMjoxNSAyMDAwIHBvc3QoMjIwNjIpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIwNjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjA2Mik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDYyKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIwNjIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMDYyKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjAyOjE5IDIwMDAgcG9zdCgyMjA3NCk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjA3NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIyMDc0KTogICAgICBtYWluKCkNCnBvc3QoMjIwNzQp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjA3NCk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIwNzQpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDI6MjAgMjAwMCBwb3N0KDIy
MDg3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMDg3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIwODcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjA4Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMDg3KTog
ICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjA4
Nyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowMjo1MyAy
MDAwIHBvc3QoMjIxMTgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjIxMTgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjExOCk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyMTE4KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjIxMTgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyMTE4KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjAzOjAxIDIwMDAgcG9zdCgyMjEyNCk6IFRyYWNlYmFjayAoaW5uZXJt
b3N0IGxhc3QpOg0KcG9zdCgyMjEyNCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMTI0KTogICAgICBtYWluKCkNCnBvc3QoMjIxMjQpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjEyNCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIxMjQpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6MDM6MTIgMjAwMCBwb3N0KDIyNDg5KTogTWFpbG1h
biBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdz
DQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjAzOjMyIDIwMDAgcXJ1bm5l
cigyMjYzMSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAxOjAzOjQ1IDIwMDAgcG9zdCgyMjE2MSk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjE2MSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIyMTYxKTogICAgICBtYWluKCkNCnBvc3QoMjIxNjEpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMjE2MSk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIxNjEpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6MDQ6MDcgMjAwMCBwb3N0KDIyMjU1KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMjU1KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjIyNTUpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjI1
NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIyMjU1KTogICAgICBtbGlz
dC5TYXZlKCkNCnBvc3QoMjIyNTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0K
cG9zdCgyMjI1NSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0
KDIyMjU1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xv
Y2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjIyNTUp
OiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIyMjU1KTogTWFp
bG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTow
NDoxMyAyMDAwIHBvc3QoMjIxNzMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjIxNzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjE3
Myk6ICAgICAgbWFpbigpDQpwb3N0KDIyMTczKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjIxNzMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyMTczKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjA0OjU1IDIwMDAgcG9zdCgyMjIxOCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjIxOCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyMjE4KTogICAgICBtYWluKCkNCnBvc3QoMjIyMTgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjIxOCk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIyMTgpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDU6MDcgMjAwMCBwb3N0KDIyMDk4KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMDk4KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjIwOTgpOiAgICAgIG1haW4oKQ0KcG9zdCgy
MjA5OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMDk4KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjA5OCk6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowNToxNSAyMDAwIHBv
c3QoMjIwMzIpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTowNToxNSAyMDAwIHBvc3QoMjIxODMpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIwMzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjAzMik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDMyKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIwMzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMTgzKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjIxODMpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjE4Myk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYx
LCBpbiBtYWluDQpwb3N0KDIyMTgzKTogICAgICBleGNlcHQgTG9ja0ZpbGUu
VGltZU91dEVycm9yOg0KcG9zdCgyMjAzMik6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCnBvc3QoMjIxODMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MDU6MTcgMjAwMCBwb3N0KDIyMjM3KTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMjM3KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjIyMzcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjIzNyk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyMjM3KTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjIzNyk6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMTowNTozOSAyMDAwIHBvc3QoMjIyNjIpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjIyNjIpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjI2Mik6ICAgICAgbWFpbigpDQpwb3N0KDIy
MjYyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjIyNjIpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMjYyKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjA1OjU2IDIwMDAgcG9z
dCgyMjI4MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjI4MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMjgwKTogICAgICBtYWlu
KCkNCnBvc3QoMjIyODApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjI4
MCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjIyODApOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDU6
NTggMjAwMCBwb3N0KDIyMjc4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyMjc4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIyNzgp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjI3OCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyMjc4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjI3OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowNjowMiAyMDAwICgyMjE5NikgRGVsaXZlcnkgZXhjZXB0aW9u
OiANCkp1biAwNiAwMTowNjowNSAyMDAwICgyMjE5NikgVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERl
bGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQog
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01U
UERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5T
YXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWls
TGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2su
cmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNl
IE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAw
MTowNjowOSAyMDAwIHBvc3QoMjIwMjIpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjIwMjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
MjAyMik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDIyKTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjIwMjIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDIyMDIyKTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjA2OjE0IDIwMDAgcG9zdCgyMjE0MCk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjE0MCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIyMTQwKTogICAgICBtYWluKCkNCnBvc3QoMjIxNDApOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjE0MCk6ICAgICAgZXhjZXB0IExv
Y2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIxNDApOiBOYW1lRXJyb3Ig
OiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNTYw
KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6
IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNTU4KTog
TWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtj
Yy1uZXdzDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNDc4KTogTWFp
bG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1u
ZXdzDQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjA2OjE5IDIwMDAgcG9z
dCgyMjU1NCk6IE1haWxtYW4gZXJyb3I6IG1haWxvd25lciBnb3QgYmFkIGxp
c3RuYW1lOiBrY2MtbmV3cw0KYmFkIG1hcnNoYWwgZGF0YUp1biAwNiAwMTow
NjoyMCAyMDAwIHBvc3QoMjIxMzIpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjIxMzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjEz
Mik6ICAgICAgbWFpbigpDQpwb3N0KDIyMTMyKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjIxMzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyMTMyKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjA2OjIxIDIwMDAgcG9zdCgyMjIyNik6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjIyNik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyMjI2KTogICAgICBtYWluKCkNCnBvc3QoMjIyMjYpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjIyNik6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIyMjYpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDY6MzMgMjAwMCBwb3N0KDIyMzA2KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMzA2KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjIzMDYpOiAgICAgIG1haW4oKQ0KcG9zdCgy
MjMwNik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMzA2KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjMwNik6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowNjo0NSAyMDAwIHBv
c3QoMjIzMDEpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTowNjo0NSAyMDAwIHBvc3QoMjIzMTgpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIzMDEpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjMwMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyMzAxKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIzMDEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMzAxKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KcG9zdCgyMjMxOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMzE4
KTogICAgICBtYWluKCkNCnBvc3QoMjIzMTgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjMxOCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjIzMTgpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MDY6NTYgMjAwMCBwb3N0KDIyMzE2KTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMzE2KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjIzMTYpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjMxNik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyMzE2KTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjMxNik6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMTowNjo1NyAyMDAwIHBvc3QoMjIyOTMpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjIyOTMpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjI5Myk6ICAgICAgbWFpbigpDQpwb3N0KDIy
MjkzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjIyOTMpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMjkzKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjA3OjI5IDIwMDAgcG9z
dCgyMjMzMyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjMzMyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMzMzKTogICAgICBtYWlu
KCkNCnBvc3QoMjIzMzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjMz
Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjIzMzMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDc6
NDMgMjAwMCBwb3N0KDIyMzgxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyMzgxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIzODEp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjM4MSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyMzgxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjM4MSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowNzo0NSAyMDAwIHBvc3QoMjIzNzgpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjIzNzgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyMjM3OCk6ICAgICAgbWFpbigpDQpwb3N0KDIyMzc4KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjIzNzgpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMzc4KTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjA3OjQ2IDIwMDAgcG9zdCgyMjM2Mik6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjM2Mik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDIyMzYyKTogICAgICBtYWluKCkNCnBvc3QoMjIz
NjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjM2Mik6ICAgICAgZXhj
ZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIzNjIpOiBOYW1l
RXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDc6NTYgMjAwMCBwb3N0
KDIyMzg5KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYg
MDE6MDc6NTYgMjAwMCBwb3N0KDIyMzg3KTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIyMzg3KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjIzODcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjM4Nyk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDIyMzg3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KcG9zdCgyMjM4OSk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMzg5KTogICAgICBtYWluKCkNCnBvc3QoMjIzODkpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjM4OSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIzODcpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpwb3N0KDIyMzg5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjA4OjIyIDIwMDAgcG9zdCgyMjM1Myk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjM1Myk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIyMzUzKTogICAgICBtYWluKCkNCnBvc3QoMjIzNTMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMjM1Myk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIzNTMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6MDg6MjUgMjAwMCBxcnVubmVyKDIyMzcxKTog
Q291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MDg6
MjggMjAwMCBwb3N0KDIyNDExKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyNDExKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI0MTEp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjQxMSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyNDExKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjQxMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowODo0MSAyMDAwIHFydW5uZXIoMjI0MjMpOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowODo0OSAyMDAwIHFy
dW5uZXIoMjI3MjApOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sN
Ckp1biAwNiAwMTowODo1MSAyMDAwIHFydW5uZXIoMjI1NjYpOiBDb3VsZCBu
b3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowODo1MSAyMDAw
IHFydW5uZXIoMjI2OTIpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxv
Y2sNCkp1biAwNiAwMTowOToxMyAyMDAwIHFydW5uZXIoMjI4MDgpOiBDb3Vs
ZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowOToxNCAy
MDAwIHFydW5uZXIoMjI3NTMpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVy
IGxvY2sNCkp1biAwNiAwMTowOToxNSAyMDAwIHFydW5uZXIoMjI4MjEpOiBD
b3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowOTo0
OCAyMDAwICgyMjE4OCkgRGVsaXZlcnkgZXhjZXB0aW9uOiANCkp1biAwNiAw
MTowOTo1MCAyMDAwICgyMjE4OCkgVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxl
cnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERlbGl2ZXJUb0xpc3QN
CiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQogIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01UUERpcmVjdC5weSIs
IGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5TYXZlKCkNCiAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxp
bmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQog
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHki
LCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNlIE5vdExvY2tlZEVy
cm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAwMToxMDowNCAyMDAw
IHFydW5uZXIoMjI4MzUpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxv
Y2sNCkp1biAwNiAwMToxMToxOSAyMDAwIHBvc3QoMjI2MTEpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI2MTEpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyMjYxMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyNjExKTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI2MTEpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNjExKTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjExOjIwIDIwMDAgcG9zdCgyMjYx
NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjYxNSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjE1KTogICAgICBtYWluKCkNCnBv
c3QoMjI2MTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjYxNSk6ICAg
ICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI2MTUp
OiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTE6MjEgMjAw
MCBwb3N0KDIyNjIxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpw
b3N0KDIyNjIxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI2MjEpOiAgICAg
IG1haW4oKQ0KcG9zdCgyMjYyMSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0
KDIyNjIxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0K
cG9zdCgyMjYyMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAw
MToxMjo0MCAyMDAwIHFydW5uZXIoMjI5MTMpOiBDb3VsZCBub3QgYWNxdWly
ZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMToxMjo0NyAyMDAwIHBvc3QoMjI2
NTMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI2NTMp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjY1Myk6ICAgICAgbWFpbigpDQpw
b3N0KDIyNjUzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI2NTMpOiAg
ICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNjUz
KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjEyOjUwIDIw
MDAgcG9zdCgyMjY0Myk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyMjY0Myk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjQzKTogICAg
ICBtYWluKCkNCnBvc3QoMjI2NDMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyMjY0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjI2NDMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6MTM6MDEgMjAwMCBwb3N0KDIyNzg2KTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIyNzg2KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjI3ODYpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjc4Nik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBp
biBtYWluDQpwb3N0KDIyNzg2KTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3Qo
MjI3ODYpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFp
bExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyMjc4Nik6ICAg
ICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIyNzg2KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGlu
ZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjI3ODYpOiAgICAgIHJhaXNlIE5v
dExvY2tlZEVycm9yDQpwb3N0KDIyNzg2KTogTWFpbG1hbi5Mb2NrRmlsZSAu
IE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMToxNDoxMSAyMDAwIHBvc3Qo
MjI5MzApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI5
MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjkzMCk6ICAgICAgbWFpbigp
DQpwb3N0KDIyOTMwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjI5MzAp
OiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMjkzMCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYw
LCBpbiBTYXZlDQpwb3N0KDIyOTMwKTogICAgICBzZWxmLl9fbG9jay5yZWZy
ZXNoKCkNCnBvc3QoMjI5MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
cG9zdCgyMjkzMCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3Qo
MjI5MzApOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0K
SnVuIDA2IDAxOjE1OjA3IDIwMDAgcG9zdCgyMjczNSk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjczNSk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyNzM1KTogICAgICBtYWluKCkNCnBvc3QoMjI3MzUpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjczNSk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI3MzUpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTU6NTAgMjAwMCBwb3N0KDIyNzc3KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYgMDE6MTU6NTAg
MjAwMCBwb3N0KDIyNzgxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIyNzc3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI3NzcpOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMjc3Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIyNzc3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMjc3Nyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3Qo
MjI3ODEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjc4MSk6ICAgICAgbWFp
bigpDQpwb3N0KDIyNzgxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI3
ODEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0
KDIyNzgxKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjE1
OjU0IDIwMDAgcG9zdCgyMjc3OSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMjc3OSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNzc5
KTogICAgICBtYWluKCkNCnBvc3QoMjI3NzkpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjc3OSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjI3NzkpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MTU6NTcgMjAwMCBwb3N0KDIyNzkxKTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyNzkxKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjI3OTEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjc5MSk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyNzkxKTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjc5MSk6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMToxNTo1NyAyMDAwIHBvc3QoMjI3OTQpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI3OTQpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjc5NCk6ICAgICAgbWFpbigpDQpwb3N0KDIy
Nzk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI3OTQpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNzk0KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjE4OjI0IDIwMDAgKDIz
MjIwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMToxODo1MSAyMDAwIHFydW5uZXIoMjI5NjEp
OiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTox
ODo1OCAyMDAwIHBvc3QoMjI4NjcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjI4NjcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjg2
Nyk6ICAgICAgbWFpbigpDQpwb3N0KDIyODY3KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjI4NjcpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyODY3KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjE4OjU5IDIwMDAgcG9zdCgyMjg3MCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjg3MCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyODcwKTogICAgICBtYWluKCkNCnBvc3QoMjI4NzApOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjg3MCk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI4NzApOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTk6MDcgMjAwMCBwb3N0KDIyODk2KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyODk2KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjI4OTYpOiAgICAgIG1haW4oKQ0KcG9zdCgy
Mjg5Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyODk2KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjg5Nik6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToxOToxNiAyMDAwIHBv
c3QoMjI1OTQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3Qo
MjI1OTQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjU5NCk6ICAgICAgbWFp
bigpDQpwb3N0KDIyNTk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjI1
OTQpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMjU5NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUg
ODYwLCBpbiBTYXZlDQpwb3N0KDIyNTk0KTogICAgICBzZWxmLl9fbG9jay5y
ZWZyZXNoKCkNCnBvc3QoMjI1OTQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVz
aA0KcG9zdCgyMjU5NCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBv
c3QoMjI1OTQpOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3Ig
IA0KSnVuIDA2IDAxOjE5OjIwIDIwMDAgcG9zdCgyMjk2OCk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjk2OCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIyOTY4KTogICAgICBtYWluKCkNCnBvc3QoMjI5NjgpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4MywgaW4gbWFpbg0KcG9zdCgyMjk2OCk6ICAgICAgbWxpc3QuU2F2
ZSgpDQpwb3N0KDIyOTY4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3Qo
MjI5NjgpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMjk2
OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDIyOTY4KTogICAg
ICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyMjk2OCk6IE1haWxtYW4u
TG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6MTk6MzMg
MjAwMCBxcnVubmVyKDIzMjM4KTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5l
ciBsb2NrDQpKdW4gMDYgMDE6MTk6MzMgMjAwMCBxcnVubmVyKDIzMTI3KTog
Q291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MTk6
MzUgMjAwMCBwb3N0KDIyOTIwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyOTIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI5MjAp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjkyMCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyOTIwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjkyMCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMToxOTo0MCAyMDAwIHFydW5uZXIoMjMwNjApOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMToxOTo0NCAyMDAwIHFy
dW5uZXIoMjMwNjkpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sN
Ckp1biAwNiAwMToxOTo0NyAyMDAwICgyMzAyOCkgRGVsaXZlcnkgZXhjZXB0
aW9uOiANCkp1biAwNiAwMToxOTo0NyAyMDAwICgyMzAyOCkgVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGlu
IERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEp
DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMv
U01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlz
dC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9N
YWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xv
Y2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxt
YW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJh
aXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAw
NiAwMToxOTo1NiAyMDAwIHBvc3QoMjI5MTEpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjI5MTEpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjkxMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyOTExKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjI5MTEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyOTExKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjIwOjAwIDIwMDAgcG9zdCgyMjg3NSk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjg3NSk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIyODc1KTogICAgICBtYWluKCkNCnBvc3QoMjI4NzUp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjg3NSk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI4NzUpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjA6MTcgMjAwMCBwb3N0KDIy
OTUwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyOTUw
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI5NTApOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjk1MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyOTUwKTog
ICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjk1
MCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToyMDoxOCAy
MDAwIHBvc3QoMjI5NTMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjI5NTMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjk1Myk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyOTUzKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjI5NTMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyOTUzKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjIwOjMyIDIwMDAgKDIzMDM5KSBEZWxpdmVyeSBleGNlcHRpb246IA0K
SnVuIDA2IDAxOjIwOjMyIDIwMDAgKDIzMDM5KSBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVsaXZl
clRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQRGly
ZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNhdmUo
KQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0
LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5yZWZy
ZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2Nr
RmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2UgTm90
TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVuIDA2IDAxOjIw
OjM0IDIwMDAgcG9zdCgyMjk3MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMjk3MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyOTcx
KTogICAgICBtYWluKCkNCnBvc3QoMjI5NzEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjk3MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjI5NzEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MjA6NDEgMjAwMCBxcnVubmVyKDIyOTk2KTogQ291bGQgbm90
IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MjA6NDYgMjAwMCBx
cnVubmVyKDIzMTU4KTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2Nr
DQpKdW4gMDYgMDE6MjA6NTEgMjAwMCBwb3N0KDIyOTgxKTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyOTgxKTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjI5ODEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjk4MSk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyOTgxKTogICAgICBleGNlcHQgTG9j
a0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjk4MSk6IE5hbWVFcnJvciA6
ICBMb2NrRmlsZSANCkp1biAwNiAwMToyMToyOCAyMDAwICgyMzA1NSkgRGVs
aXZlcnkgZXhjZXB0aW9uOiANCkp1biAwNiAwMToyMToyOCAyMDAwICgyMzA1
NSkgVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIs
IGxpbmUgNzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBt
c2csIG1zZ2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxt
YW4vSGFuZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nl
c3MNCiAgICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQog
ICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVm
cmVzaA0KICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJv
cjogDQoNCkp1biAwNiAwMToyMToyOSAyMDAwICgyMDYyOCkgRGVsaXZlcnkg
ZXhjZXB0aW9uOiANCkp1biAwNiAwMToyMTozMiAyMDAwICgyMDYyOCkgVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUg
NzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1z
Z2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAg
ICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2Vs
Zi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoN
Ckp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2MjgpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAwNiAwMToyMTozNiAyMDAwIHFy
dW5uZXIoMjA2MjgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL2Nyb24v
cXJ1bm5lciIsIGxpbmUgMTU0LCBpbiA/DQpKdW4gMDYgMDE6MjE6MzYgMjAw
MCBxcnVubmVyKDIwNjI4KTogICAgICBtYWluKCkNCkp1biAwNiAwMToyMToz
NiAyMDAwIHFydW5uZXIoMjA2MjgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL2Nyb24vcXJ1bm5lciIsIGxpbmUgMTM3LCBpbiBtYWluDQpKdW4gMDYg
MDE6MjE6MzYgMjAwMCBxcnVubmVyKDIwNjI4KTogICAgICBtbGlzdC5TYXZl
KCkNCkp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2MjgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBs
aW5lIDg2MCwgaW4gU2F2ZQ0KSnVuIDA2IDAxOjIxOjM2IDIwMDAgcXJ1bm5l
cigyMDYyOCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpKdW4gMDYg
MDE6MjE6MzYgMjAwMCBxcnVubmVyKDIwNjI4KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGlu
IHJlZnJlc2gNCkp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2Mjgp
OiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpKdW4gMDYgMDE6MjE6MzYg
MjAwMCBxcnVubmVyKDIwNjI4KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExv
Y2tlZEVycm9yICANCkp1biAwNiAwMToyMjowMiAyMDAwIHBvc3QoMjMwNDMp
OiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMwNDMpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4OSwgaW4gPw0KcG9zdCgyMzA0Myk6ICAgICAgbWFpbigpDQpwb3N0
KDIzMDQzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjMwNDMpOiAgICAg
IGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzMDQzKTog
TmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjIyOjEyIDIwMDAg
cG9zdCgyMzA0MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyMzA0MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMDQxKTogICAgICBt
YWluKCkNCnBvc3QoMjMwNDEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgy
MzA0MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBv
c3QoMjMwNDEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6
MjI6MTIgMjAwMCBwb3N0KDIzMDMxKTogVHJhY2ViYWNrIChpbm5lcm1vc3Qg
bGFzdCk6DQpwb3N0KDIzMDMxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1h
bi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMw
MzEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzAzMSk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBt
YWluDQpwb3N0KDIzMDMxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91
dEVycm9yOg0KcG9zdCgyMzAzMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSAN
Ckp1biAwNiAwMToyMjoxNCAyMDAwIHBvc3QoMjMwMjUpOiBUcmFjZWJhY2sg
KGlubmVybW9zdCBsYXN0KToNCkp1biAwNiAwMToyMjoxNCAyMDAwIHBvc3Qo
MjMwNDUpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMw
MjUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzAyNSk6ICAgICAgbWFpbigp
DQpwb3N0KDIzMDI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjMwMjUp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIz
MDQ1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMwNDUpOiAgICAgIG1haW4o
KQ0KcG9zdCgyMzA0NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIzMDQ1
KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgy
MzAyNSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3QoMjMwNDUpOiBO
YW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjI6MTUgMjAwMCBw
b3N0KDIzMDM3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0
KDIzMDM3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMwMzcpOiAgICAgIG1h
aW4oKQ0KcG9zdCgyMzAzNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIz
MDM3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9z
dCgyMzAzNyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToy
MjozMyAyMDAwICgyMjY4MCkgRGVsaXZlcnkgZXhjZXB0aW9uOiANCkp1biAw
NiAwMToyMjozNCAyMDAwICgyMjY4MCkgVHJhY2ViYWNrIChpbm5lcm1vc3Qg
bGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERlbGl2ZXJUb0xp
c3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQogIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01UUERpcmVjdC5w
eSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5TYXZlKCkNCiAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIs
IGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2sucmVmcmVzaCgp
DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUu
cHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNlIE5vdExvY2tl
ZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAwMToyMzo0MSAy
MDAwIHBvc3QoMjMwNzMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjMwNzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzA3Myk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzMDczKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjMwNzMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIzMDczKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjIzOjUwIDIwMDAgcXJ1bm5lcigyMzMzNyk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjIzOjUwIDIwMDAgcG9zdCgy
MzA4OCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzA4
OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMDg4KTogICAgICBtYWluKCkN
CnBvc3QoMjMwODgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzA4OCk6
ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjMw
ODgpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjQ6MzQg
MjAwMCBwb3N0KDIzMTIwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIzMTIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMxMjApOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMzEyMCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIzMTIwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMzEyMCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAw
NiAwMToyNTozNiAyMDAwIHBvc3QoMjMxODgpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjMxODgpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMzE4OCk6ICAgICAgbWFpbigpDQpwb3N0KDIzMTg4KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODMs
IGluIG1haW4NCnBvc3QoMjMxODgpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9z
dCgyMzE4OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9N
YWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDIzMTg4KTog
ICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjMxODgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBs
aW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyMzE4OCk6ICAgICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCnBvc3QoMjMxODgpOiBNYWlsbWFuLkxvY2tGaWxl
IC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjI2OjAzIDIwMDAgcG9z
dCgyMjY1MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjY1MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjUxKTogICAgICBtYWlu
KCkNCnBvc3QoMjI2NTEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgyMjY1
MSk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIyNjUxKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4
NjAsIGluIFNhdmUNCnBvc3QoMjI2NTEpOiAgICAgIHNlbGYuX19sb2NrLnJl
ZnJlc2goKQ0KcG9zdCgyMjY1MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNo
DQpwb3N0KDIyNjUxKTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9z
dCgyMjY1MSk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAg
DQpKdW4gMDYgMDE6MjY6MzkgMjAwMCBwb3N0KDIzMDQ4KTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzMDQ4KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjMwNDgpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzA0OCk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzMDQ4KTogICAgICBtbGlzdC5TYXZl
KCkNCnBvc3QoMjMwNDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgy
MzA0OCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzMDQ4
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCkp1biAwNiAwMToyNjo0OCAy
MDAwIHBvc3QoMjM1MDgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjM1MDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzUwOCk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzNTA4KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBv
c3QoMjM1MDgpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMzUwOCk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIs
IGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDIzNTA4KTogICAgICBzZWxmLl9f
bG9jay5yZWZyZXNoKCkNCnBvc3QoMjM1MDgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4g
cmVmcmVzaA0KcG9zdCgyMzUwOCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJy
b3INCnBvc3QoMjMwNDgpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpw
b3N0KDIzNTA4KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9y
ICANCnBvc3QoMjMwNDgpOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2Vk
RXJyb3IgIA0KSnVuIDA2IDAxOjI3OjE5IDIwMDAgKDIzNTU1KSBrY2MtbmV3
cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9o
b21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1
biAwNiAwMToyNzoyMCAyMDAwICgyMzU2MSkga2NjLW5ld3MgZGIgZmlsZSB3
YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFu
L2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6Mjc6
MjEgMjAwMCAoMjM1NDgpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQs
IHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2Mt
bmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjI3OjI0IDIwMDAgKDIz
NTYwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMToyNzozNiAyMDAwIHBvc3QoMjMyMjApOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMyMjApOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzIyMCk6ICAgICAgbWFpbigpDQpwb3N0KDIz
MjIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjMyMjApOiAgICAgIG1s
aXN0LlNhdmUoKQ0KcG9zdCgyMzIyMCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZl
DQpwb3N0KDIzMjIwKTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBv
c3QoMjMyMjApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyMzIy
MCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjMyMjApOiBN
YWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAx
OjI5OjM2IDIwMDAgKDIzMTk2KSBEZWxpdmVyeSBleGNlcHRpb246IA0KSnVu
IDA2IDAxOjI5OjQyIDIwMDAgKDIzMTk2KSBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9I
YW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVsaXZlclRv
TGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQRGlyZWN0
LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNhdmUoKQ0K
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5yZWZyZXNo
KCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2UgTm90TG9j
a2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVuIDA2IDAxOjI5OjQ5
IDIwMDAgcG9zdCgyMzE5Nik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyMzE5Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMTk2KTog
ICAgICBtYWluKCkNCnBvc3QoMjMxOTYpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0K
cG9zdCgyMzE5Nik6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIzMTk2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjMxOTYpOiAgICAgIHNlbGYu
X19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMzE5Nik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBp
biByZWZyZXNoDQpwb3N0KDIzMTk2KTogICAgICByYWlzZSBOb3RMb2NrZWRF
cnJvcg0KcG9zdCgyMzE5Nik6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2Nr
ZWRFcnJvciAgDQpKdW4gMDYgMDE6Mjk6NTggMjAwMCAoMjM3MDkpIGtjYy1u
ZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0
L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0K
SnVuIDA2IDAxOjI5OjU3IDIwMDAgcG9zdCgyMzIwOCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpKdW4gMDYgMDE6Mjk6NTggMjAwMCAoMjM3MDIpIGtjYy1uZXdzIGRiIGZp
bGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFp
bG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAx
OjI5OjU5IDIwMDAgKDIzNjk5KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3Jy
dXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMv
a2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCnBvc3QoMjMyMDgpOiAgICAgIG1h
aW4oKQ0KcG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIz
MjA4KTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjMyMDgpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5l
IDg2MCwgaW4gU2F2ZQ0KSnVuIDA2IDAxOjMwOjAwIDIwMDAgKDIzNzE2KSBr
Y2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazog
L29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxh
c3QNCnBvc3QoMjMyMDgpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0K
cG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDIz
MjA4KTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KSnVuIDA2IDAxOjMw
OjAyIDIwMDAgcG9zdCgyMzQ2Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMzQ2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDY3
KTogICAgICBtYWluKCkNCnBvc3QoMjM0NjcpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFp
bg0KcG9zdCgyMzQ2Nyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIzNDY3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0
LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjM0NjcpOiAgICAgIHNl
bGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMzQ2Nyk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0
LCBpbiByZWZyZXNoDQpwb3N0KDIzNDY3KTogICAgICByYWlzZSBOb3RMb2Nr
ZWRFcnJvcg0KcG9zdCgyMzQ2Nyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RM
b2NrZWRFcnJvciAgDQpwb3N0KDIzMjA4KTogTWFpbG1hbi5Mb2NrRmlsZSAu
IE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTozMDowNCAyMDAwICgyMzcw
OSkga2NjLW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0K
SnVuIDA2IDAxOjMwOjA2IDIwMDAgKDIzNzE2KSBrY2MtbmV3cyBmYWxsYmFj
ayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzA6MDcgMjAw
MCBwb3N0KDIzNzE2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBi
YWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MzA6MTAgMjAwMCAo
MjM2OTkpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcg
dXANCkp1biAwNiAwMTozMDoxMCAyMDAwIHBvc3QoMjM2OTkpOiBNYWlsbWFu
IGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MN
Ckp1biAwNiAwMTozMToxMyAyMDAwICgyMzc4Mikga2NjLW5ld3MgZGIgZmls
ZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWls
bWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6
MzE6MTQgMjAwMCAoMjM3NTEpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1
cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9r
Y2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMxOjE2IDIwMDAg
KDIzNzgyKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5n
IHVwDQpKdW4gMDYgMDE6MzE6MTYgMjAwMCAoMjM3NTEpIGtjYy1uZXdzIGZh
bGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMTox
OSAyMDAwICgyMzc3MCkga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwg
dXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1u
ZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MzE6MjUgMjAwMCAoMjM3
NzApIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXAN
Ckp1biAwNiAwMTozMTo0NCAyMDAwICgyMzgxOSkga2NjLW5ld3MgZGIgZmls
ZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWls
bWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6
MzE6NDUgMjAwMCAoMjM4MTkpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3Jy
dXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMTo0NSAyMDAwIHBvc3QoMjM4
MTkpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFt
ZToga2NjLW5ld3MNCkp1biAwNiAwMTozMTo0OSAyMDAwIHBvc3QoMjM3NTEp
OiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZTog
a2NjLW5ld3MNCmJhZCBtYXJzaGFsIGRhdGFKdW4gMDYgMDE6MzE6NTEgMjAw
MCAoMjM4MzIpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5n
IGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9j
b25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMyOjI2IDIwMDAgKDIzODYwKSBr
Y2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazog
L29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxh
c3QNCkp1biAwNiAwMTozMjoyOSAyMDAwICgyMzg2MCkga2NjLW5ld3MgZmFs
bGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjMyOjQ2
IDIwMDAgcG9zdCgyMzQ3MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyMzQ3MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDcwKTog
ICAgICBtYWluKCkNCnBvc3QoMjM0NzApOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0K
cG9zdCgyMzQ3MCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJv
cjoNCnBvc3QoMjM0NzApOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4g
MDYgMDE6MzM6MjAgMjAwMCBwb3N0KDIzNTAxKTogVHJhY2ViYWNrIChpbm5l
cm1vc3QgbGFzdCk6DQpwb3N0KDIzNTAxKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjM1MDEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzUwMSk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYx
LCBpbiBtYWluDQpwb3N0KDIzNTAxKTogICAgICBleGNlcHQgTG9ja0ZpbGUu
VGltZU91dEVycm9yOg0KcG9zdCgyMzUwMSk6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCkp1biAwNiAwMTozMzozMyAyMDAwIHBvc3QoMjM0OTcpOiBUcmFj
ZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM0OTcpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4
OSwgaW4gPw0KcG9zdCgyMzQ5Nyk6ICAgICAgbWFpbigpDQpwb3N0KDIzNDk3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0OTcpOiAgICAgIGV4Y2Vw
dCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDk3KTogTmFtZUVy
cm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjMzOjM2IDIwMDAgKDIzOTI2
KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFj
azogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRi
Lmxhc3QNCkp1biAwNiAwMTozMzozOCAyMDAwICgyMzkyNikga2NjLW5ld3Mg
ZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjMz
OjQwIDIwMDAgcG9zdCgyMzU1MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMzU1MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNTUw
KTogICAgICBtYWluKCkNCnBvc3QoMjM1NTApOiBNZW1vcnlFcnJvciAgDQpK
dW4gMDYgMDE6MzM6NDMgMjAwMCAoMjM5MzcpIGtjYy1uZXdzIGRiIGZpbGUg
d2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1h
bi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMz
OjQ0IDIwMDAgKDIzOTM5KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0
LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2Nj
LW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTozMzo0NiAyMDAwIHBv
c3QoMjM1MzApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3Qo
MjM1MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzUzMCk6ICAgICAgbWFp
bigpDQpwb3N0KDIzNTMwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjM1
MzApOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMzUzMCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUg
ODYwLCBpbiBTYXZlDQpKdW4gMDYgMDE6MzM6NDUgMjAwMCBwb3N0KDIzNDk0
KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYgMDE6MzM6
NDYgMjAwMCAoMjM5MzcpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0
LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMzo0NiAyMDAwICgyMzkzOSkga2Nj
LW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KcG9zdCgy
MzUzMCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzNTMw
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjM0OTQpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzQ5NCk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NDk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0OTQpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDk0KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KcG9zdCgyMzUzMCk6ICAgICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCnBvc3QoMjM1MzApOiBNYWlsbWFuLkxvY2tGaWxl
IC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjMzOjU0IDIwMDAgKDIz
OTQ3KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNDozMSAyMDAwIHBvc3QoMjM1MjkpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM1MjkpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzUyOSk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NTI5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1MjkpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTI5KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM0OjQ0IDIwMDAgKDI0
MDA2KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNDo0NyAyMDAwICgyNDAwNikga2NjLW5l
d3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAx
OjM0OjU0IDIwMDAgcG9zdCgyMzU1Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMzU1Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIz
NTU3KTogICAgICBtYWluKCkNCnBvc3QoMjM1NTcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4g
bWFpbg0KcG9zdCgyMzU1Nyk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVP
dXRFcnJvcjoNCnBvc3QoMjM1NTcpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUg
DQpKdW4gMDYgMDE6MzU6MTEgMjAwMCAoMjQwNDIpIGtjYy1uZXdzIGRiIGZp
bGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFp
bG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAx
OjM1OjE0IDIwMDAgKDI0MDQyKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29y
cnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzU6MjcgMjAwMCAoMjQwNTcp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjM1OjI5IDIwMDAgKDI0MDU3KSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzU6
NTkgMjAwMCBxcnVubmVyKDIzNTUyKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1
bm5lciBsb2NrDQpKdW4gMDYgMDE6MzY6MDUgMjAwMCAoMjQwODcpIGtjYy1u
ZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0
L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0K
SnVuIDA2IDAxOjM2OjA1IDIwMDAgKDI0MDg3KSBrY2MtbmV3cyBmYWxsYmFj
ayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzY6MDcgMjAw
MCBxcnVubmVyKDIzMzQwKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBs
b2NrDQpKdW4gMDYgMDE6MzY6MTcgMjAwMCBxcnVubmVyKDIzMzM5KTogQ291
bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MzY6MTcg
MjAwMCBxcnVubmVyKDIzMzYzKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5l
ciBsb2NrDQpKdW4gMDYgMDE6MzY6MjMgMjAwMCBhZG1pbigyNDA5Mik6IEBA
QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBADQph
ZG1pbigyNDA5Mik6IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDIuMGJldGEz
IC0tLS0tXQ0KYWRtaW4oMjQwOTIpOiBbLS0tLS0gVHJhY2ViYWNrIC0tLS0t
LV0NCmFkbWluKDI0MDkyKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQphZG1pbigyNDA5Mik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9kcml2ZXIiLCBsaW5lIDg5LCBpbiBydW5fbWFpbg0KSnVuIDA2IDAx
OjM2OjI5IDIwMDAgcXJ1bm5lcigyMzYxNSk6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjMwIDIwMDAgcXJ1bm5lcigy
MzQ1OSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAxOjM2OjMzIDIwMDAgcXJ1bm5lcigyMzY5MCk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjM1IDIwMDAgcXJ1bm5l
cigyMzY1NCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAxOjM2OjQyIDIwMDAgcXJ1bm5lcigyMzc1Nik6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjUxIDIwMDAgKDI0
MTEzKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNjo1MiAyMDAwIHBvc3QoMjM1NjEpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM1NjEpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzU2MSk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NTYxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1NjEpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTYxKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM3OjAwIDIwMDAgKDI0
MTM2KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNzowMSAyMDAwICgyNDEzNCkga2NjLW5l
d3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQv
aG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpK
dW4gMDYgMDE6Mzc6MDEgMjAwMCAoMjQxMzYpIGtjYy1uZXdzIGZhbGxiYWNr
IHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozNzowMCAyMDAw
IHBvc3QoMjM0MzcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1
biAwNiAwMTozNzowMSAyMDAwICgyNDEzNCkga2NjLW5ld3MgZmFsbGJhY2sg
d2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KcG9zdCgyMzQzNyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIzNDM3KTogICAgICBtYWluKCkNCnBvc3QoMjM0Mzcp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzQzNyk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM0MzcpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6Mzc6MzYgMjAwMCAoMjQxNzIp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjM3OjM4IDIwMDAgKDI0MTcyKSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6Mzc6
MzkgMjAwMCBwb3N0KDIzNjY4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIzNjY4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM2Njgp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMzY2OCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIzNjY4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMzY2OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTozNzo0NSAyMDAwIHFydW5uZXIoMjM4OTYpOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTozNzo0OSAyMDAwIHBv
c3QoMjQxNzIpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBs
aXN0bmFtZToga2NjLW5ld3MNCmJhZCBtYXJzaGFsIGRhdGFKdW4gMDYgMDE6
Mzc6NDkgMjAwMCBwb3N0KDI0MTM2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6Mzc6
NTEgMjAwMCBwb3N0KDI0MTM0KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVy
IGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hhbCBkYXRh
SnVuIDA2IDAxOjM4OjAwIDIwMDAgcG9zdCgyNDA4Nyk6IE1haWxtYW4gZXJy
b3I6IG1haWxvd25lciBnb3QgYmFkIGxpc3RuYW1lOiBrY2MtbmV3cw0KSnVu
IDA2IDAxOjM4OjAxIDIwMDAgcG9zdCgyMzYzNyk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzYzNyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIzNjM3KTogICAgICBtYWluKCkNCnBvc3QoMjM2MzcpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMzYzNyk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCkp1biAwNiAwMTozODowMiAyMDAwIHBvc3QoMjQw
MDYpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFt
ZToga2NjLW5ld3MNCnBvc3QoMjM2MzcpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6Mzg6MDIgMjAwMCBwb3N0KDIzOTM3KTogTWFpbG1h
biBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdz
DQpKdW4gMDYgMDE6Mzg6MDMgMjAwMCBwb3N0KDIzOTI2KTogTWFpbG1hbiBl
cnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpK
dW4gMDYgMDE6Mzg6MDMgMjAwMCBwb3N0KDIzOTM5KTogTWFpbG1hbiBlcnJv
cjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4g
MDYgMDE6Mzg6MDQgMjAwMCBwb3N0KDI0MDQyKTogTWFpbG1hbiBlcnJvcjog
bWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYg
MDE6Mzg6MDQgMjAwMCBwb3N0KDI0MDU3KTogTWFpbG1hbiBlcnJvcjogbWFp
bG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hh
bCBkYXRhYmFkIG1hcnNoYWwgZGF0YUp1biAwNiAwMTozODowOCAyMDAwIHBv
c3QoMjM1NjApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTozODowOCAyMDAwIHBvc3QoMjM3ODIpOiBNYWlsbWFuIGVycm9yOiBt
YWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAw
MTozODowOSAyMDAwIHBvc3QoMjM4NjApOiBNYWlsbWFuIGVycm9yOiBtYWls
b3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCnBvc3QoMjM1NjAp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KSnVuIDA2IDAxOjM4OjEwIDIwMDAgcG9zdCgy
Mzc3MCk6IE1haWxtYW4gZXJyb3I6IG1haWxvd25lciBnb3QgYmFkIGxpc3Ru
YW1lOiBrY2MtbmV3cw0KcG9zdCgyMzU2MCk6ICAgICAgbWFpbigpDQpwb3N0
KDIzNTYwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1NjApOiAgICAg
IGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTYwKTog
TmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM4OjA5IDIwMDAg
cG9zdCgyMzQ5NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyMzQ5NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDk1KTogICAgICBt
YWluKCkNCnBvc3QoMjM0OTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgy
MzQ5NSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBv
c3QoMjM0OTUpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6
Mzg6MTEgMjAwMCBwb3N0KDIzNzA5KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hhbCBk
YXRhSnVuIDA2IDAxOjM4OjE3IDIwMDAgcG9zdCgyMzY2Nik6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzY2Nik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIzNjY2KTogICAgICBtYWluKCkNCnBvc3QoMjM2NjYpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzY2Nik6ICAgICAgZXhjZXB0IExv
Y2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM2NjYpOiBOYW1lRXJyb3Ig
OiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDA6MzMgMjAwMCBwb3N0KDIzODMy
KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzODMyKTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgODksIGluID8NCnBvc3QoMjM4MzIpOiAgICAgIG1haW4oKQ0KcG9z
dCgyMzgzMik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIzODMyKTogICAg
ICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMzgzMik6
IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0MToyNCAyMDAw
ICgyNDM1Nikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcg
ZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2Nv
bmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDE6MjQgMjAwMCAoMjQzNTQpIGtj
Yy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAv
b3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFz
dA0KSnVuIDA2IDAxOjQxOjI0IDIwMDAgKDI0MzYxKSBrY2MtbmV3cyBkYiBm
aWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21h
aWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAw
MTo0MToyNCAyMDAwICgyNDM0Nykga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29y
cnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3Rz
L2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDE6MjUgMjAw
MCAoMjQzNDcpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZp
bmcgdXANCkp1biAwNiAwMTo0MToyNSAyMDAwICgyNDM2MSkga2NjLW5ld3Mg
ZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjQx
OjI1IDIwMDAgKDI0MzU2KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVw
dCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDE6MjUgMjAwMCAoMjQzNTQpIGtj
Yy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAw
NiAwMTo0MTo0MCAyMDAwIHBvc3QoMjM1MTUpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjM1MTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMzUxNSk6ICAgICAgbWFpbigpDQpwb3N0KDIzNTE1KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjM1MTUpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIzNTE1KTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjQxOjQxIDIwMDAgcG9zdCgyMzQ4MCk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzQ4MCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIzNDgwKTogICAgICBtYWluKCkNCnBvc3QoMjM0ODAp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzQ4MCk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM0ODApOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDE6NTAgMjAwMCBwb3N0KDI0
MjQ3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0MjQ3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQyNDcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyNDI0Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0MjQ3KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjQyNDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyNDI0Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDI0MjQ3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjQyNDcpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0
MjQ3KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo0MjowMSAyMDAwIHBvc3QoMjM2NzEpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjM2NzEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyMzY3MSk6ICAgICAgbWFpbigpDQpwb3N0KDIzNjcxKTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjM2NzEpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNjcxKTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQyOjIxIDIwMDAgcG9zdCgyNDI1Mik6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDI1Mik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDI0MjUyKTogICAgICBtYWluKCkNCnBvc3QoMjQy
NTIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2OCwgaW4gbWFpbg0KcG9zdCgyNDI1Mik6ICAgICAgaWYg
Qm91bmNlckFQSS5TY2FuTWVzc2FnZXMobWxpc3QsIG1zZyk6DQpwb3N0KDI0
MjUyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0JvdW5j
ZXJzL0JvdW5jZXJBUEkucHkiLCBsaW5lIDUwLCBpbiBTY2FuTWVzc2FnZXMN
CnBvc3QoMjQyNTIpOiAgICAgIGFkZHJzID0gZnVuYyhtc2cpDQpwb3N0KDI0
MjUyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0JvdW5j
ZXJzL0RTTi5weSIsIGxpbmUgNjAsIGluIHByb2Nlc3MNCnBvc3QoMjQyNTIp
OiAgICAgIHMgPSBTdHJpbmdJTyhtZmlsZS5yZWFkKCkpDQpwb3N0KDI0MjUy
KTogICBGaWxlICIvdXNyL2xvY2FsL2xpYi9weXRob24xLjUvbXVsdGlmaWxl
LnB5IiwgbGluZSAxMTgsIGluIHJlYWQNCnBvc3QoMjQyNTIpOiAgICAgIHJl
dHVybiBzdHJpbmcuam9pbmZpZWxkcyhzZWxmLnJlYWRsaW5lcygpLCAnJykN
CnBvc3QoMjQyNTIpOiAgIEZpbGUgIi91c3IvbG9jYWwvbGliL3B5dGhvbjEu
NS9tdWx0aWZpbGUucHkiLCBsaW5lIDExNCwgaW4gcmVhZGxpbmVzDQpwb3N0
KDI0MjUyKTogICAgICBsaXN0LmFwcGVuZChsaW5lKQ0KcG9zdCgyNDI1Mik6
IE1lbW9yeUVycm9yICANCkp1biAwNiAwMTo0Mjo0NyAyMDAwIHBvc3QoMjM0
MjkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM0Mjkp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQyOSk6ICAgICAgbWFpbigpDQpw
b3N0KDIzNDI5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0MjkpOiAg
ICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDI5
KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQyOjQ5IDIw
MDAgcG9zdCgyMzk3MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyMzk3MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzOTcxKTogICAg
ICBtYWluKCkNCnBvc3QoMjM5NzEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyMzk3MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjM5NzEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6NDI6NTIgMjAwMCBwb3N0KDIzNDQxKTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIzNDQxKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjM0NDEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzQ0MSk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDIzNDQxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KSnVuIDA2IDAxOjQyOjUzIDIwMDAgcG9zdCgyMzQ0Nik6
IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzQ0MSk6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3QoMjM0NDYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyMzQ0Nik6ICAgICAgbWFpbigpDQpwb3N0KDIzNDQ2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0NDYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDQ2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQ0OjU5IDIwMDAgcG9zdCgyNDQ2
MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDQ2MSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NDYxKTogICAgICBtYWluKCkNCnBv
c3QoMjQ0NjEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgyNDQ2MSk6ICAg
ICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0NDYxKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGlu
IFNhdmUNCnBvc3QoMjQ0NjEpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2go
KQ0KcG9zdCgyNDQ2MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0
KDI0NDYxKTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyNDQ2
MSk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4g
MDYgMDE6NDU6MjIgMjAwMCBwb3N0KDI0MTEzKTogVHJhY2ViYWNrIChpbm5l
cm1vc3QgbGFzdCk6DQpwb3N0KDI0MTEzKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjQxMTMpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDExMyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgz
LCBpbiBtYWluDQpwb3N0KDI0MTEzKTogICAgICBtbGlzdC5TYXZlKCkNCnBv
c3QoMjQxMTMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyNDExMyk6
ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDI0MTEzKTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5Iiwg
bGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQxMTMpOiAgICAgIHJhaXNl
IE5vdExvY2tlZEVycm9yDQpwb3N0KDI0MTEzKTogTWFpbG1hbi5Mb2NrRmls
ZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo0NTo0NSAyMDAwICgy
NDUxNikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFs
bGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZp
Zy5kYi5sYXN0DQpKdW4gMDYgMDE6NDU6NDUgMjAwMCBhZG1pbigyNDUxNyk6
IEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA
DQphZG1pbigyNDUxNyk6IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDIuMGJl
dGEzIC0tLS0tXQ0KYWRtaW4oMjQ1MTcpOiBbLS0tLS0gVHJhY2ViYWNrIC0t
LS0tLV0NCmFkbWluKDI0NTE3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQphZG1pbigyNDUxNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9kcml2ZXIiLCBsaW5lIDg5LCBpbiBydW5fbWFpbg0KSnVuIDA2
IDAxOjQ1OjQ1IDIwMDAgKDI0NTA1KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBj
b3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlz
dHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTo0NTo0NSAy
MDAwICgyNDUxMikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNp
bmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdz
L2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDU6NDYgMjAwMCAoMjQ1MDcp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjQ1OjQ3IDIwMDAgKDI0NTA1KSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDU6
NDcgMjAwMCAoMjQ1MTIpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0
LCBnaXZpbmcgdXANCkp1biAwNiAwMTo0NTo0NyAyMDAwICgyNDUwNykga2Nj
LW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2
IDAxOjQ1OjQ5IDIwMDAgKDI0NTE2KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMg
Y29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDU6NTkgMjAwMCBwb3N0
KDI0MTY0KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0
MTY0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQxNjQpOiAgICAgIG1haW4o
KQ0KcG9zdCgyNDE2NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0MTY0
KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgy
NDE2NCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0Njow
OCAyMDAwIHBvc3QoMjQ1MDUpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIg
Z290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAwMTo0NjoxOCAy
MDAwIHBvc3QoMjQzNTQpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290
IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAwMTo0NjoyNCAyMDAw
IHBvc3QoMjM0MjUpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBv
c3QoMjM0MjUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQyNSk6ICAgICAg
bWFpbigpDQpwb3N0KDIzNDI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1h
bi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3Qo
MjM0MjUpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpw
b3N0KDIzNDI1KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAx
OjQ2OjMzIDIwMDAgcG9zdCgyMzQ0Myk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMzQ0Myk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIz
NDQzKTogICAgICBtYWluKCkNCnBvc3QoMjM0NDMpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4g
bWFpbg0KcG9zdCgyMzQ0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVP
dXRFcnJvcjoNCnBvc3QoMjM0NDMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUg
DQpKdW4gMDYgMDE6NDY6MzcgMjAwMCBwb3N0KDIzOTk3KTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzOTk3KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjM5OTcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzk5Nyk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzOTk3KTogICAgICBtbGlzdC5TYXZl
KCkNCnBvc3QoMjM5OTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgy
Mzk5Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzOTk3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjM5OTcpOiAgICAg
IHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIzOTk3KTogTWFpbG1hbi5M
b2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo0Njo0MiAy
MDAwIHBvc3QoMjM0NDkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjM0NDkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQ0OSk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzNDQ5KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjM0NDkpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIzNDQ5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjQ2OjQ2IDIwMDAgcG9zdCgyNDM0Nyk6IE1haWxtYW4gZXJyb3I6IG1h
aWxvd25lciBnb3QgYmFkIGxpc3RuYW1lOiBrY2MtbmV3cw0KSnVuIDA2IDAx
OjQ2OjQ3IDIwMDAgcG9zdCgyNDMwNyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyNDMwNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0
MzA3KTogICAgICBtYWluKCkNCnBvc3QoMjQzMDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyNDMwNyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0
MzA3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQzMDcpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDMwNyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0MzA3KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyNDMwNyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NDY6NTUgMjAwMCBwb3N0KDIz
OTQ3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzOTQ3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM5NDcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMzk0Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzOTQ3KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjM5NDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyMzk0Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDIzOTQ3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjM5NDcpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIz
OTQ3KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo0Njo1NiAyMDAwIHBvc3QoMjQyMjEpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQyMjEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDIyMSk6ICAgICAgbWFpbigpDQpwb3N0KDI0MjIxKTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjQyMjEpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjIxKTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQ3OjI0IDIwMDAgcG9zdCgyNDI0NCk6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDI0NCk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDI0MjQ0KTogICAgICBtYWluKCkNCnBvc3QoMjQy
NDQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDI0NCk6ICAgICAgZXhj
ZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQyNDQpOiBOYW1l
RXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDc6MzQgMjAwMCBwb3N0
KDI0NTE2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlz
dG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6MzUgMjAwMCBwb3N0KDI0
NTA3KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5h
bWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6MzYgMjAwMCBwb3N0KDI0NTEy
KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6
IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6NDAgMjAwMCBwb3N0KDI0MzYxKTog
TWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtj
Yy1uZXdzDQpKdW4gMDYgMDE6NDc6NDEgMjAwMCBwb3N0KDI0MzU2KTogTWFp
bG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1u
ZXdzDQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjQ3OjQ2IDIwMDAgcG9z
dCgyNDIxNyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
NDIxNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0MjE3KTogICAgICBtYWlu
KCkNCnBvc3QoMjQyMTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDIx
Nyk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjQyMTcpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDc6
NDggMjAwMCBwb3N0KDI0MjA3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDI0MjA3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQyMDcp
OiAgICAgIG1haW4oKQ0KcG9zdCgyNDIwNyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDI0MjA3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyNDIwNyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTo0Nzo0OSAyMDAwIHBvc3QoMjQyMjQpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQyMjQpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDIyNCk6ICAgICAgbWFpbigpDQpwb3N0KDI0MjI0KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjQyMjQpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjI0KTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQ4OjAzIDIwMDAgcG9zdCgyNDI4MSk6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KSnVuIDA2IDAxOjQ4OjAzIDIw
MDAgcG9zdCgyNDI3Mik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyNDI4MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0MjgxKTogICAg
ICBtYWluKCkNCnBvc3QoMjQyODEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyNDI4MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjQyNzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDI3Mik6ICAg
ICAgbWFpbigpDQpwb3N0KDI0MjcyKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjQyNzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDI0MjcyKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KcG9zdCgy
NDI4MSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0ODow
NyAyMDAwIHBvc3QoMjQyNzQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0
KToNCnBvc3QoMjQyNzQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDI3NCk6
ICAgICAgbWFpbigpDQpwb3N0KDI0Mjc0KTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4N
CnBvc3QoMjQyNzQpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJy
b3I6DQpwb3N0KDI0Mjc0KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjQ4OjMxIDIwMDAgcG9zdCgyNDMwMyk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDMwMyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDI0MzAzKTogICAgICBtYWluKCkNCnBvc3QoMjQzMDMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyNDMwMyk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQzMDMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6NDg6MzkgMjAwMCBwb3N0KDI0MzA5KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0MzA5KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjQzMDkpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDMw
OSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0MzA5KTogICAgICBleGNl
cHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyNDMwOSk6IE5hbWVF
cnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0OTozNCAyMDAwIHBvc3Qo
MjQyMzQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQy
MzQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDIzNCk6ICAgICAgbWFpbigp
DQpwb3N0KDI0MjM0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQyMzQp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0
MjM0KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQ5OjQy
IDIwMDAgcG9zdCgyNDIzNik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KSnVuIDA2IDAxOjQ5OjQyIDIwMDAgcG9zdCgyNDE5Nyk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDIzNik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDI0MTk3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQxOTcp
OiAgICAgIG1haW4oKQ0KcG9zdCgyNDE5Nyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDI0MTk3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyNDIzNik6ICAgICAgbWFpbigpDQpwb3N0KDI0MjM2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQyMzYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjM2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KcG9zdCgyNDE5Nyk6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCkp1biAwNiAwMTo1MDoxNiAyMDAwICgyNDQyOSkgRGVsaXZlcnkg
ZXhjZXB0aW9uOiANCkp1biAwNiAwMTo1MDoyMSAyMDAwICgyNDQyOSkgVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUg
NzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1z
Z2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAg
ICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2Vs
Zi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoN
Ckp1biAwNiAwMTo1MDoyMyAyMDAwIHBvc3QoMjQ0MjkpOiBUcmFjZWJhY2sg
KGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ0MjkpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4g
Pw0KcG9zdCgyNDQyOSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NDI5KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODMsIGluIG1haW4NCnBvc3QoMjQ0MjkpOiAgICAgIG1saXN0LlNhdmUo
KQ0KcG9zdCgyNDQyOSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDI0
NDI5KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjQ0Mjkp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUu
cHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDQyOSk6ICAgICAg
cmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ0MjkpOiBNYWlsbWFuLkxv
Y2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjUwOjUxIDIw
MDAgcG9zdCgyNDM4NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyNDM4NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0Mzg1KTogICAg
ICBtYWluKCkNCnBvc3QoMjQzODUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyNDM4NSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjQzODUpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6NTE6MTAgMjAwMCBwb3N0KDI0NDEyKTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDI0NDEyKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjQ0MTIpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDQxMik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDI0NDEyKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KcG9zdCgyNDQxMik6IE5hbWVFcnJvciA6ICBMb2NrRmls
ZSANCkp1biAwNiAwMTo1MTo0NSAyMDAwIHBvc3QoMjQ0MjYpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ0MjYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyNDQyNik6ICAgICAgbWFpbigpDQpwb3N0KDI0NDI2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQ0MjYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0NDI2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjUxOjU0IDIwMDAgcG9zdCgyNDQy
MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDQyMSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NDIxKTogICAgICBtYWluKCkNCnBv
c3QoMjQ0MjEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDQyMSk6ICAg
ICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQ0MjEp
OiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NTI6MzkgMjAw
MCBwb3N0KDI0NDQ4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpw
b3N0KDI0NDQ4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQ0NDgpOiAgICAg
IG1haW4oKQ0KcG9zdCgyNDQ0OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0
KDI0NDQ4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0K
cG9zdCgyNDQ0OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAw
MTo1Mjo0MCAyMDAwIHBvc3QoMjQ0NTgpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjQ0NTgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
NDQ1OCk6ICAgICAgbWFpbigpDQpwb3N0KDI0NDU4KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjQ0NTgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDI0NDU4KTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjUzOjMzIDIwMDAgcG9zdCgyNDc1MSk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDc1MSk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDI0NzUxKTogICAgICBtYWluKCkNCnBvc3QoMjQ3NTEpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4MywgaW4gbWFpbg0KcG9zdCgyNDc1MSk6ICAgICAgbWxpc3QuU2F2
ZSgpDQpwb3N0KDI0NzUxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3Qo
MjQ3NTEpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDc1
MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0NzUxKTogICAg
ICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyNDc1MSk6IE1haWxtYW4u
TG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NTM6MzUg
MjAwMCBwb3N0KDIzNTAzKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIzNTAzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM1MDMpOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMzUwMyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpw
b3N0KDIzNTAzKTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjM1MDMpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHki
LCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyMzUwMyk6ICAgICAgc2VsZi5f
X2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzNTAzKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGlu
IHJlZnJlc2gNCnBvc3QoMjM1MDMpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVy
cm9yDQpwb3N0KDIzNTAzKTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tl
ZEVycm9yICANCkp1biAwNiAwMTo1NDowOCAyMDAwIHBvc3QoMjQ1OTcpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1OTcpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyNDU5Nyk6ICAgICAgbWFpbigpDQpwb3N0KDI0
NTk3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjQ1OTcpOiAgICAgIG1s
aXN0LlNhdmUoKQ0KcG9zdCgyNDU5Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZl
DQpwb3N0KDI0NTk3KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBv
c3QoMjQ1OTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDU5
Nyk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ1OTcpOiBN
YWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAx
OjU0OjM3IDIwMDAgcG9zdCgyNDY1NCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyNDY1NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0
NjU0KTogICAgICBtYWluKCkNCnBvc3QoMjQ2NTQpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyNDY1NCk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0
NjU0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ2NTQpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDY1NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0NjU0KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyNDY1NCk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NTQ6NTIgMjAwMCBwb3N0KDI0
NzI1KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NzI1
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQ3MjUpOiAgICAgIG1haW4oKQ0K
cG9zdCgyNDcyNSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0NzI1KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjQ3MjUpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyNDcyNSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDI0NzI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjQ3MjUpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0
NzI1KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo1NToxMCAyMDAwIHBvc3QoMjQ1NTUpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1NTUpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDU1NSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NTU1KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODMsIGluIG1haW4NCnBvc3QoMjQ1NTUpOiAgICAgIG1saXN0LlNhdmUoKQ0K
cG9zdCgyNDU1NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDI0NTU1
KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjQ1NTUpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHki
LCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDU1NSk6ICAgICAgcmFp
c2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ1NTUpOiBNYWlsbWFuLkxvY2tG
aWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjU1OjEwIDIwMDAg
cG9zdCgyNDU2Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyNDU2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NTY3KTogICAgICBt
YWluKCkNCnBvc3QoMjQ1NjcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgy
NDU2Nyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0NTY3KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGlu
ZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ1NjcpOiAgICAgIHNlbGYuX19sb2Nr
LnJlZnJlc2goKQ0KcG9zdCgyNDU2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZy
ZXNoDQpwb3N0KDI0NTY3KTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0K
cG9zdCgyNDU2Nyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJv
ciAgDQpKdW4gMDYgMDE6NTU6MTcgMjAwMCBwb3N0KDI0NTc5KTogVHJhY2Vi
YWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NTc5KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODks
IGluID8NCnBvc3QoMjQ1NzkpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDU3OSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0NTc5KTogICAgICBtbGlzdC5T
YXZlKCkNCnBvc3QoMjQ1NzkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9z
dCgyNDU3OSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDI0
NTc5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tG
aWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQ1NzkpOiAg
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0NTc5KTogTWFpbG1h
bi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo1NToz
MiAyMDAwIHBvc3QoMjQ1NDgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0
KToNCnBvc3QoMjQ1NDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDU0OCk6
ICAgICAgbWFpbigpDQpwb3N0KDI0NTQ4KTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4N
CnBvc3QoMjQ1NDgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJy
b3I6DQpwb3N0KDI0NTQ4KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjU1OjMzIDIwMDAgcG9zdCgyNDU0Myk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDU0Myk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDI0NTQzKTogICAgICBtYWluKCkNCnBvc3QoMjQ1NDMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyNDU0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQ1NDMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6NTY6MDcgMjAwMCBwb3N0KDI0NTg2KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NTg2KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjQ1ODYpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDU4
Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0NTg2KTogICAgICBleGNl
cHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyNDU4Nik6IE5hbWVF
cnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo1NjoxNyAyMDAwIHBvc3Qo
MjQ1OTkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1
OTkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDU5OSk6ICAgICAgbWFpbigp
DQpwb3N0KDI0NTk5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQ1OTkp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0
NTk5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjU2OjMx
IDIwMDAgcG9zdCgyNDg2Nik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyNDg2Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0ODY2KTog
ICAgICBtYWluKCkNCnBvc3QoMjQ4NjYpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0K
cG9zdCgyNDg2Nik6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0ODY2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ4NjYpOiAgICAgIHNlbGYu
X19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDg2Nik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBp
biByZWZyZXNoDQpwb3N0KDI0ODY2KTogICAgICByYWlzZSBOb3RMb2NrZWRF
cnJvcg0KcG9zdCgyNDg2Nik6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2Nr
ZWRFcnJvciAgDQpKdW4gMDYgMDE6NTY6MzUgMjAwMCBwb3N0KDI0Njk1KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0Njk1KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjQ2OTUpOiAgICAgIG1haW4oKQ0KcG9zdCgy
NDY5NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0Njk1KTogICAgICBt
bGlzdC5TYXZlKCkNCnBvc3QoMjQ2OTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2
ZQ0KcG9zdCgyNDY5NSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpw
b3N0KDI0Njk1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFu
L0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQ2
OTUpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0Njk1KTog
TWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAw
MTo1Njo0MCAyMDAwIHBvc3QoMjQ2MjkpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjQ2MjkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
NDYyOSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NjI5KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjQ2MjkpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDI0NjI5KTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjU3OjA3IDIwMDAgKDI0NjEyKSBEZWxpdmVyeSBleGNl
cHRpb246IA0KSnVuIDA2IDAxOjU3OjA3IDIwMDAgKDI0NjEyKSBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwg
aW4gRGVsaXZlclRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0
YSkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVy
cy9TTVRQRGlyZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1s
aXN0LlNhdmUoKQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFu
L01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9f
bG9jay5yZWZyZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAg
cmFpc2UgTm90TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVu
IDA2IDAxOjU3OjE1IDIwMDAgKDI0NzExKSBEZWxpdmVyeSBleGNlcHRpb246
IA0KSnVuIDA2IDAxOjU3OjE1IDIwMDAgKDI0NzExKSBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVs
aXZlclRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQ
RGlyZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNh
dmUoKQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5y
ZWZyZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9M
b2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg==
---559023410-959030623-960272479=:25061--


From bwarsaw@python.org  Thu Jun  8 04:45:36 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 23:45:36 -0400 (EDT)
Subject: [Mailman-Developers] multifile.Error :  sudden EOF in MultiFile.readline()
References: <Pine.GSO.4.21.0006071244180.25061-100000@alb-net.com>
Message-ID: <14655.5856.797357.860746@anthem.concentric.net>

In situations like this, it would be nice to have the original
message, because it's probably incomplete or otherwise misformated.
But in any case, please try this patch.

-Barry

Index: Postfix.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Postfix.py,v
retrieving revision 1.6
diff -c -r1.6 Postfix.py
*** Postfix.py	2000/06/05 15:54:47	1.6
--- Postfix.py	2000/06/08 03:41:18
***************
*** 43,49 ****
          if not more:
              # we didn't find it
              return None
!         s = StringIO(mfile.read())
          msg2 = mimetools.Message(s)
          if msg2.gettype() == 'text/plain':
              desc = msg2.get('content-description')
--- 43,53 ----
          if not more:
              # we didn't find it
              return None
!         try:
!             s = StringIO(mfile.read())
!         except multifile.Error:
!             # It is a mis-formated or incomplete message
!             return None
          msg2 = mimetools.Message(s)
          if msg2.gettype() == 'text/plain':
              desc = msg2.get('content-description')



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun  8 04:45:16 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Wed, 7 Jun 2000 20:45:16 -0700 (PDT)
Subject: [Mailman-Developers] Mass unsubscription
Message-ID: <200006080345.UAA03544@utopia.west.sun.com>

Anyone have any comments?

Barry/Harald/whoever, as much discussion as this engendered on
mailman-users, if this looks good, maybe it could get squeezed into
beta3 (due any second now, right)?

------------- Begin Forwarded Message -------------

Date: Wed, 7 Jun 2000 20:21:30 -0700 (PDT)
From: Dan Mick <Dan.Mick@west.sun.com>
To: mailman-users@python.org
Subject: [Mailman-Users] Mass unsubscription
X-Beenthere: mailman-users@python.org
X-Mailman-Version: 2.0beta3
List-Id: Mailman mailing list management users <mailman-users.python.org>

In the "put up or shut up" category, I volunteer this patch to
add and process a "mass-unsubscribe" text box to the "Membership
Management" page for Mailman 1.1 (I haven't tried to make it 
apply to any 2.0 yet, although I'm sure the code will be similar).

It seems to work for me for a test list.  YMMV.  I'll submit
it over on mailman-developers too and see if anyone has any
criticism.

The file that changes is Cgi/admin.py:



*** admin.py.orig       Thu Jun  1 23:09:46 2000
--- admin.py    Wed Jun  7 20:18:52 2000
***************
*** 612,617 ****
--- 612,626 ----
      container.AddItem(Center(t))
      container.AddItem(Center(TextArea(name='subscribees',
                                        rows=10,cols=60,wrap=None)))
+     t = Table(width="90%")
+     t.AddRow([Center(Header(4, "Mass Remove Members"))])
+     t.AddCellInfo(t.GetCurrentRowIndex(),
+                   t.GetCurrentCellIndex(),
+                   bgcolor="#cccccc", colspan=8)
+     t.AddRow(["Enter one address to remove per line: <p>"])
+     container.AddItem(Center(t))
+     container.AddItem(Center(TextArea(name='unsubscribees',
+                                       rows=10,cols=60,wrap=None)))
      return container
  
  def FormatPasswordStuff():
***************
*** 877,882 ****
--- 886,920 ----
                      dirty = 1
          if unsubscribe_errors:
              document.AddItem(Header(5, "Error Unsubscribing:"))
+             items = map(lambda x: "%s -- %s" % (x[0], x[1]), 
unsubscribe_errors)
+             document.AddItem(apply(UnorderedList, tuple((items))))
+             document.AddItem("<p>")
+ 
+     #
+     # mass unsubscription processing for members category
+     #
+     if cgi_info.has_key('unsubscribees'):
+       name_text = cgi_info['unsubscribees'].value
+         name_text = string.replace(name_text, '\r', '')
+       names = map(string.strip, string.split(name_text, '\n'))
+         unsubscribe_errors = []
+         unsubscribe_success = []
+       for name in names:
+          try:
+             lst.DeleteMember(name)
+          except:
+             unsubscribe_errors.append(name, "No such user")
+          else:
+             unsubscribe_success.append(name)
+ 
+         if unsubscribe_success:
+             document.AddItem(Header(5, "Successfully Unsubscribed:"))
+             document.AddItem(apply(UnorderedList, 
tuple((unsubscribe_success))))
+             document.AddItem("<p>")
+             dirty = 1
+ 
+         if unsubscribe_errors:
+             document.AddItem(Header(5, "Error Unsubscribing:"))
              items = map(lambda x: "%s -- %s" % (x[0], x[1]), 
unsubscribe_errors)
              document.AddItem(apply(UnorderedList, tuple((items))))
              document.AddItem("<p>")


------------------------------------------------------
Mailman-Users maillist  -  Mailman-Users@python.org
http://www.python.org/mailman/listinfo/mailman-users

------------- End Forwarded Message -------------





From chuqui@plaidworks.com  Thu Jun  8 07:04:55 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 7 Jun 2000 23:04:55 -0700
Subject: [Mailman-Developers] an issue with the listinfo/<listname> page...
Message-ID: <p04310101b564e6ca796f@[209.239.169.197]>


I was working upgrading to the latest CVS tonight, and realized 
there's a problem with the list page put up when you go to 
.../listinfo/listname.

that's the URL used when someone wants to access the list or 
subscribe to it, but there's no link there that allows a user to log 
on and change their subscription option. that's a different URL 
(../listinfo/listname/emailaddr) that's sent to them when they 
subscribe, but you can't assume they'll save that (in fact, you can 
guarantee most of them won't), so the user dead-ends trying to get 
into the web site to try to change their options.

There really needs to be a way, both on the listinfo/ page and the 
listinfo/listname page, for an existing subscriber to sign in and get 
to their subscription configuration page. Otherwise, people are going 
to get lost and end up annoying the admin for help...

I'd classify this as a medium to medium-high problem, because it's a 
huge dead end in the interface with a significant number of users 
who'll be looking for it.

chuq
-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jwt@dskk.co.jp  Thu Jun  8 08:20:36 2000
From: jwt@dskk.co.jp (Jim Tittsler)
Date: Thu, 8 Jun 2000 16:20:36 +0900
Subject: [Mailman-Developers] Multilingual support
In-Reply-To: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>; from gpoo@ubiobio.cl on Tue, Jun 06, 2000 at 12:29:52PM -0300
References: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>
Message-ID: <20000608162036.A19873@mail.dskk.co.jp>

On Tue, Jun 06, 2000 at 12:29:52PM -0300, German Poo Caaman~o wrote:
> 
> I've downloaded Mailman-2.0b2 and I'v translated the templates files
> to spanish, but it wasn't enough.  Some web pages appears with
> english and spanish words.
> 
> Are there some language support on mind?   May be, a language file
> where reside all words used on the interface (buttons, messages,
> etc.).

There is a I18n effort with its own mailing list
http://www.python.org/mailman/listinfo/mailman-i18n

I believe the I18n work is essentially on hold until after the basic
features for version 2.0 are complete.

-- 
Jim Tittsler, Tokyo
Python Starship     http://starship.python.net/crew/jwt/



From gorgo@caesar.elte.hu  Thu Jun  8 12:23:00 2000
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Thu, 8 Jun 2000 13:23:00 +0200 (METDST)
Subject: [Mailman-Developers] subscription notification
Message-ID: <Pine.A32.3.96.1000608132202.42066M-100000@caesar.power.elte.hu>

Hello,

I have noticed another change between 1.1 and 2.0beta2... on a closed list
when the list admin approves someones subscription, he doesn't get an
email notification of the subscription

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From gorgo@caesar.elte.hu  Thu Jun  8 13:09:14 2000
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Thu, 8 Jun 2000 14:09:14 +0200 (METDST)
Subject: [Mailman-Developers] subscription notification
In-Reply-To: <Pine.A32.3.96.1000608132202.42066M-100000@caesar.power.elte.hu>
Message-ID: <Pine.A32.3.96.1000608140852.42066Q-100000@caesar.power.elte.hu>

On Thu, 8 Jun 2000, Gergely Madarasz wrote:

> Hello,
> 
> I have noticed another change between 1.1 and 2.0beta2... on a closed list
> when the list admin approves someones subscription, he doesn't get an
> email notification of the subscription

Ah, sorry, the notification arrived, just a bit late... :)

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From ricardo@rixhq.nu  Fri Jun  9 08:16:11 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 9 Jun 2000 09:16:11 +0200
Subject: [Mailman-Developers] userdatabases
Message-ID: <20000609091611.A1188@miss-janet.com>

Hi,

I know this subject has been touched before... but I was wondering if
anybody has yet implemented some system where mailman is used next to
a userdatabase where every subscriber is linked somehow to a user in
that database. There are probably 1001 ways to synchronize mailman
subscribers with an external user database, but the problem is finding
the best solution. At this moment our programmers have several projects
where announce mail lists are going to be needed, but of course
customers want to have more details for every subscriber than just
their email address. I've been pushing them to use mailman and I've been 
successfull so far, but we still haven't come up with a solution for the problem above...

My job-description doesn't officially include programming :) but I'm
willing to invest some of my own time in creating some standard solution
for this which I could contribute back to mailman...

So if anybody has any ideas... please let me know!

Ricardo.

--



From ricardo@rixhq.nu  Sat Jun 10 10:03:49 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 10 Jun 2000 11:03:49 +0200
Subject: [Mailman-Developers] Mass unsubscription
In-Reply-To: <200006080345.UAA03544@utopia.west.sun.com>; from Dan.Mick@West.Sun.COM on Wed, Jun 07, 2000 at 08:45:16PM -0700
References: <200006080345.UAA03544@utopia.west.sun.com>
Message-ID: <20000610110349.B872@miss-janet.com>

On Wed, Jun 07, 2000 at 08:45:16PM -0700, Dan Mick wrote:
> Anyone have any comments?
> Barry/Harald/whoever, as much discussion as this engendered on
> mailman-users, if this looks good, maybe it could get squeezed into
> beta3 (due any second now, right)?

i added something simular to a local copy of mailman a while ago,
but it got lost with updating cvs versions... anyway I personally
think this is a good feature to add -- I know I will be using it...

ps: i notice my posts sometimes don't arrive on the develop list or
are very late... am I'm being victim of the mailman code post restricting
behavior? ;) [now i know how our users feel who keep complaining about
posts arriving late due to the moderating feature LOL]

Ricardo.


From ricardo@rixhq.nu  Sat Jun 10 10:09:01 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 10 Jun 2000 11:09:01 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
In-Reply-To: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>; from andrea@integra-italia.com on Wed, Jun 07, 2000 at 04:21:06PM +0200
References: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>
Message-ID: <20000610110901.C872@miss-janet.com>

On Wed, Jun 07, 2000 at 04:21:06PM +0200, Andrea Paparelli wrote:
> Bug in Mailman version 1.1
>   File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
> CheckCookie
>     if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
> IndexError: string index out of range

I stumbled on this a few times too... but it is very hard to reproduce...
what I think went wrong in my situation most of those times is that somehow
the cookie got mixed up with a different cookie which was set by a different
program at the exact same server as mailman...
anybody had simular experiences?

Ricardo.


From chuqui@plaidworks.com  Sun Jun 11 23:55:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 15:55:00 -0700
Subject: [Mailman-Developers] updating templates..
Message-ID: <p0431010eb569c85c9b4d@[209.239.169.197]>

Been playing with the templates today (or trying to... ), and 
couldn't figure out why updates to the templates weren't showing up 
in the browser. It's because, of course, when a list is created it 
copies templates into the /lists/<listname>/ subdirectory, so changes 
to the /templates subdirectory only work on new lists.

It looks like there's no "update existing lists" makefile or script, either.

I'd suggest that the newlist function create symlinks into the 
templates directory instead of copying the file, so that changes 
automatically propogate to all of the lists, while still allowing 
admins to break the link and create a custom page if they want to. 
Otherwise, updating a site with lots of lists is going to be a royal 
pain if you want to redo the look and feel.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Mon Jun 12 04:33:17 2000
From: jim@cosource.com (Jim Hebert)
Date: Sun, 11 Jun 2000 23:33:17 -0400 (EDT)
Subject: [Mailman-Developers] updating templates..
In-Reply-To: <p0431010eb569c85c9b4d@[209.239.169.197]>
Message-ID: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>

On Sun, 11 Jun 2000, Chuq Von Rospach wrote:

> I'd suggest that the newlist function create symlinks into the 
[...]

When I ran a Smartlist installation in a former life, it did a similar
thing, only it used hardlinks to accomplish the task.

Is there any wisdom in doing one over the other? I don't recall why
smartlist used hardlinks, though something makes me wonder if it wasn't to
satisfy anti-symlink sanity checks, e.g. in procmail.

jim
who probably should just assume that Chuq has already done that
calculation and decided on symlinks =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox



From chuqui@plaidworks.com  Mon Jun 12 04:39:45 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 20:39:45 -0700
Subject: [Mailman-Developers] updating templates..
In-Reply-To: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>
Message-ID: <p04310110b56a0ae43c2b@[209.239.169.197]>

At 11:33 PM -0400 6/11/2000, Jim Hebert wrote:

>When I ran a Smartlist installation in a former life, it did a similar
>thing, only it used hardlinks to accomplish the task.
>
>Is there any wisdom in doing one over the other? I don't recall why
>smartlist used hardlinks,

Not really. I'm sure there are some flavors of unix without symlinks 
in them, but I wouldn't use one. Hard links don't work across 
filesystems. If, for instance, a site wanted to move the 
list/listname folder into a users home directory for access and/or 
quota regulation, symlinks work great, hard links might of might not.

>who probably should just assume that Chuq has already done that
>calculation and decided on symlinks =)

Nah. I just use symlinks unless there's some overriding reason not to.

About the only real advantage of hard links is if someone rm's the 
thing the symlink is pointing to, everyone's copy breaks, but if you 
use hard links, only that instance goes away. On the other hand, what 
happens more often is someone unlinks a copy thinking it's the 
master, changes it,a nd simply breaks the link rather than updating 
all of the copies.

In this case, I chose symlinks because the files aren't next to each 
other, so figuring out what they're linked to is going to be 
impossible with hard links. I hate hard links that aren't in the same 
directory -- but that's a religious issue, not any hard technical one.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 05:17:26 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 21:17:26 -0700
Subject: [Mailman-Developers] updated listinfo.html template...
Message-ID: <p04310111b56a1444700e@[209.239.169.197]>

I've been whacking on this today, and I thought I'd pass off a copy. 
If you want to see this in action, take a quick gander at 
<http://newboy.plaidworks.com/mailman/listinfo/test>

It doesn't include some minor tweaks to the text in HTMLformatter.py, 
but those are fairly minor rewordings. Once I'm done, I'll get the 
whole thing packaged up.

<!-- $Revision: 1.20 $ -->
<HTML>
     <HEAD>
	<TITLE>The <MM-List-Name> Mailing List</TITLE>
     </HEAD>
     <BODY BGCOLOR="#ffffff">
	<table width="100%" border="0" cellpadding="10">
	    <tr><td><A HREF="/"><img src="/images/plaidworks.logo.gif"
		width="168" height="169"></a>
	    </td><td> <img src="/images/mainlogo.gif" width="601" height="124">
	    </td></tr>
	    <tr><td COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC" ALIGN="RIGHT">
		<B>
		<A HREF="/">Home</a> -+-
		<A HREF="/lists">Mailing Lists home</a> -+-
		<A HREF="#About">About <MM-List-Name></a>
		<BR>
		<A HREF="#Subscribe">Subscribe</a> -+-
		<A HREF="#Unsubscribe">Unsubscribe</a> -+-
		<A HREF="#Unsubscribe">Change Subscription</a>
		<BR>
		<A HREF="#Posting">Posting</a> -+-
		<A HREF="#Archives">Archives</a> -+-
		<A HREF="#Subscribers">Subscribers</a>
		</B>
	    </td></tr>
	</table>
	<MM-Subscribe-Form-Start>
	<P>
	<TABLE COLS="2" BORDER="0" CELLSPACING="4" CELLPADDING="5">
	<TR><TD COLSPAN="2" WIDTH="100%" ALIGN="CENTER">
	    <A NAME="About"><B><FONT COLOR="#000000" SIZE="+2"><MM-List-Name>:
	    <MM-List-Description></FONT></B>
	</TD></TR>
	<tr><td colspan="2"><p>&nbsp;
	</td></tr>
	<tr> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <B><FONT COLOR="#000000" SIZE="+1">About The <MM-List-Name>
	    Mailing List</FONT></B>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    <P><MM-List-Info></P>
	</TD></TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Subscribe">
	    <B><FONT COLOR="#000000" SIZE="+1">Subscribing to <MM-List-Name>
	    </FONT></B>
	</TD></TR>
	<tr><td colspan="2">
	    <P>To subscribe to <B><MM-List-Name></B>, fill out this form.
	    <MM-List-Subscription-Msg>
	    <BLOCKQUOTE>
	    <TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2"
		WIDTH="70%" HEIGHT= "112">
		<TR><TD BGCOLOR="#cccccc" WIDTH="55%">Your email address:</TD>
		<TD WIDTH="33%"><MM-Subscribe-Box></TD>
		<TD WIDTH="12%">&nbsp;</TD></TR><TR>
		<TD COLSPAN="3">
		    <BLOCKQUOTE>
		    You must enter a privacy
		    password. This provides only mild security, but should
		    prevent others from modifying your subscription.  <b>Do
		    not use the password to your account</b>. Use something
		    you will remember, but which won't give someone access to
		    your accounts if they somehow get their hands on it.
		    <MM-Reminder>
		    </BLOCKQUOTE>
		</TD></TR>
		<TR><TD BGCOLOR="#cccccc">Pick a password:</TD>
		<TD><MM-New-Password-Box></TD>
		<TD>&nbsp;</TD></TR>
		<TR> <TD BGCOLOR="#cccccc">Re-enter password to confirm:</TD>
		<TD><MM-Confirm-Password></TD>
		<TD>&nbsp; </TD></TR>
		<tr><td>Would you like to receive list mail batched in a daily
		    digest?
		</td><td><MM-Undigest-Radio-Button> No
		    <MM-Digest-Radio-Button>  Yes
		</TD></tr>
		<tr><td colspan="3">
		    <center><MM-Subscribe-Button></P></center>
		</TD></tr>
	    </TABLE>
	    <MM-Form-End>
	    </BLOCKQUOTE>
	    </td></tr>
	    <TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
		<a name="Unsubscribe">
		<B><FONT COLOR="#000000" SIZE="+1">Unsubscribe and Change
		    Subscription Options</FONT></B>
	    </TD></TR>
	    <TR><TD COLSPAN="2" WIDTH="100%">
		<MM-Subscribe-Form-Start>
		<MM-Editing-Options>
		<MM-Form-End>
	    </td></tr>
	</TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Posting">
	    <B><FONT COLOR="#000000" <FONT SIZE="+1">Posting to
		<MM-List-Name></FONT></B>
	</TD></TR>
	<tr><td colspan="2">
	    To post a message to all the list members, send email to
	    <A HREF="mailto:<MM-Posting-Addr>"><MM-Posting-Addr></A>.
	</td></tr>
	<tr><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Archives">
	    <B><FONT COLOR="#000000" SIZE="+1"><MM-List-Name> Archives
	    </FONT></B>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    To see the collection of prior postings to the list,
	    visit the <MM-Archive><MM-List-Name> Archives</MM-Archive>.
	    <MM-Restricted-List-Message>
	</TD></TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <a name="Subscribers">
	    <B><FONT COLOR="#000000" SIZE = "+1">
	    <MM-List-Name> Subscribers</FONT></B></a>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    <MM-Roster-Form-Start>
	    <MM-Roster-Option>
	    <MM-Form-End>
	    <p>
	</TD></TR>
     </table>
     <MM-Mailman-Footer>
</BODY>
</HTML>

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 05:26:13 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 21:26:13 -0700
Subject: [Mailman-Developers] dead pipermail link
Message-ID: <p04310112b56a16af0185@[209.239.169.197]>

the link generated by pipermail in the archives to the pipermail site 
is dead....

<http://starship.skyport.net/crew/amk/maintained/pipermail.html> no 
longer exists.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 06:15:08 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 22:15:08 -0700
Subject: [Mailman-Developers] GetRelativeScriptURL problem
Message-ID: <p04310113b56a218c8eca@[209.239.169.197]>

--============_-1251335476==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"


There's a problem with GetRelativeScriptURL. If you go to

..mailman/listinfo/<listname> and from there, go into the edit 
options page, on that page, (..mailman/subscribe/<listname>), the 
link at the bottom of the page back to <listname> is wrong. 
GetRelativeScriptURL generates

<hr><address><a href="../../listinfo/test">Test</a> list run by

which is incorrect. It really ought to be ../listinfo/test

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"
--============_-1251335476==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>GetRelativeScriptURL problem</title></head><body>
<div><br></div>
<div>There's a problem with GetRelativeScriptURL. If you go to</div>
<div><br></div>
<div>..mailman/listinfo/&lt;listname&gt; and from there, go into the
edit options page, on that page,
(..mailman/subscribe/&lt;listname&gt;), the link at the bottom of the
page back to &lt;listname&gt; is wrong. GetRelativeScriptURL
generates</div>
<div><br></div>
<div><font face="Monaco" color="#000000">&lt;</font><font
face="Monaco" color="#0000FF">hr</font><font face="Monaco"
color="#000000">&gt;&lt;</font><font face="Monaco"
color="#0000FF">address</font><font face="Monaco"
color="#000000">&gt;&lt;</font><font face="Monaco"
color="#0000FF">a</font><font face="Monaco" color="#000000">
href=&quot;../../listinfo/test&quot;&gt;Test&lt;</font><font
face="Monaco" color="#0000FF">/a</font><font face="Monaco"
color="#000000">&gt; list run by</font></div>
<div><font face="Monaco" color="#000000"><br></font></div>
<div><font face="Monaco" color="#000000">which is incorrect. It
really ought to be ../listinfo/test</font></div>
<div><font face="Monaco" color="#000000"><br></font></div>

<div>-- <br>
Chuq Von Rospach - Plaidworks Consulting
(mailto:chuqui@plaidworks.com) <br>
Apple Mail List Gnome (mailto:chuq@apple.com) <br>
<br>
And they sit at the bar and put bread in my jar<br>
and say 'Man, what are you doing here?'&quot;</div>
</body>
</html>
--============_-1251335476==_ma============--


From dan@feld.cvut.cz  Mon Jun 12 17:09:26 2000
From: dan@feld.cvut.cz (Dan Ohnesorg)
Date: Mon, 12 Jun 2000 18:09:26 +0200 (CEST)
Subject: [Mailman-Developers] using https for admin purposes
Message-ID: <Pine.LNX.4.21.0006121734490.27940-200000@poli.feld.cvut.cz>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--546564545-459075905-960824974=:27940
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0006121807381.27940@poli.feld.cvut.cz>

I have tried last CVS version and I have find some bug, which was also in
1.x version too. The admin.py (and other) uses for members addresses
formating function:

mlist.GetAbsoluteOptionsURL(member, obscure=1)

which will use http://, when it is set in list options. I think it will be
match better to use GetOptionsURL(...relative=1), becouse it is legal to
use http for users and https for admins.

Patch which makes this is attached. It will be possible to switch https X
https according to enviroment created by webserver, but I think, so it is
good enought.

cheers
dan


-- 
                    ________________________________________
DDDDDD             
DD   DD                Dan Ohnesorg, supervisor on POWER     
DD  OOOO               Dan@feld.cvut.cz
DD OODDOO              Dep. of Power Engineering
DDDDDD OO              CTU FEL Prague, Bohemia
   OO  OO              work: +420 2 24352785;+420 2 24972109
    OOOO               home: +420 311 679679;+420 311 679311
                    ________________________________________

Nejztracenejsi den naseho zivota
je ten, kdy jsme se nezasmali.

--546564545-459075905-960824974=:27940
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman.https.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0006121809260.27940@poli.feld.cvut.cz>
Content-Description: 
Content-Disposition: attachment; filename="mailman.https.patch"

ZGlmZiAtdXIgbWFpbG1hbjIub2xkL01haWxtYW4vQ2dpL2FkbWluLnB5IG1h
aWxtYW4yL01haWxtYW4vQ2dpL2FkbWluLnB5DQotLS0gbWFpbG1hbjIub2xk
L01haWxtYW4vQ2dpL2FkbWluLnB5CU1vbiBKdW4gMTIgMTY6NTg6MTIgMjAw
MA0KKysrIG1haWxtYW4yL01haWxtYW4vQ2dpL2FkbWluLnB5CU1vbiBKdW4g
MTIgMTc6NDI6MjAgMjAwMA0KQEAgLTU3MSw3ICs1NzEsNyBAQA0KICAgICAg
ICAgYnV0dG9ucyA9IFtdDQogICAgICAgICBmb3IgY2kgaW4gY2h1bmtfaW5k
aWNlczoNCiAgICAgICAgICAgICBzdGFydCwgZW5kID0gY2h1bmtzW2NpXVsw
XSwgY2h1bmtzW2NpXVstMV0NCi0JICAgIHVybCA9IG1saXN0LkdldEFic29s
dXRlU2NyaXB0VVJMKCdhZG1pbicpDQorCSAgICB1cmwgPSBtbGlzdC5HZXRT
Y3JpcHRVUkwoJ2FkbWluJywgcmVsYXRpdmU9MSkNCiAgICAgICAgICAgICBi
dXR0b25zLmFwcGVuZCgiPGEgaHJlZj0lcy9tZW1iZXJzP2NodW5rPSVkPiBm
cm9tICVzIHRvICVzIDwvYT4iDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJSAoIHVybCwgIGNpLCBzdGFydCwgZW5kKSkNCiAgICAgICAgIGJ1dHRv
bnMgPSBhcHBseShVbm9yZGVyZWRMaXN0LCB0dXBsZShidXR0b25zKSkNCkBA
IC01ODEsNyArNTgxLDcgQEANCiAgICAgICAgIGZvb3RlciA9ICI8cD4iDQog
ICAgIGZvciBtZW1iZXIgaW4gYWxsOg0KICAgICAgICAgbXRleHQgPSAnPGEg
aHJlZj0iJXMiPiVzPC9hPicgJSAoDQotICAgICAgICAgICAgbWxpc3QuR2V0
QWJzb2x1dGVPcHRpb25zVVJMKG1lbWJlciwgb2JzY3VyZT0xKSwNCisgICAg
ICAgICAgICBtbGlzdC5HZXRPcHRpb25zVVJMKG1lbWJlciwgb2JzY3VyZT0x
LCByZWxhdGl2ZT0xKSwNCiAgICAgICAgICAgICBtbGlzdC5HZXRVc2VyU3Vi
c2NyaWJlZEFkZHJlc3MobWVtYmVyKSkNCiAgICAgICAgIGNlbGxzID0gW210
ZXh0ICsgIjxpbnB1dCB0eXBlPWhpZGRlbiBuYW1lPXVzZXIgdmFsdWU9JXM+
IiAlIChtZW1iZXIpLA0KICAgICAgICAgICAgICAgICAgQ2VudGVyKENoZWNr
Qm94KG1lbWJlciArICJfc3Vic2NyaWJlZCIsICJvbiIsIDEpLkZvcm1hdCgp
KV0NCmRpZmYgLXVyIG1haWxtYW4yLm9sZC9NYWlsbWFuL0NnaS9oYW5kbGVf
b3B0cy5weSBtYWlsbWFuMi9NYWlsbWFuL0NnaS9oYW5kbGVfb3B0cy5weQ0K
LS0tIG1haWxtYW4yLm9sZC9NYWlsbWFuL0NnaS9oYW5kbGVfb3B0cy5weQlN
b24gSnVuIDEyIDE2OjU4OjEyIDIwMDANCisrKyBtYWlsbWFuMi9NYWlsbWFu
L0NnaS9oYW5kbGVfb3B0cy5weQlNb24gSnVuIDEyIDE3OjQ2OjA0IDIwMDAN
CkBAIC0xNjIsNyArMTYyLDcgQEANCiAgICAgICAgICAgICAgICAgICAgIGFk
ZHIgPSBVdGlscy5PYnNjdXJlRW1haWwoYWRkcnNbMF0pDQogICAgICAgICAg
ICAgICAgICAgICBpZiBtbGlzdC5vYnNjdXJlX2FkZHJlc3NlczoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICBhZGRyID0gVXRpbHMuT2JzY3VyZUVtYWls
KGFkZHIpDQotICAgICAgICAgICAgICAgICAgICB1cmwgPSBtbGlzdC5HZXRB
YnNvbHV0ZU9wdGlvbnNVUkwoYWRkcikNCisgICAgICAgICAgICAgICAgICAg
IHVybCA9IG1saXN0LkdldE9wdGlvbnNVUkwoYWRkciwgcmVsYXRpdmU9MSkN
CiAgICAgICAgICAgICAgICAgICAgIGxpbmsgPSBMaW5rKHVybCwgbWxpc3Qu
cmVhbF9uYW1lKQ0KICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIG1saXN0
LmludGVybmFsX25hbWUoKSwgbGluaw0KIA0KZGlmZiAtdXIgbWFpbG1hbjIu
b2xkL01haWxtYW4vSFRNTEZvcm1hdHRlci5weSBtYWlsbWFuMi9NYWlsbWFu
L0hUTUxGb3JtYXR0ZXIucHkNCi0tLSBtYWlsbWFuMi5vbGQvTWFpbG1hbi9I
VE1MRm9ybWF0dGVyLnB5CU1vbiBKdW4gMTIgMTY6NTg6MTIgMjAwMA0KKysr
IG1haWxtYW4yL01haWxtYW4vSFRNTEZvcm1hdHRlci5weQlNb24gSnVuIDEy
IDE4OjA0OjAxIDIwMDANCkBAIC0yOTksNyArMjk5LDcgQEANCiAgICAgICAg
IHJldHVybiBjb250YWluZXINCiANCiAgICAgZGVmIEZvcm1hdEZvcm1TdGFy
dChzZWxmLCBuYW1lLCBleHRyYT0nJyk6DQotCWJhc2VfdXJsID0gc2VsZi5H
ZXRBYnNvbHV0ZVNjcmlwdFVSTChuYW1lKQ0KKwliYXNlX3VybCA9IHNlbGYu
R2V0U2NyaXB0VVJMKG5hbWUsIHJlbGF0aXZlPTEpDQogICAgICAgICBpZiBl
eHRyYToNCiAgICAgICAgICAgICBmdWxsX3VybCA9ICIlcy8lcyIgJSAoYmFz
ZV91cmwsIGV4dHJhKQ0KICAgICAgICAgZWxzZToNCg==
--546564545-459075905-960824974=:27940--


From Harald.Meland@usit.uio.no  Mon Jun 12 17:28:29 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 12 Jun 2000 18:28:29 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
In-Reply-To: Ricardo Kustner's message of "Sat, 10 Jun 2000 11:09:01 +0200"
References: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>
 <20000610110901.C872@miss-janet.com>
Message-ID: <d6daegqn9si.fsf@octarine.uio.no>

[Ricardo Kustner]

> On Wed, Jun 07, 2000 at 04:21:06PM +0200, Andrea Paparelli wrote:
> > Bug in Mailman version 1.1
> >   File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
> > CheckCookie
> >     if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
> > IndexError: string index out of range
> 
> I stumbled on this a few times too... but it is very hard to reproduce...
> what I think went wrong in my situation most of those times is that somehow
> the cookie got mixed up with a different cookie which was set by a different
> program at the exact same server as mailman...
> anybody had simular experiences?

I haven't seen this happen with my users, but as the offending piece
of code indeed is a hack that won't work reliably if the browser sends
multiple cookies, I think this should be addressed somehow.

The real problem, I think, is that there's confusion on the subject of
cookie content syntax.

The original Netscape proposal uses this (not very well-defined, IMO)
cookie content syntax:

: NAME=VALUE
:      This string is a sequence of characters excluding semi-colon,
:      comma and white space. If there is a need to place such data in
:      the name or value, some encoding method such as URL style %XX
:      encoding is recommended, though no encoding is defined or
:      required.

A quick example:
[ Server -> Client ]
  Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

[ Client -> Server ]
  Cookie: CUSTOMER=WILE_E_COYOTE

Note that there are no quotes around the cookie value.


RFC 2109, however, has a more well-defined, but ever so slightly
different content syntax:

: 4.1  Syntax:  General
: 
:    The two state management headers, Set-Cookie and Cookie, have common
:    syntactic properties involving attribute-value pairs.  The following
:    grammar uses the notation, and tokens DIGIT (decimal digits) and
:    token (informally, a sequence of non-special, non-white space
:    characters) from the HTTP/1.1 specification [RFC 2068] to describe
:    their syntax.
: 
:    av-pairs        =       av-pair *(";" av-pair)
:    av-pair         =       attr ["=" value]        ; optional value
:    attr            =       token
:    value           =       word
:    word            =       token | quoted-string

Note that the cookies value can be a quoted-string.  The example from
the Netscape spec could look like this using the RFC syntax:

[ Server -> Client ]
  Set-Cookie: CUSTOMER="WILE_E_COYOTE"; Version="1"; Path="/"; Max-Age="3600"

[ Client -> Server ]
  Cookie: $Version="1"; CUSTOMER="WILE_E_COYOTE"; $Path="/"


(Some time back) I looked over misc/Cookie.py trying to find some way
to make it cope reliably with both kinds of cookies, but wasn't really
able to discover what's wrong with _CookiePattern :(

I suspect that using "Max-Age" attributes on Mailman cookies instead
of the current (non-RFC) "Expires" attribute *might* help, but I
really don't have any idea whether such a change will stop Mailman
from working with certain browsers.
-- 
Harald


From jmackenzie@local.ie  Tue Jun 13 12:05:32 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Tue, 13 Jun 2000 12:05:32 +0100
Subject: [Mailman-Developers] Issue with one List, Upgraded To 2.0 last friday
Message-ID: <00061312070500.01462@samsara.local.ie>

Hey guys, 

I've got an issue with A Mailman list I'm running, it worked fine until the
upgrade. 

I Attached the bug report it generated... Any ideas ?

Bug in Mailman version 2.0beta2

We're sorry, we hit a bug!

If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! 

Traceback:

Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 89, in run_main
    main()
  File "/home/mailman/Mailman/Cgi/admindb.py", line 125, in main
    mlist.Save()
  File "/home/mailman/Mailman/MailList.py", line 853, in Save
    self.SaveRequestsDb()
  File "/home/mailman/Mailman/ListAdmin.py", line 89, in SaveRequestsDb
    self.__closedb()
  File "/home/mailman/Mailman/ListAdmin.py", line 73, in __closedb
    assert self.Locked()
AssertionError: 





Python information:

     Variable
                                               Value
 sys.version
                 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- 
 sys.executable
                 /usr/bin/python 
 sys.prefix
                 /usr 
 sys.exec_prefix
                 /usr 
 sys.path
                 /usr 
 sys.platform
                 linux-i386 




Environment variables:

        Variable
                                                                                        Value
 DOCUMENT_ROOT 
                       /www/local-ireland/db/dbwww 
 SERVER_ADDR 
                       159.134.244.165 
 HTTP_ACCEPT_ENCODING 
                       gzip 
 REMOTE_HOST 
                       server01.merrion.nua.net 
 CONTENT_TYPE 
                       application/x-www-form-urlencoded 
 PATH_TRANSLATED 
                       /www/local-ireland/db/dbwww/local-ancestors 
 REMOTE_ADDR 
                       195.7.46.71 
 SERVER_SOFTWARE 
                       Apache/1.3.9 (Unix) (Red Hat/Linux) 
 GATEWAY_INTERFACE 
                       CGI/1.1 
 HTTP_COOKIE 
                       local-ancestors:admin="(lp1\012F960892961.80800498\012aI960903761\012aS'\\317bjG\\352\\010qA\\014`\\024\\3360\\374\\325\\211'\012p2\012a.";
                       RMID=c3072e4738e8aa90; Apache=server01.merrion.nua.net.21641958579664595 
 HTTP_ACCEPT_LANGUAGE 
                       en 
 REMOTE_PORT 
                       1240 
 SERVER_PORT 
                       80 
 HTTP_CONNECTION 
                       Keep-Alive 
 HTTP_USER_AGENT 
                       Mozilla/4.7 [en] (X11; I; Linux 2.2.12-20 i686) 
 HTTP_ACCEPT_CHARSET 
                       iso-8859-1,*,utf-8 
 HTTP_ACCEPT 
                       image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* 
 REQUEST_URI 
                       /mailman/admindb/local-ancestors 
 PATH 
                       /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin 
 QUERY_STRING 
 SERVER_PROTOCOL 
                       HTTP/1.0 
 CONTENT_LENGTH 
                       5447 
 HTTP_HOST 
                       www.local.ie 
 REQUEST_METHOD 
                       POST 
 SERVER_SIGNATURE 
 SCRIPT_NAME 
                       /mailman/admindb 
 SERVER_ADMIN 
                       webmaster@local.ie 
 SCRIPT_FILENAME 
                       /home/mailman/cgi-bin/admindb 
 PYTHONPATH 
                       /home/mailman 
 PATH_INFO 
                       /local-ancestors 
 HTTP_REFERER 
                       http://www.local.ie/mailman/admindb/local-ancestors 
 SERVER_NAME 
                       www.local.ie 


From jmackenzie@local.ie  Tue Jun 13 12:17:13 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Tue, 13 Jun 2000 12:17:13 +0100
Subject: [Mailman-Developers] Issue with one List, Upgraded To 2.0 last friday
In-Reply-To: <00061312070500.01462@samsara.local.ie>
References: <00061312070500.01462@samsara.local.ie>
Message-ID: <00061312161401.01462@samsara.local.ie>

I stupidly forgot to mention that this occured while i was attempting to
approve a Mail to the list. If I discard it It works as it normally would. 

Regards
- john


On Tue, 13 Jun 2000, you wrote:
> Hey guys, 
> 
> I've got an issue with A Mailman list I'm running, it worked fine until the
> upgrade. 
<snip>


From bwarsaw@python.org  Wed Jun 14 05:57:48 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 00:57:48 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
 <d6d4s79du5t.fsf@octarine.uio.no>
Message-ID: <14663.4300.188254.867225@anthem.concentric.net>

    HM> I still don't see why there's a need for the "intermediate"
    HM> state (neither fully locked nor fully unlocked) with the
    HM> shared lockfile having a link count of 1.  I think it just
    HM> makes the locking logic more complicated to understand.

You've convinced me.  I'm about to check in a bunch of changes,
including some to LockFile.py in which I've basically installed your
patch.  The one thing I'm not sure about is removing the try/except
around the unlink of winner -- I think there's still a race condition
where winner could be non-empty but the unlink could fail.  The
try/except shouldn't hurt so I'm leaving that one thing in.

    HM> The other method that currently unlinks the shared lockfile is
    HM> __break().  The purpose of that method is to remove lockfiles
    HM> that some other process has failed to release within the
    HM> lock's lifetime.  Thus, this method breaks the invariant you
    HM> mention *by design*.

I think __break() is fundamentally broken.  Actually, I think breaking
locks gets us into all kinds of problems.  But there's the trade-off
of deadlocking the whole system for something we haven't thought
about.

One approach might be to never break locks implicitly, but have
qrunner (which now runs every minute) check for long-dead locks and
send warning emails to the site admin.  A simple rm should clear up
the problem.

As an interim approach, I'm just cranking up the qrunner and list lock
lifetimes to really big numbers (like 10 hours and 5 hours
respectively).  Hopefully, in conjunction with some other soon to be
checked in changes, this will help many of the problems that I think
are premature-lock-breaking related.

All this is just whacked anyway.  What we really need is a
transactional database underneath so we wouldn't need all these stupid
list locks.  I still believe that's too much work for 2.0, but as this
beta3 drags on, I'm starting to have doubts.

-Barry


From dgc@uchicago.edu  Wed Jun 14 06:31:14 2000
From: dgc@uchicago.edu (David Champion)
Date: Wed, 14 Jun 2000 00:31:14 -0500
Subject: [Mailman-Developers] rmlist bug?
Message-ID: <20000614003114.A7685@smack.uchicago.edu>

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Sorry if this has come up before; I didn't see it.

rmlist has what would appear to be a bug: it doesn't care where you
keep your lists, but the Mailman configuration allows you to keep them
outside the tree that Mailman itself lives in.  This patch against
current CVS repairs.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rmlist.patch"

Index: bin/rmlist
===================================================================
RCS file: /cvsroot/mailman/mailman/bin/rmlist,v
retrieving revision 1.12
diff -u -r1.12 rmlist
--- bin/rmlist	2000/03/21 06:26:18	1.12
+++ bin/rmlist	2000/06/14 05:27:28
@@ -40,6 +40,8 @@
 import getopt
 import paths
 
+from Mailman import Defaults
+
 def usage(status, msg=''):
     print __doc__ % globals()
     if msg:
@@ -93,7 +95,7 @@
     REMOVABLES.append(('locks/%s.lock', 'lock file'))
 
     for dirtmpl, msg in REMOVABLES:
-        dir = os.path.join(paths.prefix, dirtmpl % listname)
+        dir = os.path.join(Defaults.DATA_PREFIX, dirtmpl % listname)
         remove_it(listname, dir, msg)
 
 

--7JfCtLOvnd9MIVvH--


From hniksic@iskon.hr  Wed Jun 14 09:28:22 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 10:28:22 +0200
Subject: [Mailman-Developers] Mailman version
Message-ID: <dpaegowtsp.fsf@mraz.iskon.hr>

Hi!

After a long period of pondering, my company is scheduling the move
from majordomo to mailman for mailing list management.

A quick question: I notice that mailman is currently in 2.0-beta, and
that beta2 was released in April.  How stable is that beta?  I
wouldn't like the majordomo->mailman migration pain to be followed by
a 1.x->2.0 upgrade pain.

What do the developers recommend?


From Nigel.Metheringham@VData.co.uk  Wed Jun 14 09:45:28 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Wed, 14 Jun 2000 09:45:28 +0100
Subject: [Mailman-Developers] Mailman version
In-Reply-To: Message from Hrvoje Niksic <hniksic@iskon.hr>
 of "14 Jun 2000 10:28:22 +0200." <dpaegowtsp.fsf@mraz.iskon.hr>
Message-ID: <E1328ng-0000ft-00@rioja.localnet>

hniksic@iskon.hr said:
> A quick question: I notice that mailman is currently in 2.0-beta, and
> that beta2 was released in April.  How stable is that beta?  I
> wouldn't like the majordomo->mailman migration pain to be followed by
> a 1.x->2.0 upgrade pain. 

The beta is *very* stable - as far as I can see, although there are a 
few minor bugs that I can think of, specifically:-

  - messages that go through the approval pipeline do not
    get correctly archived.
    Patches are at http://sourceforge.net/patch/download.php?id=100416
    and http://sourceforge.net/patch/download.php?id=100417
    [looks like both are needed]

  - archiving timezone date oddities (only affects weekly archived lists
    in particular timezones).  Theres a one line patch of mine for that
    somewhere on the dev list and also in the www.list.org bug db

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Harald.Meland@usit.uio.no  Wed Jun 14 13:10:18 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 14 Jun 2000 14:10:18 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: bwarsaw@python.org's message of "Wed, 14 Jun 2000 00:57:48 -0400 (EDT)"
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
 <d6d4s79du5t.fsf@octarine.uio.no>
 <14663.4300.188254.867225@anthem.concentric.net>
Message-ID: <d6dhfawpiol.fsf@octarine.uio.no>

[Barry A. Warsaw]

> I think __break() is fundamentally broken.  Actually, I think
> breaking locks gets us into all kinds of problems.

I completely agree.  However:

> But there's the trade-off of deadlocking the whole system for
> something we haven't thought about.

That is one rather humongously-sized "but".  [ Do not read the
previous sentence out loud to your wife/girlfriend ;) ]

> One approach might be to never break locks implicitly, but have
> qrunner (which now runs every minute) check for long-dead locks and
> send warning emails to the site admin.  A simple rm should clear up
> the problem.

My gut feeling says that this would be too cumbersome.  The problem
with breaking a lock is that it introduces race conditions; and by
having human admins break the lock "by hand", all you really gain is a
reduced probability that two or more admins will (try to) break the
same lock (nearly) simultaneously -- meaning that all but the first
admin really break non-stale locks.

As long as we do locking by use of the file system, I think there
_has_ to be some way to break stale locks.  Furthermore, I don't think
it's possible to make the method for breaking these locks *completely*
free of race conditions.

I think that our focus should therefore be on reducing the
probabilities of

  a) the occurance of stale locks and
  b) multiple lock breakages in quick succession, as this could
     possibly lead to fresh, non-stale locks being broken.

I would vastly prefer reducing the probability of breaking non-stale
lock by automated means, e.g. by introducing (relatively) large
sleep()s in appropriate places.



Oh, hang on: I just realized that I might have misunderstood what
you're suggesting.  If you meant that there should only be *one*
process which is allowed to break locks, then I agree.  

Of course, there is a catch-22 inside that: The way of ensuring that
there is only *one* instance of that process running, is to do obtain
some lock...

> As an interim approach, I'm just cranking up the qrunner and list
> lock lifetimes to really big numbers (like 10 hours and 5 hours
> respectively).

Ouch.  I do agree with you, though.

> All this is just whacked anyway.  What we really need is a
> transactional database underneath so we wouldn't need all these
> stupid list locks.  I still believe that's too much work for 2.0,
> but as this beta3 drags on, I'm starting to have doubts.

Ummm, by saying "transactional" you're ruling out mysql, right?  I
think I read somewhere that the lack of "transactions" was the main
thing separating mysql from other DBMSes.

As Mailman is GNU software, I'm wondering which free transactional
DBMS(es) Mailman could (or should :) live on top of.
-- 
Harald


From hniksic@iskon.hr  Wed Jun 14 14:12:12 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 15:12:12 +0200
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
Message-ID: <dpk8fstnir.fsf@mraz.iskon.hr>

How is one supposed to create a mailing list on a different virtual
domain?

For instance, say my company `foo' normally runs mailman on `foo.net'.
Now our `bar' clients need a mailing list on `bar.net', which we also
host (and relay mail for.)

Of course, we could set things up so that mail that arrives to
<LIST@bar.net> be delivered to the right place, but Mailman responses
will still appear coming from foo.net.

Mailman README says that Mailman supports virtual domains.  So how is
one supposed to set them up?

Any help, or pointers to help, will be much appreciated.


From stu@ekins.net  Wed Jun 14 14:56:34 2000
From: stu@ekins.net (Stu Ekins)
Date: Wed, 14 Jun 2000 14:56:34 +0100
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
In-Reply-To: <dpk8fstnir.fsf@mraz.iskon.hr>
Message-ID: <BJEKLFPEBALNOFGGKCJACECDCAAA.stu@ekins.net>

Mailman has an option in the list admin pages, which says something like
"domain name this list prefers". Specify "bar.net" in here, and bob should
be your mother's brother...

-----Original Message-----
From: mailman-developers-admin@python.org
[mailto:mailman-developers-admin@python.org]On Behalf Of Hrvoje Niksic
Sent: 14 June 2000 14:12
To: Mailman Developers
Subject: [Mailman-Developers] Virtual hosts/domains in mailman


How is one supposed to create a mailing list on a different virtual
domain?

<rest snipped>



From bwarsaw@python.org  Wed Jun 14 15:46:09 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 10:46:09 -0400 (EDT)
Subject: [Mailman-Developers] Mailman version
References: <dpaegowtsp.fsf@mraz.iskon.hr>
Message-ID: <14663.39601.308077.84506@anthem.concentric.net>

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

    Hrvoje> After a long period of pondering, my company is scheduling
    Hrvoje> the move from majordomo to mailman for mailing list
    Hrvoje> management.

    Hrvoje> A quick question: I notice that mailman is currently in
    Hrvoje> 2.0-beta, and that beta2 was released in April.  How
    Hrvoje> stable is that beta?  I wouldn't like the
    Hrvoje> majordomo->mailman migration pain to be followed by a
    Hrvoje> 1.x->2.0 upgrade pain.

    Hrvoje> What do the developers recommend?

I don't recommend upgrading to 2.0beta2.  Beta3 should be out RSN.

-Barry


From hniksic@iskon.hr  Wed Jun 14 15:49:02 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 16:49:02 +0200
Subject: [Mailman-Developers] Mailman version
In-Reply-To: bwarsaw@python.org's message of "Wed, 14 Jun 2000 10:46:09 -0400 (EDT)"
References: <dpaegowtsp.fsf@mraz.iskon.hr>
 <14663.39601.308077.84506@anthem.concentric.net>
Message-ID: <dpd7lktj1d.fsf@mraz.iskon.hr>

bwarsaw@python.org (Barry A. Warsaw) writes:

> I don't recommend upgrading to 2.0beta2.

I'm not running Mailman at all right now: the question is not whether
to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
2.0beta3 is out.  Or to install the latest stable 1.x version.


From lm@bitmover.com  Wed Jun 14 15:51:29 2000
From: lm@bitmover.com (Larry McVoy)
Date: Wed, 14 Jun 2000 07:51:29 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: <dpd7lktj1d.fsf@mraz.iskon.hr>
References: <dpaegowtsp.fsf@mraz.iskon.hr> <14663.39601.308077.84506@anthem.concentric.net> <dpd7lktj1d.fsf@mraz.iskon.hr>
Message-ID: <20000614075129.E3397@work.bitmover.com>

1.x is pretty cool; I'm not a developer, JC just dragged me into mailman
and I must say I am very impressed (I believe that I sent JC mail saying
"this is better than BitKeeper" so that should give you some idea of
how much I like it).  

I don't think you can go wrong with using 1.x for now, it's very functional.

On Wed, Jun 14, 2000 at 04:49:02PM +0200, Hrvoje Niksic wrote:
> bwarsaw@python.org (Barry A. Warsaw) writes:
> 
> > I don't recommend upgrading to 2.0beta2.
> 
> I'm not running Mailman at all right now: the question is not whether
> to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
> 2.0beta3 is out.  Or to install the latest stable 1.x version.
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers

-- 
---
Larry McVoy            	   lm@bitmover.com           http://www.bitmover.com/lm 


From chuqui@plaidworks.com  Wed Jun 14 16:30:43 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 08:30:43 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: <dpd7lktj1d.fsf@mraz.iskon.hr>
References: <dpaegowtsp.fsf@mraz.iskon.hr>
 <14663.39601.308077.84506@anthem.concentric.net>
 <dpd7lktj1d.fsf@mraz.iskon.hr>
Message-ID: <p04310103b56d5585f11b@[209.239.169.197]>

At 4:49 PM +0200 6/14/2000, Hrvoje Niksic wrote:

>I'm not running Mailman at all right now: the question is not whether
>to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
>2.0beta3 is out.  Or to install the latest stable 1.x version.

Install to the latest CVS versions of not-quite-2.0b3

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From ajohnson@mail.xperts.com  Wed Jun 14 18:06:51 2000
From: ajohnson@mail.xperts.com (Johnson, April)
Date: Wed, 14 Jun 2000 13:06:51 -0400
Subject: [Mailman-Developers] HTML-formatted email
Message-ID: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>

We've done a test implementation of Mailman, but we're really looking for
the list manager to be "happy" with HTML-formatted email. Are there any
patches or add-ons that address this issue? If so, where can we find them?

April Johnson
Xperts, Inc.
(804) 967-0700 x174
http://www.xperts.com
http://www.xperts.org




From chuqui@plaidworks.com  Wed Jun 14 18:10:47 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 10:10:47 -0700
Subject: [Mailman-Developers] HTML-formatted email
In-Reply-To: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>
References: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>
Message-ID: <p04310102b56d6cf0f837@[17.216.27.193]>

At 1:06 PM -0400 6/14/2000, Johnson, April wrote:
>We've done a test implementation of Mailman, but we're really looking for
>the list manager to be "happy" with HTML-formatted email. Are there any
>patches or add-ons that address this issue? If so, where can we find them?

which version of mailman?

Version 2.0b2-3 works fine with MIME, we've been experimenting with 
it heavily. or are you expecting mailman to process email commands 
embedded in HTML?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From claw@kanga.nu  Wed Jun 14 18:38:00 2000
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 14 Jun 2000 10:38:00 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: Message from Larry McVoy <lm@bitmover.com>
 of "Wed, 14 Jun 2000 07:51:29 PDT." <20000614075129.E3397@work.bitmover.com>
References: <dpaegowtsp.fsf@mraz.iskon.hr> <14663.39601.308077.84506@anthem.concentric.net> <dpd7lktj1d.fsf@mraz.iskon.hr>  <20000614075129.E3397@work.bitmover.com>
Message-ID: <12917.961004280@kanga.nu>

On Wed, 14 Jun 2000 07:51:29 -0700 
Larry McVoy <lm@bitmover.com> wrote:

> 1.x is pretty cool; I'm not a developer, JC just dragged me into
> mailman and I must say I am very impressed (I believe that I sent
> JC mail saying "this is better than BitKeeper" so that should give
> you some idea of how much I like it).

Nice to see you here again Larry.

> I don't think you can go wrong with using 1.x for now, it's very
> functional.

I've been playing, very softly, with 2.0*.  My take: 1.1 works, I
like it, I use it.  2.0* works better (eg far better bounce message
parsing) but has a number of fragile corners.  If you never hit
those corners, of course, you'll never care.  OTOH we don't know
where all the corners are yet.  I don't feel that 2.0* has been hit
hard enough to be relied on for a production system as shown by the
rate of reported bugs.

Given that a concern for production systems is that rolling to
versions of installed software is painful, I don't see that going to
2.0* right now is worth it.  In a few weeks/months you are going to
have to upgrade to the full 2.x release anyway, just as you would
from 1.1.  Yes, the delta will be a little smaller, but that's
hardly a big concern when most of the pain centers on rolling the
version in the first place.

For production systems, go with 1.1.  Its not as wonderful as 2.0*,
but it does work, and quite well to boot.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From rob_mm@hotmail.com  Wed Jun 14 20:02:02 2000
From: rob_mm@hotmail.com (Robert mm)
Date: Wed, 14 Jun 2000 15:02:02 EDT
Subject: [Mailman-Developers] integration with other databases?
Message-ID: <20000614190202.16597.qmail@hotmail.com>

Hi,
I originally sent this to the users list, but I think it might be better 
sent to the developers

Please respond to ether rob_mm@hotmail.com or the mailman-users list, as I 
am not part of the developers list.
----
I have just installed mailman on our test intranet.
I was wondering if anyone has tried integrating mailman with other 
information systems?

We use the LDAP standard (kind of a database) to keep track of people and 
groups in our organization.

We have a need for a mail list manager for the purposes of archiving, 
digests, exploding lists, etc... but would like to have the actual lists 
managed from the LDAP side (or at least kept concurrent with).

My Original plan was to simply have a daemon running to periodically extract 
members of groups from the LDAP database and rebuild the lists that mailman 
uses (I thought they would be text files).

However, now that I have installed Mailman I see the lists are kept in the 
binary file format (.db). This makes things much more difficult.

Does anyone have any experience/suggestions in this matter?
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From hniksic@iskon.hr  Wed Jun 14 20:21:05 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 21:21:05 +0200
Subject: [Mailman-Developers] Web interface for creating new mailing lists
Message-ID: <dpem60nk66.fsf@mraz.iskon.hr>

As far as I can see, it seems that there is no interface for creating
on-site mailing lists?  Is that omission intentional, or is it the
case that noone has gotten around to doing it?

What I have in mind is a user/maintainer-friendly web interface that
allows you to open new mailing lists, delete the existing ones, stuff
like that.  It would store its state information somewhere in the
mailman directories, and write out sendmail-(or whatever)-style
aliases to a system file instructed to be read by the MTA -- say
/etc/mail/mailman-aliases.

Do you think such a thing would be worthwhile to add to Mailman if it
does not already exist?  I need to write something like that here at
work, and I wonder if it's possible to leverage the existing Mailman
architectures for things like state files, locks, etc.


From bigdog@dogpound.vnet.net  Wed Jun 14 20:31:10 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Wed, 14 Jun 2000 15:31:10 -0400 (EDT)
Subject: [Mailman-Developers] Web interface for creating new mailing
 lists
In-Reply-To: <dpem60nk66.fsf@mraz.iskon.hr>
Message-ID: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>

On 14 Jun 2000, Hrvoje Niksic wrote:

> What I have in mind is a user/maintainer-friendly web interface that
> allows you to open new mailing lists, delete the existing ones, stuff
> like that.  It would store its state information somewhere in the
> mailman directories, and write out sendmail-(or whatever)-style
> aliases to a system file instructed to be read by the MTA -- say
> /etc/mail/mailman-aliases.

The newlist program could be hacked up to pipe thoes sendmail aliases to a
mailman writeable alias file like you mentioned above..  But the problem I
ran into was getting sendmail to reread thoes aliases.  As far as I could
see, only root could run 'newaliases'.

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Falls don't kill people. It's the deceleration trauma.
----------------------------------------------------------------
Wednesday, June 14, 2000 / 12:58PM



From hniksic@iskon.hr  Wed Jun 14 20:35:24 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 21:35:24 +0200
Subject: [Mailman-Developers] Web interface for creating new mailing lists
In-Reply-To: Matt Davis's message of "Wed, 14 Jun 2000 15:31:10 -0400 (EDT)"
References: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
Message-ID: <dpem60m4xv.fsf@mraz.iskon.hr>

Matt Davis <bigdog@dogpound.vnet.net> writes:

> On 14 Jun 2000, Hrvoje Niksic wrote:
> 
> > What I have in mind is a user/maintainer-friendly web interface that
> > allows you to open new mailing lists, delete the existing ones, stuff
> > like that.  It would store its state information somewhere in the
> > mailman directories, and write out sendmail-(or whatever)-style
> > aliases to a system file instructed to be read by the MTA -- say
> > /etc/mail/mailman-aliases.
> 
> The newlist program could be hacked up to pipe thoes sendmail
> aliases to a mailman writeable alias file like you mentioned above..
> But the problem I ran into was getting sendmail to reread thoes
> aliases.  As far as I could see, only root could run 'newaliases'.

On my system we never run `newaliases' because sendmail rebuilds the
aliases database on demand, automatically.

(The support for that will soon be removed from sendmail, but I assume
the same task could be performed by a simple cron job.)


From bwarsaw@python.org  Wed Jun 14 20:46:06 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 15:46:06 -0400 (EDT)
Subject: [Mailman-Developers] Web interface for creating new mailing lists
References: <dpem60nk66.fsf@mraz.iskon.hr>
Message-ID: <14663.57598.1538.417700@anthem.concentric.net>

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

    Hrvoje> As far as I can see, it seems that there is no interface
    Hrvoje> for creating on-site mailing lists?  Is that omission
    Hrvoje> intentional, or is it the case that noone has gotten
    Hrvoje> around to doing it?

The latter.  Mailman, in its deep dark history, had some provision for
that but it was broken at one point in the pre-1.0 era and was never
put back in.  I would definitely like at some point to add stuff like
that back.

-Barry


From smead@amplepower.com  Wed Jun 14 21:35:30 2000
From: smead@amplepower.com (David Smead)
Date: Wed, 14 Jun 2000 13:35:30 -0700 (PDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: <d6dhfawpiol.fsf@octarine.uio.no>
Message-ID: <Pine.LNX.4.10.10006141331310.5254-100000@henry.amplepower.com>

Greetings,

I believe that the mv command is atomic.  Instead of unlinking a lock
file, why not move it? Hope this is helpful.

Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On 14 Jun 2000, Harald Meland wrote:

> [Barry A. Warsaw]
> 
> > I think __break() is fundamentally broken.  Actually, I think
> > breaking locks gets us into all kinds of problems.
> 
> I completely agree.  However:
> 
> > But there's the trade-off of deadlocking the whole system for
> > something we haven't thought about.
> 
> That is one rather humongously-sized "but".  [ Do not read the
> previous sentence out loud to your wife/girlfriend ;) ]
> 
> > One approach might be to never break locks implicitly, but have
> > qrunner (which now runs every minute) check for long-dead locks and
> > send warning emails to the site admin.  A simple rm should clear up
> > the problem.
> 
> My gut feeling says that this would be too cumbersome.  The problem
> with breaking a lock is that it introduces race conditions; and by
> having human admins break the lock "by hand", all you really gain is a
> reduced probability that two or more admins will (try to) break the
> same lock (nearly) simultaneously -- meaning that all but the first
> admin really break non-stale locks.
> 
> As long as we do locking by use of the file system, I think there
> _has_ to be some way to break stale locks.  Furthermore, I don't think
> it's possible to make the method for breaking these locks *completely*
> free of race conditions.
> 
> I think that our focus should therefore be on reducing the
> probabilities of
> 
>   a) the occurance of stale locks and
>   b) multiple lock breakages in quick succession, as this could
>      possibly lead to fresh, non-stale locks being broken.
> 
> I would vastly prefer reducing the probability of breaking non-stale
> lock by automated means, e.g. by introducing (relatively) large
> sleep()s in appropriate places.
> 
> 
> 
> Oh, hang on: I just realized that I might have misunderstood what
> you're suggesting.  If you meant that there should only be *one*
> process which is allowed to break locks, then I agree.  
> 
> Of course, there is a catch-22 inside that: The way of ensuring that
> there is only *one* instance of that process running, is to do obtain
> some lock...
> 
> > As an interim approach, I'm just cranking up the qrunner and list
> > lock lifetimes to really big numbers (like 10 hours and 5 hours
> > respectively).
> 
> Ouch.  I do agree with you, though.
> 
> > All this is just whacked anyway.  What we really need is a
> > transactional database underneath so we wouldn't need all these
> > stupid list locks.  I still believe that's too much work for 2.0,
> > but as this beta3 drags on, I'm starting to have doubts.
> 
> Ummm, by saying "transactional" you're ruling out mysql, right?  I
> think I read somewhere that the lack of "transactions" was the main
> thing separating mysql from other DBMSes.
> 
> As Mailman is GNU software, I'm wondering which free transactional
> DBMS(es) Mailman could (or should :) live on top of.
> -- 
> Harald
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From claw@kanga.nu  Thu Jun 15 01:22:42 2000
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 14 Jun 2000 17:22:42 -0700
Subject: [Mailman-Developers] Web interface for creating new mailing lists
In-Reply-To: Message from Matt Davis <bigdog@dogpound.vnet.net>
 of "Wed, 14 Jun 2000 15:31:10 EDT." <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
References: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
Message-ID: <20581.961028562@kanga.nu>

On Wed, 14 Jun 2000 15:31:10 -0400 (EDT) 
Matt Davis <bigdog@dogpound.vnet.net> wrote:

> The newlist program could be hacked up to pipe thoes sendmail
> aliases to a mailman writeable alias file like you mentioned
> above..  But the problem I ran into was getting sendmail to reread
> thoes aliases.  As far as I could see, only root could run
> 'newaliases'.

Much as I think the best route is to take sendmail out back and
shoot it like the mangy rabid cur it is, a simple cronjob that
watched the timestamp of the alias file and ran newaliases as
appropriate would do the job.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 15 01:30:11 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Wed, 14 Jun 2000 17:30:11 -0700 (PDT)
Subject: [Mailman-Developers] Web interface for creating new mailing lists
Message-ID: <200006150029.RAA00807@utopia.west.sun.com>

> Much as I think the best route is to take sendmail out back and
> shoot it like the mangy rabid cur it is, a simple cronjob that
> watched the timestamp of the alias file and ran newaliases as
> appropriate would do the job.

s/cronjob/daemon (or background shell process with sleep, whatever)/



From Harald.Meland@usit.uio.no  Thu Jun 15 01:56:41 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 15 Jun 2000 02:56:41 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: David Smead's message of "Wed, 14 Jun 2000 13:35:30 -0700 (PDT)"
References: <Pine.LNX.4.10.10006141331310.5254-100000@henry.amplepower.com>
Message-ID: <d6dzoonoj7a.fsf@octarine.uio.no>

[David Smead]

> Greetings,
> 
> I believe that the mv command is atomic.  Instead of unlinking a
> lock file, why not move it?

Both unlink(2) and rename(2) are (supposed to be) atomic system calls,
AFAIK.  The problem occurs whenever there is a stale lock, and the
need to break that lock is raised.

An example of how the race condition can manifest itself might help
explain:


Say that two processes, A and B, want lock L.  They both discover that
the lock is so old that it is stale.

First, process A breaks the lock.  Whether this is done by means of
unlink(2) or rename(2) is not relevant, the point is that after the
breaking there is no longer any file occupying the lockfile's position
in the file system.

Next, process A tries to get the lock, and succeeds.

Now the problem arises: Process B still thinks the lock is stale, and
breaks it.  Process A has lock attempt has already returned
successfully, so process A still thinks it is the lock owner.

Finally, process B tries to get the lock -- and succeeds.

Now, both processes believes they own the lock.  We should aim at
reducing the probability of such situations.


One thing which would (slightly) reduce the risk of race condition is
to put a long(ish) delay right after a process has broken a lock, so
that the process doing the lock breaking is less likely to obtain the
lock.  The idea is that such a delay would cause B's breaking attempt
to occur before A retries lock retrieval.

However, this would only help with race conditions involving only two
processes -- with e.g. three processes, process A could break, process
B get the lock, and then process C could break B's fresh lock.


Thanks for trying, though -- I would love it if we were able to come
up with a failsafe filsystem-based locking scheme (with support for
breaking stale locks).
-- 
Harald


From mentor@alb-net.com  Thu Jun 15 05:07:25 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:07:25 -0400 (EDT)
Subject: [Mailman-Developers] password a MUST?!
Message-ID: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>

Hello,

Isn't it more user friendly and a nice feature to have the password as
optional when users try to subscribe to a list? 

If they supply the password, ok, use it. Otherwise, let the mailman 
generate a password for them as it does when e-mail addresses are
subscribed by the list owner through the web page.

The optional password feature will be nice when embedding the subscription
box on a different page that the default one. 

Just a thought......

later,
mentor



From chuqui@plaidworks.com  Thu Jun 15 05:16:43 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 21:16:43 -0700
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>
References: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>
Message-ID: <p04320400b56e089cf021@[209.239.169.197]>

At 12:07 AM -0400 6/15/2000, Mentor Cana wrote:
>Hello,
>
>Isn't it more user friendly and a nice feature to have the password as
>optional when users try to subscribe to a list?

You need some way to authenticate users on the web site. Otherwise, 
anyone with your emailaddress can raise havoc on you.

But that doesn't mean the password needs to be set immediately, 
Simple leave it undefined until a user needs it, and then 
auto-generate it and mail it to them on request. That way, until the 
user needs it, they aren't confused by it....

But if you're going to do your admin via web, you need some sort of 
server-generated dongle to validate the user has access to the email 
address.

Unfortunately, you can't trust the universe.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mentor@alb-net.com  Thu Jun 15 05:24:44 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:24:44 -0400 (EDT)
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <p04320400b56e089cf021@[209.239.169.197]>
Message-ID: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>

On Wed, 14 Jun 2000, at 21:16, Chuq Von Rospach wrote:
> At 12:07 AM -0400 6/15/2000, Mentor Cana wrote:
> >Hello,
> >
> >Isn't it more user friendly and a nice feature to have the password as
> >optional when users try to subscribe to a list?
> 
> You need some way to authenticate users on the web site. Otherwise, 
> anyone with your emailaddress can raise havoc on you.

Isn't this independent of the fact if password is required on subscription
or not? What I'm saying is not to eliminate the password option all
together, just suggestion that password should not be required if not
supplied and mailman generates the password instead. 

The havoc is control by the list setting that should require confirmation
on subscription which is not dependent on he passwords.
 
later,
Mentor



From chuqui@plaidworks.com  Thu Jun 15 05:28:30 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 21:28:30 -0700
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>
References: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>
Message-ID: <p04320401b56e0b9da4f0@[209.239.169.197]>

At 12:24 AM -0400 6/15/2000, Mentor Cana wrote:

>Isn't this independent of the fact if password is required on subscription
>or not?

Yes.

>  What I'm saying is not to eliminate the password option all
>together, just suggestion that password should not be required if not
>supplied and mailman generates the password instead.

Could be done. At this point, I don't think I'd consider it a high 
priority for 2.0. But it'd be nice to have down the road.

>The havoc is control by the list setting that should require confirmation
>on subscription which is not dependent on he passwords.

No, actually, both are independent but control different aspects of attack.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mentor@alb-net.com  Thu Jun 15 05:33:30 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:33:30 -0400 (EDT)
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: <p04320401b56e0b9da4f0@[209.239.169.197]>
Message-ID: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>

On Wed, 14 Jun 2000, at 21:28, Chuq Von Rospach wrote:
> >  What I'm saying is not to eliminate the password option all
> >together, just suggestion that password should not be required if not
> >supplied and mailman generates the password instead.
> 
> Could be done. At this point, I don't think I'd consider it a high 
> priority for 2.0. But it'd be nice to have down the road.

The following patch was posted on this list few days ago. Isn't this doing
the trick?

later,
mentor
--
Mailman/Cgi/subscribe.py
diff -r1.25 subscribe.py
139,141c139,140
<         error = 1
<         results = (results +
<                    "You must supply a valid password, and confirm  it.<br>")
---
>         pw  = Utils.MakeRandomPassword()
>         pwc = pw



From fil@bok.net  Thu Jun 15 09:04:04 2000
From: fil@bok.net (Fil)
Date: Thu, 15 Jun 2000 10:04:04 +0200
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>; from mentor@alb-net.com on Thu, Jun 15, 2000 at 12:33:30AM -0400
References: <p04320401b56e0b9da4f0@[209.239.169.197]> <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>
Message-ID: <20000615100404.A21990@orwell.bok.net>

* Mentor Cana (mentor@alb-net.com) écrivait :
> Mailman/Cgi/subscribe.py
> diff -r1.25 subscribe.py
> 139,141c139,140
> <         error = 1
> <         results = (results +
> <                    "You must supply a valid password, and confirm  it.<br>")
                                                                     **

** not so sure about the two spaces here, but yes this patch does the trick,
has been working for me for quite a long time, and I don't see a downside in
letting mm choose the password for the user.



From Harald.Meland@usit.uio.no  Thu Jun 15 10:14:22 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 15 Jun 2000 11:14:22 +0200
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: Mentor Cana's message of "Thu, 15 Jun 2000 00:33:30 -0400 (EDT)"
References: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>
Message-ID: <d6dr99zz4pd.fsf@octarine.uio.no>

[Mentor Cana]

> On Wed, 14 Jun 2000, at 21:28, Chuq Von Rospach wrote:
> > >  What I'm saying is not to eliminate the password option all
> > >together, just suggestion that password should not be required if not
> > >supplied and mailman generates the password instead.
> > 
> > Could be done. At this point, I don't think I'd consider it a high 
> > priority for 2.0. But it'd be nice to have down the road.
> 
> The following patch was posted on this list few days ago. Isn't this doing
> the trick?

Not quite, I think.  I, for one, don't want to allow my users to
subscribe with random passwords -- explaining the Mailman
password-and-user stuff we have in place here is confusing enough as
it is.

Here's a revised version of the patch (please use "diff -u" or "diff
-c" when posting patches -- I believe Barry prefers the latter, while
I myself prefer the former):

Index: Mailman/Defaults.py.in
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Defaults.py.in,v
retrieving revision 1.101
diff -u -r1.101 Defaults.py.in
--- Mailman/Defaults.py.in      2000/05/04 22:44:28     1.101
+++ Mailman/Defaults.py.in      2000/06/15 08:32:49
@@ -222,6 +222,10 @@
 DEFAULT_SUBSCRIBE_POLICY = 1
 # does this site allow completely unchecked subscriptions?
 ALLOW_OPEN_SUBSCRIBE = 0
+# does this site allow user to subscribe without specifying what their
+# member password should be?  If set to true, Mailman will generate
+# random passwords for such users.
+ALLOW_RANDOMPWD_SUBSCRIBE = 0
 
 # Private_roster == 0: anyone can see, 1: members only, 2: admin only.
 DEFAULT_PRIVATE_ROSTER = 0
Index: Mailman/Cgi/subscribe.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v
retrieving revision 1.24
diff -u -r1.24 subscribe.py
--- Mailman/Cgi/subscribe.py    2000/04/04 23:38:25     1.24
+++ Mailman/Cgi/subscribe.py    2000/06/15 09:13:14
@@ -135,9 +135,20 @@
         results = results + "You must not subscribe a list to itself!<br>"
 
     if not form.has_key("pw") or not form.has_key("pw-conf"):
-        error = 1
-        results = (results +
-                   "You must supply a valid password, and confirm it.<br>")
+        if mm_cfg.ALLOW_RANDOMPWD_SUBSCRIBE:
+            # If the user has supplied a password, but not confirmed it,
+            # we use the supplied password anyway.
+            if form.has_key("pw"):
+                pw = form["pw"].value
+            # Otherwise generate a random password.
+            else:
+                pw = Utils.MakeRandomPassword()
+            # Auto-confirm this password
+            pwc = pw
+        else:
+            error = 1
+            results = (results +
+                       "You must supply a valid password, and confirm it.<br>")
     else:
         pw  = form["pw"].value
         pwc = form["pw-conf"].value


The patch has not (yet) been tested, please report back any failures
or successes.

If it works out OK, and no-one objects strongly, I'll consider
committing this before 2.0 (I'll be away next week (attending USENIX
2000), which should leave ample time to voice any objections :).
-- 
Harald


From Nigel.Metheringham@VData.co.uk  Fri Jun 16 16:24:01 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 16 Jun 2000 16:24:01 +0100
Subject: [Mailman-Developers] Mailman home location nowadays...
Message-ID: <E132xyT-0000hL-00@rioja.localnet>

Mailman seems to be spreading somewhat...  currently there seems to be:-

  http://www.list.org/
	- general info, FAQs, link to jitterbug database, current source

  http://www.gnu.org/software/mailman/mailman.html
	- quoted as the canonical source, older source (currently offline)

  http://sourceforge.net/project/?group_id=103
	- developer stuff, patches, bug db, release sources set, cvs

  http://mailman.sourceforge.net/
	[potential.... sourceforge is currently suffering "issues"]


Barry, where is the best place for developer type activity now - 
patches/issues to list, into sourceforge, into jitterbug, or something 
else?
[obviously to all rules there will be exceptions - security related 
stuff might be best straight to you so it can be fixed before 
publicised, patches that are concepts for comments are prolly best to 
the list]

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From bwarsaw@python.org  Fri Jun 16 17:19:22 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 16 Jun 2000 12:19:22 -0400 (EDT)
Subject: [Mailman-Developers] Mailman home location nowadays...
References: <E132xyT-0000hL-00@rioja.localnet>
Message-ID: <14666.21386.675707.199924@anthem.concentric.net>

>>>>> "NM" == Nigel Metheringham <Nigel.Metheringham@VData.co.uk> writes:

    NM> Mailman seems to be spreading somewhat...  currently there
    NM> seems to be:-

    NM>   http://www.list.org/ - general info, FAQs, link to jitterbug
    NM> database, current source

    NM>   http://www.gnu.org/software/mailman/mailman.html - quoted as
    NM> the canonical source, older source (currently offline)

Seems to work for me, and the ftp site has 2.0b2.

I was thinking about using list.org to house a lot more information
about Mailman, including eventually manuals, API's, and perhaps a more
elaborate site.  I don't know if that would work on gnu.org so I was
thinking that that would just be a very brief intro.  RMS may want
gnu.org to be the primary site though, but I'll only do that if I can
have the creative control I want.

    |   http://sourceforge.net/project/?group_id=103
    | 	- developer stuff, patches, bug db, release sources set, cvs

I'd like to migrate everything off of python.org except the mailing
lists (and maybe one day those too).  Jitterbug blows, and SF's
project management stuff has other problems, but I think it's the
right long term solution.  At some point I plan on turning of the
Jitterbug stuff and just pointing everyone to SF.

    |   http://mailman.sourceforge.net/
    | 	[potential.... sourceforge is currently suffering "issues"]

Yeah, I just tried that, wassup with it?

Ideally, mailman.sourceforge.net, gnu.org/..., and list.org would be
identical copies of the same web pages and ftp.  Think of them as
mirrors.

    NM> Barry, where is the best place for developer type activity now
    NM> - patches/issues to list, into sourceforge, into jitterbug, or
    NM> something else?  [obviously to all rules there will be
    NM> exceptions - security related stuff might be best straight to
    NM> you so it can be fixed before publicised, patches that are
    NM> concepts for comments are prolly best to the list]

Yup.  Let's try to start using SF to track stuff, because while it has
problems, it's better than Jitterbug.  For really important stuff, use
mailman-developers or mailman-cabal (this reaches just the core
developers).  I haven't had time to read mailman-users in a long time,
so I really appreciate when people forward the important stuff to the
dev list.

-Barry


From claw@kanga.nu  Fri Jun 16 18:57:35 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 16 Jun 2000 10:57:35 -0700
Subject: [Mailman-Developers] Migration to sourceforge?
In-Reply-To: Message from "Bradley M. Kuhn" <bkuhn@gnu.org>
 of "Fri, 16 Jun 2000 13:26:03 EDT." <20000616132603.T22088@ebb.org>
References: <20000616132603.T22088@ebb.org>
Message-ID: <25908.961178255@kanga.nu>

On Fri, 16 Jun 2000 13:26:03 -0400 
Bradley M Kuhn <bkuhn@gnu.org> wrote:

> SourceForge is currently (I am trying to change their minds, but
> it's an uphill battle) somewhat unfriendly to free software
> developers, as they consistently favor the term "open source" over
> "free software".

I know the people at SourceForge (I used to work at VA).  This is
not going to happen, and not only because ESR is on VA's board.  VA
falls solidly on ESR's side of the Open/Free debate.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Fri Jun 16 19:21:34 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 16 Jun 2000 11:21:34 -0700
Subject: [Mailman-Developers] Migration to sourceforge?
In-Reply-To: Message from "Bradley M. Kuhn" <bkuhn@gnu.org>
 of "Fri, 16 Jun 2000 14:06:40 EDT." <20000616140640.Y22088@ebb.org>
References: <20000616132603.T22088@ebb.org> <bkuhn@gnu.org> <25908.961178255@kanga.nu>  <20000616140640.Y22088@ebb.org>
Message-ID: <26474.961179694@kanga.nu>

On Fri, 16 Jun 2000 14:06:40 -0400 
Bradley M Kuhn <bkuhn@gnu.org> wrote:

> I have been told that VA Linux doesn't dictate policy to
> SourceForge---they own it, but they don't seem to exert full
> control over it, giving the SourceForge developers some freedom to
> make these sorts of decisions.

SF is paid for out of VA's Marketting dept.  This explains many
things.

>      "We could really get a lot of use out of sourceforge for GNU
> mailman.  However, since GNU mailman is a free software project
> but not an open source project, it doesn't make sense to host it
> there the way the site stands, because it only reflects an
> affiliation with open source, and free software seems to be
> inadvertantly omitted.  Would you mention Free Software and Open
> Source equally on SourceForge, so we can host GNU mailman there?"

Ahh, this is different than I first understood.  Drop an email to
this effect to Tony (heads the SF project, forget email address) at
VA and CC it to Brian Biles (bbiles@valinux.com) and you should get
a good response.  

> Don Marti has been particularly sympathetic, but seems to need to
> be convinced a little bit more to make the change.

While Don works at VA, he really isn't involved in SF and so has
little direct say.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From mentor@alb-net.com  Fri Jun 16 22:24:42 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Fri, 16 Jun 2000 17:24:42 -0400 (EDT)
Subject: [Mailman-Developers] editing messages on hold donesn't work
Message-ID: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>

I don't remember if modifying the messages for approval was supposed to be
a feature yet or not.

Anyways, I just tried modifying the message body and then approved the
message and the changes were lost. The messages was distributed as it
came...

later,
Mentor



From bwarsaw@python.org  Fri Jun 16 22:39:10 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 16 Jun 2000 17:39:10 -0400 (EDT)
Subject: [Mailman-Developers] editing messages on hold donesn't work
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>
Message-ID: <14666.40574.479937.533421@anthem.concentric.net>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> I don't remember if modifying the messages for approval was
    MC> supposed to be a feature yet or not.

Not.


From dgc@uchicago.edu  Fri Jun 16 22:43:04 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 16 Jun 2000 16:43:04 -0500
Subject: [Mailman-Developers] Re: editing messages on hold donesn't work
In-Reply-To: <14666.40574.479937.533421@anthem.concentric.net>; from bwarsaw@python.org on Fri, Jun 16, 2000 at 05:39:10PM -0400
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com> <14666.40574.479937.533421@anthem.concentric.net>
Message-ID: <20000616164304.Q13782@smack.uchicago.edu>

On 2000.06.16, in <14666.40574.479937.533421@anthem.concentric.net>,
	"Barry A. Warsaw" <bwarsaw@python.org> wrote:
> 
> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:
> 
>     MC> I don't remember if modifying the messages for approval was
>     MC> supposed to be a feature yet or not.
> 
> Not.

Now or ever?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@python.org  Sat Jun 17 06:40:52 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 17 Jun 2000 01:40:52 -0400 (EDT)
Subject: [Mailman-Developers] Re: editing messages on hold donesn't work
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>
 <14666.40574.479937.533421@anthem.concentric.net>
 <20000616164304.Q13782@smack.uchicago.edu>
Message-ID: <14667.3940.630979.158550@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:
> 
>     MC> I don't remember if modifying the messages for approval was
>     MC> supposed to be a feature yet or not.
> 
> Not.

    DC> Now or ever?

Never say never. :)  It would be a useful feature to have.


From mentor@alb-net.com  Sun Jun 18 03:40:57 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Sat, 17 Jun 2000 22:40:57 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
Message-ID: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>

TypeError: not enough arguments; expected 7, got 4

---
Jun 17 21:44:25 2000 admin(20600): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(20600): [----- Mailman Version: 2.0beta3 -----]
admin(20600): [----- Traceback ------]
admin(20600): Traceback (innermost last):
admin(20600):   File "/opt/home/mailman/scripts/driver", line 95, in run_main
admin(20600):     main()
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 122, in main
admin(20600):     PrintRequests(mlist, doc, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
admin(20600):     PrintPostRequest(mlist, id, info, total, count, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
admin(20600):     mlist.HandleRequest(id, 2, None)
admin(20600): TypeError: not enough arguments; expected 7, got 4
admin(20600): [----- Python Information -----]
admin(20600): sys.version    = 1.5.2 (#6, Jan  5 2000, 13:41:49)  [GCC 2.95.2 19991024 (release)]
admin(20600): sys.executable = /usr/local/bin/python
admin(20600): sys.prefix     = /usr/local
admin(20600): sys.exec_prefix= /usr/local
admin(20600): sys.path       = /usr/local
admin(20600): sys.platform   = sunos5
admin(20600): [----- Environment Variables -----]
admin(20600): 	DOCUMENT_ROOT: /opt/i386/html
admin(20600): 	SERVER_ADDR: 205.216.244.65
admin(20600): 	HTTP_ACCEPT_ENCODING: gzip, deflate
admin(20600): 	REMOTE_HOST: spider-tm011.proxy.aol.com
admin(20600): 	CONTENT_TYPE: application/x-www-form-urlencoded
admin(20600): 	PATH_TRANSLATED: /opt/i386/html/alb-club
admin(20600): 	SERVER_SOFTWARE: Apache/1.3.12 (Unix) mod_ssl/2.6.0 OpenSSL/0.9.4
admin(20600): 	GATEWAY_INTERFACE: CGI/1.1
admin(20600): 	HTTP_ACCEPT_LANGUAGE: en-us
admin(20600): 	REMOTE_ADDR: 152.163.197.46
admin(20600): 	SERVER_PORT: 80
admin(20600): 	TZ: US/Eastern
admin(20600): 	HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 4.01; AOL 5.0; Windows 98)
admin(20600): 	HTTP_ACCEPT: application/msword, application/x-comet, */*
admin(20600): 	REQUEST_URI: /mailman/admindb/alb-club
admin(20600): 	LD_LIBRARY_PATH: /opt/i386/lib
admin(20600): 	PATH: /usr/sbin:/usr/bin:/bin:/usr/bin:/usr/ucb:/usr/ccs/bin/:/opt/i386/bin:/usr/sbin:/opt/i386/bin/include:/etc:/usr/local/bin:/opt/i386/Perl/bin:/opt/i386/lib:/etc/lib
admin(20600): 	QUERY_STRING: 
admin(20600): 	SERVER_PROTOCOL: HTTP/1.0
admin(20600): 	CONTENT_LENGTH: 15
admin(20600): 	HTTP_HOST: www.alb-net.com
admin(20600): 	REQUEST_METHOD: POST
admin(20600): 	SERVER_SIGNATURE: <ADDRESS>Apache/1.3.12 Server at www.alb-net.com Port 80</ADDRESS>

admin(20600): 	SCRIPT_NAME: /mailman/admindb
admin(20600): 	SERVER_ADMIN: staff@alb-net.com
admin(20600): 	SCRIPT_FILENAME: /opt/home/mailman/cgi-bin/admindb
admin(20600): 	PYTHONPATH: /opt/home/mailman
admin(20600): 	PATH_INFO: /alb-club
admin(20600): 	HTTP_REFERER: http://www.alb-net.com/mailman/admindb/alb-club
admin(20600): 	HTTP_PRAGMA: No-Cache
admin(20600): 	SERVER_NAME: www.alb-net.com
admin(20600): 	REMOTE_PORT: 43440



From bigdog@dogpound.vnet.net  Sun Jun 18 04:03:24 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Sat, 17 Jun 2000 23:03:24 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
In-Reply-To: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
Message-ID: <Pine.LNX.4.21.0006172301570.27164-100000@dogpound.vnet.net>

On Sat, 17 Jun 2000, Mentor Cana wrote:

> TypeError: not enough arguments; expected 7, got 4

It might help if you tell us a bit more about what you were doing at hte
time you got this problem.  What did you click?  What page was it
from? What were you doing at the time?  What color were your socks when
this happened?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Drive C: Error, (A)bort (R)etry (I)gnore (K)ick (S)cream
----------------------------------------------------------------
Saturday, June 17, 2000 / 11:01PM





From mentor@alb-net.com  Sun Jun 18 04:14:47 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Sat, 17 Jun 2000 23:14:47 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS (fwd)
Message-ID: <Pine.GSO.4.21.0006172311240.20851-100000@alb-net.com>

Sorry for not adding the additional line of explanation.

It happened after hitting "Tend to pending administrative requests."
The page shows the error below.

The list in question has more then 10 pending approval (looking at data/
directory). 

thanks,
mentor

---------- Forwarded message ----------
Date: Sat, 17 Jun 2000 22:40:57 -0400 (EDT)
From: Mentor Cana <mentor@alb-net.com>
To: mailman-developers@python.org
Cc: mailman-users@python.org
Subject: [Mailman-Developers] a bug with the most recent CVS


TypeError: not enough arguments; expected 7, got 4

---
Jun 17 21:44:25 2000 admin(20600): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(20600): [----- Mailman Version: 2.0beta3 -----]
admin(20600): [----- Traceback ------]
admin(20600): Traceback (innermost last):
admin(20600):   File "/opt/home/mailman/scripts/driver", line 95, in run_main
admin(20600):     main()
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 122, in main
admin(20600):     PrintRequests(mlist, doc, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
admin(20600):     PrintPostRequest(mlist, id, info, total, count, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
admin(20600):     mlist.HandleRequest(id, 2, None)
admin(20600): TypeError: not enough arguments; expected 7, got 4
admin(20600): [----- Python Information -----]
admin(20600): sys.version    = 1.5.2 (#6, Jan  5 2000, 13:41:49)  [GCC 2.95.2 19991024 (release)]
admin(20600): sys.executable = /usr/local/bin/python
admin(20600): sys.prefix     = /usr/local
admin(20600): sys.exec_prefix= /usr/local
admin(20600): sys.path       = /usr/local
admin(20600): sys.platform   = sunos5
admin(20600): [----- Environment Variables -----]
admin(20600): 	DOCUMENT_ROOT: /opt/i386/html
admin(20600): 	SERVER_ADDR: 205.216.244.65
admin(20600): 	HTTP_ACCEPT_ENCODING: gzip, deflate
admin(20600): 	REMOTE_HOST: spider-tm011.proxy.aol.com
admin(20600): 	CONTENT_TYPE: application/x-www-form-urlencoded
admin(20600): 	PATH_TRANSLATED: /opt/i386/html/alb-club
admin(20600): 	SERVER_SOFTWARE: Apache/1.3.12 (Unix) mod_ssl/2.6.0 OpenSSL/0.9.4
admin(20600): 	GATEWAY_INTERFACE: CGI/1.1
admin(20600): 	HTTP_ACCEPT_LANGUAGE: en-us
admin(20600): 	REMOTE_ADDR: 152.163.197.46
admin(20600): 	SERVER_PORT: 80
admin(20600): 	TZ: US/Eastern
admin(20600): 	HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 4.01; AOL 5.0; Windows 98)
admin(20600): 	HTTP_ACCEPT: application/msword, application/x-comet, */*
admin(20600): 	REQUEST_URI: /mailman/admindb/alb-club
admin(20600): 	LD_LIBRARY_PATH: /opt/i386/lib
admin(20600): 	PATH: /usr/sbin:/usr/bin:/bin:/usr/bin:/usr/ucb:/usr/ccs/bin/:/opt/i386/bin:/usr/sbin:/opt/i386/bin/include:/etc:/usr/local/bin:/opt/i386/Perl/bin:/opt/i386/lib:/etc/lib
admin(20600): 	QUERY_STRING: 
admin(20600): 	SERVER_PROTOCOL: HTTP/1.0
admin(20600): 	CONTENT_LENGTH: 15
admin(20600): 	HTTP_HOST: www.alb-net.com
admin(20600): 	REQUEST_METHOD: POST
admin(20600): 	SERVER_SIGNATURE: <ADDRESS>Apache/1.3.12 Server at www.alb-net.com Port 80</ADDRESS>

admin(20600): 	SCRIPT_NAME: /mailman/admindb
admin(20600): 	SERVER_ADMIN: staff@alb-net.com
admin(20600): 	SCRIPT_FILENAME: /opt/home/mailman/cgi-bin/admindb
admin(20600): 	PYTHONPATH: /opt/home/mailman
admin(20600): 	PATH_INFO: /alb-club
admin(20600): 	HTTP_REFERER: http://www.alb-net.com/mailman/admindb/alb-club
admin(20600): 	HTTP_PRAGMA: No-Cache
admin(20600): 	SERVER_NAME: www.alb-net.com
admin(20600): 	REMOTE_PORT: 43440


_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://www.python.org/mailman/listinfo/mailman-developers




From paul@cr355112-a.slnt1.on.wave.home.com  Sun Jun 18 04:43:43 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Sat, 17 Jun 2000 23:43:43 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <20000618033202.1565D1CE28@dinsdale.python.org>
Message-ID: <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>

I get this message daily:
Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs

Traceback (innermost last):
  File "/usr/local/mailman/cron/checkdbs", line 87, in ?
    main()
  File "/usr/local/mailman/cron/checkdbs", line 52, in main
    text = text + '\n' + pending_requests(mlist)
  File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
    pending.append('    %s %s' % addr, time.ctime(when))
TypeError: not enough arguments for format string

Any idea how to fix it ?
I checked out this file but have no idea how /usr/bin/env python works.

Thanks
___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca



From smead@amplepower.com  Sun Jun 18 06:05:06 2000
From: smead@amplepower.com (David Smead)
Date: Sat, 17 Jun 2000 22:05:06 -0700 (PDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <Pine.LNX.4.10.10006172203440.24223-100000@henry.amplepower.com>

Paul,

I'd suggest parens around the part that supplies the arguments.  That is:
     pending.append('    %s %s' % (addr, time.ctime(when)))


Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Sat, 17 Jun 2000, paul wrote:

> I get this message daily:
> Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs
> 
> Traceback (innermost last):
>   File "/usr/local/mailman/cron/checkdbs", line 87, in ?
>     main()
>   File "/usr/local/mailman/cron/checkdbs", line 52, in main
>     text = text + '\n' + pending_requests(mlist)
>   File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
>     pending.append('    %s %s' % addr, time.ctime(when))
> TypeError: not enough arguments for format string
> 
> Any idea how to fix it ?
> I checked out this file but have no idea how /usr/bin/env python works.
> 
> Thanks
> ___________________________________________________________
> Paul Faure			    paul@engsoc.carleton.ca
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From paul@cr355112-a.slnt1.on.wave.home.com  Sun Jun 18 08:16:17 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Sun, 18 Jun 2000 03:16:17 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <Pine.LNX.4.10.10006172203440.24223-100000@henry.amplepower.com>
Message-ID: <Pine.LNX.4.10.10006180313350.12633-100000@cr355112-a.slnt1.on.wave.home.com>

Thanks, looks like it works.

___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca

On Sat, 17 Jun 2000, David Smead wrote:

> Paul,
> 
> I'd suggest parens around the part that supplies the arguments.  That is:
>      pending.append('    %s %s' % (addr, time.ctime(when)))
> 
> 
> Sincerely,
> 
> David Smead
> http://www.amplepower.com.
> http://www.ampletech.com.
> 
> On Sat, 17 Jun 2000, paul wrote:
> 
> > I get this message daily:
> > Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs
> > 
> > Traceback (innermost last):
> >   File "/usr/local/mailman/cron/checkdbs", line 87, in ?
> >     main()
> >   File "/usr/local/mailman/cron/checkdbs", line 52, in main
> >     text = text + '\n' + pending_requests(mlist)
> >   File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
> >     pending.append('    %s %s' % addr, time.ctime(when))
> > TypeError: not enough arguments for format string
> > 
> > Any idea how to fix it ?
> > I checked out this file but have no idea how /usr/bin/env python works.
> > 
> > Thanks
> > ___________________________________________________________
> > Paul Faure			    paul@engsoc.carleton.ca
> > 
> > 
> > _______________________________________________
> > Mailman-Developers mailing list
> > Mailman-Developers@python.org
> > http://www.python.org/mailman/listinfo/mailman-developers
> > 
> 



From marc_news@valinux.com  Sun Jun 18 18:02:17 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 18 Jun 2000 10:02:17 -0700
Subject: [Mailman-Developers] mailing list digest broken with mailman CVS
Message-ID: <20000618100217.A7174@moremagic.merlins.org>

Hi,

I had a mm1.1 installation, and upgraded it to mm cvs about 10 days ago.
Apparently, after the  upgrade, the digests were being sent,  but some users
complained of not receiving them.
I subscribed an Email of mine, and indeed, it never got any digests.

Jun 09 08:12:16 2000 (11394) svlug v 97 - 16 msgs, 243 recips (234 mime, 2 text,
7 disabled)
Jun 09 08:12:16 2000 (11394) next svlug digest: #98, post#1
Jun 09 21:47:25 2000 (10756) Officers v 92 - 16 msgs, 0 recips (0 mime, 0 text, 0
 disabled)
Jun 09 21:47:25 2000 (10756) next officers digest: #93, post#1
Jun 10 11:36:02 2000 (26804) svlug v 98 - 21 msgs, 244 recips (235 mime, 2 text,
7 disabled)
Jun 10 11:36:02 2000 (26804) next svlug digest: #99, post#1
Jun 11 08:00:02 2000 (25942) web-team v 21 - 20 msgs, 0 recips (0 mime, 0 text, 0
 disabled)
(...)
Jun 15 00:33:51 2000 (6181) svlug v 106 - 14 msgs, 246 recips (237 mime, 2 text,
7 disabled)
Jun 15 00:33:51 2000 (6181) next svlug digest: #107, post#1
Jun 15 10:56:06 2000 (25111) svlug v 107 - 17 msgs, 246 recips (237 mime, 2 text,
 7 disabled)
Jun 15 10:56:06 2000 (25111) next svlug digest: #108, post#1
Jun 15 19:32:40 2000 (12301) svlug v 108 - 21 msgs, 246 recips (237 mime, 2 text,
 7 disabled)
Jun 15 19:32:40 2000 (12301) next svlug digest: #109, post#1

Then, I upgraded to the CVS code of  the day on June 16th, and digests don't
even  show up  in  mailman/logs/digest  (there are  already  two days  worth
missing)

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From foner@media.mit.edu  Sun Jun 18 20:01:38 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 15:01:38 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20)
Message-ID: <200006181901.PAA04187@out-of-band.media.mit.edu>

[Please keep me CC'ed on any responses.  Thanks!]

I've just started using Mailman, and, while it's quite a nice little
package, I've already tripped over a number of bugs.  I've listed them
approximately in order from most severe to least severe below; I've
fixed 3 & 7-11 myself, but 1 & 2 require someone with at least a
passing familiarity with Python and Mailman's internals, and of course
they should all wind up in the current source tree.

I also spent a while poking at the Jitterbug interface, and concluded
that it wasn't likely that I'd be able to figure out which category
each individual bug should go into, or that it would save anybody any
time for me to try to stick them in the interface in the first place.
It's also incredibly painful to submit bugs by filling in web forms,
because the editing environment available is so poor.  Having the
forms used by Jitterbug also allow file uploading (when supported by
the browser, which most do) would help, but aren't a complete solution.

(1) Mailman doesn't send error reports to the right place.  Our setup
here has individual workstations, such as foo.media.mit.edu,
masquerade such that their mail headers are rewritten to appear to
come from media.mit.edu (which forwards mail to our main mail-handling
machine, and also has an MX pointing there).  This is usually how
large sets of machines are set up everywhere.  But when I was trying
to configure Mailman (with the wrong compiled-in GID [it wasn't clear
to me whether it was the webserver's GID or sendmail's GID that was
the right one], hence any request caused the wrapper to err), Mailman
evidently went out of its way to attempt to send the error mail to the
individual workstation, e.g., foo.media.mit.edu, and -not- to
media.mit.edu, which is what the From: address in the incoming mail to
Mailman specified and which should be respected in any event---From:
should -always- take precedence over some attempt to divine a better
address.  After all, Mailman cannot possibly have a better idea of
which machine is handling mail for the sender than the sender itself
does.  (This meant, btw, that the error mail simply got wedged in the
sendmail queue of the machine I'm running Mailman on, since individual
workstations here don't listen to SMTP requests.)

(2) Sending a message with no subject and no body to listname-request
causes the blank message to simply arrive at the admin address.  I
contend that it would be far nicer to the users -and- the administrator
if a blank message acted like one with "help" in it.  Otherwise, users
see a black hole (until the admin responds), and admins need to deal
with responding in a way that gets users to ask "help" anyway, most
likely.  It's just a pain all around.

(3) mailman-2.0beta2/Mailman/Archiver/HyperArch.py puts the URL
http://starship.skyport.net/crew/amk/maintained/pipermail.html
into the footer of its page describing the message archives,
but this is a dead link.  (I just commented out the footer entirely.)

(4) Feature request:  Mailman should support a --with-default-url as a
build argument so it can use cnames and/or virtual hosts.  Ditto for
the FQDN of the host.  I had to go in and screw around with various
options files to get this set up correctly after Mailman guessed; why
make the user edit this instead of taking it as an arg?  (Yes, I know
you can change it one list at a time in the admin web interface, but
the default should be right, too.)

(5) The doc says to run "make install" in at least 2 places, but never
says to actually run "make" anywhere.  But you -do- have to do a make :)

(6) Should I be creating mailman-owner or owner-mailman as aliases?
The doc is inconsistent, so I did both.  Is this specific to the MTA?
If so, you should figure it out and document it for common ones.  (I'm
using sendmail 8.9.3.)

(7) Even if the list administrator has disabled monthly password
mailings, templates/convert.txt and templates/subscribeack.txt both
claim that users' passwords will be mailed to them monthly (in fact,
the latter seems to say the same thing twice, in both the last and
penultimate paragraphs).  There should be some way for these templates
to check the current setting for the list, and to fail to include this
text if monthly reminders are turned off.  Mailman/HTMLFormatter.py
appears to make this check correctly, though I'm not positive that it's
generating the page I think it is.  [I find monthly password reminders
absolutely pernicious---after all, if I forget the password, I can
-ask- for it and get an instant response from the server anyway.  And
this way, I don't have the extra traffic, my password doesn't get
sent more than it has to over insecure channels, and very low-volume
lists don't send me mostly password-reminder traffic instead of
blessed silence.]

(8) Three's some bad formatting in the help page returned by sending a
"help" request to listname-request, apparently caused by linewrapping
performed by Utils.wrap (in Mailman/Utils.py)---Utils.wrap defaults to
70 columns wide, but the template text in template/help.txt has lines
longer than this (as do a couple of other calls from elsewhere in the
source code which call Utils.wrap on a fixed string; these are less
objectionable, in general, because the constant text isn't also
indented).  The end result looks pretty awful:

	end or --
	   Stop processing commands (good to do if your mailer
    automatically
	   adds a signature file - it'll save you from a lot of cruft).

should be

	end or --
	   Stop processing commands (good to do if your mailer automatically
	   adds a signature file - it'll save you from a lot of cruft).

and

	    unsubscribe from a different address than the one you
    subscribed
	    from, you may specify it in the 'address' field.

should be

	    unsubscribe from a different address than the one you subscribed
	    from, you may specify it in the 'address' field.

I've fixed this by changing the default in Utils.wrap to 78
characters, which is half-baked but works.

(9) Mailman/Handlers/Hold.py spells administrivia as adbministrivia instead
(there shouldn't be a "b" in that word...)

(10) Mailman/Cgi/admindb.py's default textbox message that says
"Please do *not* post administrative requests to the list!" has a
repeated "the" in the next sentence, so it talks about "the the
request address".  (The two "the"'s are separated by a newline in the
source, which makes this harder to see.)  I removed the repeat and
also changed the first sentence to "Please do not post administrative
requests to the list." (no *, no !) so it seems less like the admin is
yelling at the poor user.

(11) templates/subscribeack.txt puts an extra newline before "You" in
the normal (non-umbrella) case in:

      %(optionsurl)s
    %(umbrella)s
    You can also make such adjustments via email by sending a message to:

which I've fixed simply by doing

      %(optionsurl)s %(umbrella)s
    You can also make such adjustments via email by sending a message to:

but this also requires putting the right number of newlines into the
string in Deliverer.py which generates the string in umbrella.  Since
I can't easily test it, I didn't bother fixing that.

(12) It would be less confusing if the "details" page for various
configuration stuff didn't say "don't change it here---change it on
the previous page" or whatever.  Either make the form active on the
details page, or don't make it a form at all.  This wasn't a problem
for me, but I imagine it will be for others.  (Yes, I understand it's
easier to be able to reuse the code that generates the form this way,
but surely it can't be that hard to modularize.)


From marc_news@valinux.com  Sun Jun 18 20:14:46 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 18 Jun 2000 12:14:46 -0700
Subject: [Mailman-Developers] mailing list digest broken with mailman CVS ?
In-Reply-To: <20000618100217.A7174@moremagic.merlins.org>; from marc_news@valinux.com on Sun, Jun 18, 2000 at 10:02:17AM -0700
References: <20000618100217.A7174@moremagic.merlins.org>
Message-ID: <20000618121445.B17676@marc.merlins.org>

On Sun, Jun 18, 2000 at 10:02:17AM -0700, Marc MERLIN wrote:
> Then, I upgraded to the CVS code of  the day on June 16th, and digests don't
> even  show up  in  mailman/logs/digest  (there are  already  two days  worth
> missing)

I do apologize for the wording of my previous mail, I wasn't sufficiently
awake when I wrote it.
I added the question  mark after "broken" in the subject  line and wanted to
add the following:
---
Of course if digests didn't work at all, there would be other mentions of it
on the  mailing list,  and I didn't  see any, so  where should  I look? What
could be wrong?
---

Thanks,
Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From ricardo@rixhq.nu  Sun Jun 18 21:56:15 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sun, 18 Jun 2000 22:56:15 +0200
Subject: [Mailman-Developers] latest cvs trouble
In-Reply-To: <14665.1291.385427.914555@anthem.concentric.net>; from bwarsaw@python.org on Thu, Jun 15, 2000 at 12:32:11PM -0400
References: <20000324235727.K12922@xs4all.nl> <20000325125159.A20826@miss-janet.com> <14663.9674.246238.29225@anthem.concentric.net> <20000614085245.C855@miss-janet.com> <14665.1291.385427.914555@anthem.concentric.net>
Message-ID: <20000618225615.A706@miss-janet.com>

Hi,

I was just grabbing the latest CVS version and then I noticed the changes
in admindb.py (thanks Barry! :) ) and I couldn't wait to try it out on my list... 
so I wanted to test the feature to send a copy of an email held for approval to a certain
email address... I tried this by clicking the forward option and supplying my
email address for one of the 16 messages held for approval and hitted the
submit button... then I get this error :

Traceback (innermost last):
  File "/usr/local/mailman/scripts/driver", line 95, in run_main
    main()
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 122, in main
    PrintRequests(mlist, doc, form)
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
    PrintPostRequest(mlist, id, info, total, count, form)
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
    mlist.HandleRequest(id, 2, None)
TypeError: not enough arguments; expected 7, got 4

this error kinda puzzles me and I'm not enough of an python expert to see what's
going wrong...
I also noticed getting about 16 copies of the approved post send to my email address... yikes...

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From ricardo@rixhq.nu  Sun Jun 18 22:08:44 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sun, 18 Jun 2000 23:08:44 +0200
Subject: [Mailman-Developers] found the error... (admindb.py)
Message-ID: <20000618230844.B706@miss-janet.com>

admindb.py line #216 gets called when a post is lost (which happened in my case
i guess)... but this is still and old call to mlist.HandleRequest() which doesn't
include the rest of the necessary function parameters...
maybe the extra parameters should default to empty ("") ?
i was confused because it looks like it calls with 3 parameters instead of 4...
but then i realized to first parameter is probably 'self'... right?
and then I wonder why the post got lost too... (well maybe the id just didnt get
removed from the db?)

ps: i'm cc-ing this to you Barry, because I know my posts tend to arrive a bit late
on the list for some reason ;)

Ricardo.

--



From foner@media.mit.edu  Sun Jun 18 22:44:14 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 17:44:14 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [one more...]
Message-ID: <200006182144.RAA04624@out-of-band.media.mit.edu>

(13) Things that get bounced to the admin address because they look
like administrivia (e.g., sending "help" to the main list address)
have -two- X-BeenThere: message headers.  Since this header is
presumably there to stop loops, it strikes me as odd that two of them
could be in a message under any circumstances.  (Maybe they're only
checked for messages intended to go all the way out through the main
list---the two of them -do- seem harmless so far---but it's still odd.)


From foner@media.mit.edu  Mon Jun 19 00:53:33 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 19:53:33 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [and another]
Message-ID: <200006182353.TAA05006@out-of-band.media.mit.edu>

(14) When setting archival options, the form specifies the time period as
yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
order?


From dgc@uchicago.edu  Mon Jun 19 00:57:50 2000
From: dgc@uchicago.edu (David Champion)
Date: Sun, 18 Jun 2000 18:57:50 -0500
Subject: [Mailman-Developers] Re: Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [and another]
In-Reply-To: <200006182353.TAA05006@out-of-band.media.mit.edu>; from foner@media.mit.edu on Sun, Jun 18, 2000 at 07:53:33PM -0400
References: <200006182353.TAA05006@out-of-band.media.mit.edu>
Message-ID: <20000618185750.H7911@smack.uchicago.edu>

On 2000.06.18, in <200006182353.TAA05006@out-of-band.media.mit.edu>,
	"Lenny Foner" <foner@media.mit.edu> wrote:
> (14) When setting archival options, the form specifies the time period as
> yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
> yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
> order?

This made me think of something else.  Mailman text is full of
references to the "monthly" password reminders.  Any ideas about
allowing that period to be configurable?  What about turning off those
messages when the site or list policy is not to mail them?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bigdog@dogpound.vnet.net  Mon Jun 19 02:02:04 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Sun, 18 Jun 2000 21:02:04 -0400 (EDT)
Subject: [Mailman-Developers] Re: Various mailman bugs (all in 2.0beta2
 under HPUX 10.20) [and another]
In-Reply-To: <20000618185750.H7911@smack.uchicago.edu>
Message-ID: <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>

Not to step on anyones toes..  But all these look like great bugs or
features you would like (except 13 which I believe is configuratable on
the admin page for the list..).  But I'm quite certain Berry & the other
Mailman developers are swamped down with other things.

If you could fix and/or send a patch for these fixes to the list (or post
them to sourceforge) i'm sure the developers would be greatly
appreciatiave or however you spell that.  And if your in the process of
this already..  tell me to shutup :)

On Sun, 18 Jun 2000, David Champion wrote:

> On 2000.06.18, in <200006182353.TAA05006@out-of-band.media.mit.edu>,
> 	"Lenny Foner" <foner@media.mit.edu> wrote:
> > (14) When setting archival options, the form specifies the time period as
> > yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
> > yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
> > order?
> 
> This made me think of something else.  Mailman text is full of
> references to the "monthly" password reminders.  Any ideas about
> allowing that period to be configurable?  What about turning off those
> messages when the site or list policy is not to mail them?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Oxymoron: Sit up.
----------------------------------------------------------------
Sunday, June 18, 2000 / 08:51PM





From dgc@uchicago.edu  Mon Jun 19 02:12:36 2000
From: dgc@uchicago.edu (David Champion)
Date: Sun, 18 Jun 2000 20:12:36 -0500
Subject: [Mailman-Developers] Re: Re: Various mailman bugs (all in 2.0beta2
In-Reply-To: <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>; from bigdog@dogpound.vnet.net on Sun, Jun 18, 2000 at 09:02:04PM -0400
References: <20000618185750.H7911@smack.uchicago.edu> <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>
Message-ID: <20000618201236.L7911@smack.uchicago.edu>

On 2000.06.18, in <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>,
	"Matt Davis" <bigdog@dogpound.vnet.net> wrote:
> If you could fix and/or send a patch for these fixes to the list (or post
> them to sourceforge) i'm sure the developers would be greatly
> appreciatiave or however you spell that.  And if your in the process of
> this already..  tell me to shutup :)

I'm sure they would, too, but I don't know Python, and Lenny said he
doesn't, either.  I don't have time to learn Python just to make
patches to Mailman, but it's not doing anyone any good for us to sit on
the bugs we aren't able to fix ourselves.

Bugs should be reported.  All the better if you can submit patches, too.

Now, on that topic: Any responses to the last bug I reported (with a
patch) regarding rmlist?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@python.org  Mon Jun 19 07:12:30 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:12:30 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
References: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
Message-ID: <14669.47566.224850.953941@anthem.concentric.net>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> TypeError: not enough arguments; expected 7, got 4

Patch appended.

-Barry

Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- admindb.py	2000/06/15 21:01:51	1.25
+++ admindb.py	2000/06/19 06:11:18	1.26
@@ -213,7 +213,7 @@
             # TBD: kludge to remove id from requests.db.  value==2 means
             # discard the message.
             try:
-                mlist.HandleRequest(id, 2, None)
+                mlist.HandleRequest(id, 3, None, None, None, None)
             except Errors.LostHeldMessage:
                 pass
             return


From bwarsaw@python.org  Mon Jun 19 07:17:41 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:17:41 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
References: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
 <Pine.LNX.4.21.0006172301570.27164-100000@dogpound.vnet.net>
Message-ID: <14669.47877.911786.626295@anthem.concentric.net>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> It might help if you tell us a bit more about what you were
    MD> doing at hte time you got this problem.  What did you click?
    MD> What page was it from? What were you doing at the time?  What
    MD> color were your socks when this happened?

Who wears socks?

:)


From bwarsaw@python.org  Mon Jun 19 07:19:46 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:19:46 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
References: <20000618033202.1565D1CE28@dinsdale.python.org>
 <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <14669.48002.355282.202511@anthem.concentric.net>

>>>>> "paul" ==   <paul@cr355112-a.slnt1.on.wave.home.com> writes:

    paul> I get this message daily: Subject: Cron <mailman@stout>
    paul> /usr/bin/python /usr/local/mailman/cron/checkdbs

This will be fixed in 2.0b3, which I had hoped to release this
weekend.  I found a last minute bug so the release will probably
happen sometime Monday.

-Barry


From bwarsaw@python.org  Mon Jun 19 07:52:22 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:52:22 -0400 (EDT)
Subject: [Mailman-Developers] Re: Re: Various mailman bugs (all in 2.0beta2
References: <20000618185750.H7911@smack.uchicago.edu>
 <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>
 <20000618201236.L7911@smack.uchicago.edu>
Message-ID: <14669.49958.574736.903273@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> Bugs should be reported.  All the better if you can submit
    DC> patches, too.

Please start using the SourceForge bug manager for reporting bugs.  I
don't have enough experience to know yet, but I hope it's better than
Jitterbug.

-Barry


From mentor@alb-net.com  Mon Jun 19 11:24:15 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Mon, 19 Jun 2000 06:24:15 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS "reject" option gives
Message-ID: <Pine.GSO.4.21.0006190620120.20851-100000@alb-net.com>

latest CVS...

If you try to reject a message in "Tend to pending administrative
requests", you get an error 
"TypeError: object does not support item deletion"
Then, if you go back to "Tend to pending administrative requests" shows the
rejected messages as lost.....

later,
mentor



From mss@transas.com  Mon Jun 19 13:11:11 2000
From: mss@transas.com (Michael Sobolev)
Date: Mon, 19 Jun 2000 16:11:11 +0400
Subject: [Mailman-Developers] mailman seems to ignore Content-Transfer-Encoding
Message-ID: <20000619153411.A19742@transas.com>

I have a problem here.  It's pretty simple (I believe).. :)

The messages sent to the mailling list have Content-Transfer-Encoding equal to
base64 or quoted-printable.  Mailing list software just adds its usual
blah-blah-blah (mailing-list, url, etc).  When such a message arrives to the
recipient, MUA processes the body according to the header's value, and the
users sees garbage.  What can I do (beside modifying the source :)?

Thanks,

--
Misha



From jmackenzie@local.ie  Mon Jun 19 17:48:21 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Mon, 19 Jun 2000 17:48:21 +0100
Subject: [Mailman-Developers] Issues With Mailman 2.0 upgrade
Message-ID: <00061917523002.05445@samsara.local.ie>

Hey guys, 

Since upgrading to the beta I've had issues sending some of my lists. 
On certain lists when I go to approve It waits a little while and then returns
with a "document contained no data" box. 

Other lists Work fine but it just happens with these certain ones (it would
appear that its just the ones with high volume subscribers. 

Anyone Know the cause of this and how to sort it ?

Cheers

- John


 -- 

John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html 
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie
t: +353 1 676 8996  f: +353 1 283 9988


From dgc@uchicago.edu  Mon Jun 19 20:00:46 2000
From: dgc@uchicago.edu (David Champion)
Date: Mon, 19 Jun 2000 14:00:46 -0500
Subject: [Mailman-Developers] explicit bulk approval
Message-ID: <20000619140046.J27585@smack.uchicago.edu>

Three alternate proposals:
1. Implicit-approval addresses supercede "too many recipients" blocking
   -- i.e., if sender matches "posters", then "max_num_recipients" is
   irrelevant.
2. Same as #1, but only if some new boolean is true.
3. Same as #1, but using a different address list than "posters".

(Slap me, please, if this is already in a newer version of Mailman.)

Do these seem good?  I have no idea whether I can do them, so if
someone else wants to, be my guest.  It would be a while before I get
to it since I need to learn more Python first.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From ajohnson@mail.xperts.com  Mon Jun 19 21:28:04 2000
From: ajohnson@mail.xperts.com (Johnson, April)
Date: Mon, 19 Jun 2000 16:28:04 -0400
Subject: [Mailman-Developers] Possible MIME bug
Message-ID: <5B7C00CB140FD4119B4E00508BA54CD5018C52@mail.xperts.com>

We've encountered a problem that may be a bug.  It is caused when HTML-style
email
is posted to the mailing list from MS Outlook Express
for Macintosh (version 4.5 and 5 tested, possibly also Eudora).  The MIME
data from the
Outlook email cannot be correctly interpreted, so
the MIME headers show up in the email contents. 

Is this a known bug? Is there a fix available?  

April Johnson
Xperts, Inc.
(804) 967-0700 x174
http://www.xperts.com
http://www.xperts.org




From gorgo@sztaki.hu  Tue Jun 20 16:01:55 2000
From: gorgo@sztaki.hu (Gergely Madarasz)
Date: Tue, 20 Jun 2000 17:01:55 +0200 (MET DST)
Subject: [Mailman-Developers] Bug#65955: Resent-To and Resent-Cc should be considered explicit
 destinations. (fwd)
Message-ID: <Pine.GSO.4.10.10006201701000.22817-100000@lutra.sztaki.hu>

A small bug, with a patch included... 

-- 
Madarasz Gergely           gorgo@sztaki.hu           gorgo@linux.rulez.org
     It's practically impossible to look at a penguin and feel angry.
         Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                   HuLUG: http://mlf.linux.rulez.org/

---------- Forwarded message ----------
Date: Tue, 20 Jun 2000 15:09:05 +0200
From: Thomas Quinot <quinot@ada.eu.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#65955: Resent-To and Resent-Cc should be considered explicit
    destinations.
Resent-Date: Tue, 20 Jun 2000 14:59:53 +0000 (GMT)
Resent-From: Thomas Quinot <quinot@ada.eu.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-cc: Gergely Madarasz <gorgo@sztaki.hu>

Package: mailman
Version: 1.1-6
Severity: normal

Currently, mailman only takes To: and Cc: headers into account to
determine whether a message was explicitly sent to a mailing list.
The Resent-To: and Resent-Cc: headers should be used as well. The following
patch is a proposed solution to this problem:

--- MailList.py.dist	Thu Jun  1 00:26:48 2000
+++ MailList.py	Tue Jun 20 15:04:06 2000
@@ -1118,7 +1118,8 @@
 	lowname = string.lower(self.real_name)
         recips = []
         # First check all dests against simple name:
-        for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'):
+        for recip in msg.getaddrlist('to') + msg.getaddrlist('cc') \
+            + msg.getaddrlist('resent-to') + msg.getaddrlist('resent-cc'):
             curr = string.lower(string.split(recip[1], '@')[0])
 	    if lowname == curr:
 		return 1

-- System Information
Debian Release: 2.2
Architecture: sparc
Kernel: Linux marvin 2.2.14 #2 Mon Feb 21 16:52:43 CET 2000 sparc64

Versions of packages mailman depends on:
ii  apache                1.3.9-13.1         Versatile, high-performance HTTP s
ii  apache [httpd]        1.3.9-13.1         Versatile, high-performance HTTP s
ii  cron                  3.0pl1-57          management of regular background p
ii  libc6                 2.1.3-10.0.1       GNU C Library: Shared libraries an
ii  logrotate             3.2-11             Log rotation utility              
hi  postfix [mail-transpo 0.0.19991231pl05-2 A mail transport agent            
ii  python-base           1.5.2-10           An interactive object-oriented scr




From klm@digicool.com  Tue Jun 20 22:55:13 2000
From: klm@digicool.com (Ken Manheimer)
Date: Tue, 20 Jun 2000 17:55:13 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
Message-ID: <14671.59457.568158.148145@korak.digicool.com>

When i left CNRI for Digital Creations, i thought i might continue
with mailman development, but that didn't wind up happening.  However,
i'm still pretty darn enthusiastic about the benefits of using Zope
stuff for mailman, and seeing Andrew Kuchling's recent ZODB/ZEO
introduction:

  http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

brings home the point pretty well - i think many of mailman's burning
issues would best be solved using ZODB and ZEO.

ZODB is the Zope Object DataBase, and ZEO is the Zope Enterprise
Option - multiple concurrent access to a single database.

Where would this help?  Lots and lots of places.  Mailman wants a
persistent object store, badly.  Anytime mailman does something with a
maillist, an instance of the Maillist class is instantiated, which
then fetches its instance information from a marshalled dictionary in
the filesystem.  Unless the activity is sure to *not* involve any
state changes, the maillist in question is locked - since multiple
instances of the maillist are separate copies.  !

Lots of stuff is jammed into the current, feeble persistence
mechanism, beyond the basic maillist state - stuff like subscriber
information, messages caught for administrative approval (though that
may be changing), maybe other stuff.  This means that not only are
multiple concurrent instances of a maillist distinct, disassociated
copies, but also that there's no way to share these other components
between them, without going to other storage.  (Other storage, eg the
filesystem, for things like the message delivery queues.)

Imagine, instead, that maillist instances and the other components
were implemented as persistent objects in the ZODB, which is reached
from the web, email, news, and command line interfaces with
lightweight scripts that plug into ZEO.  ZODB, being transactional,
would handle conflict resolution - no more locking performance or
misbehavior hassles - and the Connection class cache would take care
of rolling stuff in and out based on activation, for good
responsiveness and memory performance.

Messages going through the system could be implemented as persistent
objects in their own right.  This is useful for mediated transmission
through the message pipline, and also for retention for archival
purposes.  (Maybe the message store would be a separately mounted
ZODB, tuned for use as a smart archive, with provisions for good
cataloguing, message annotations, etc.)  Multiple threads in the
delivery pipeline could be processing the messages at once - for
parallel news gatewaying and mail transmission.  Messages held for
approval would already be in a kind of archive - currently, they're
held as message objects in the respective maillists, and are
marshalled and unmarshalled with the maillist state.  Bogus!

How are subscribers currently represented?  Urgh.  Last i knew, they
were manifest in scattered places in the maillist structure - entries
in the members or digest_members attributes, for membership info, with
parallel entries in the passwords (or somename like that) dictionary,
and probably elsewhere.  Unless this has since changed, they weren't
instance objects, but scattered data, and most importantly, they're
specific to each list.  Bogus!

This last may be the most telling failing of the current maillist-
marshal based persistence mechanism - it's neither unified nor
transparent, so there's no easy way to share state between lists.
Judicious use of ZODB plus ZEO could solve all that, making it easy to
represent the components of the system - mailling lists, members,
messages, etc - as real objects, with transparent, transactional
persistence and concurrent access built in.

My cries of "bogus", above, should not be taken as condemnation.  I
still think mailman is great - i'm pretty pleased to see the way it
has taken off.  I do think that the current architecture has severe
limitations, in particular, it will continue to involve great pain
with filesystem locking, obstruction to unified membership, etc.  And
i think that a concurrent persistent object system is the right way to
deal with this - and ZODB plus ZEO are just about ideal prospects for
providing that...

Take a look at the andrews description - 

  http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

Ken Manheimer
klm@digicool.com


From jim@cosource.com  Wed Jun 21 00:32:36 2000
From: jim@cosource.com (Jim Hebert)
Date: Tue, 20 Jun 2000 19:32:36 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <14671.59457.568158.148145@korak.digicool.com>
Message-ID: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, Ken Manheimer wrote:

[awesome stuff snipped]

Ken, thanks for brining this up! I too have been sitting here thinking
about how Zope stuff could really be beneficial to Mailman (I was esp.
thinking this during the recent discussion of the need for a pipermail
successor). But I figured I was too green to be so impetuous. =)

To some, making mailman depend on peices of zope might be ornerous, but to
me it's a better call than hooking it directly up to something like
postgres (which I've heard batted around) and gets you a whole lot more,
too. I run zope and mailman one several machines for work and play and
would love to see them working even better together. Getting list data
into the Zope db puts mailman within striking distance of resting other
things on zope's shoulders, such as the web interface (one which can then
look like the rest of the web site), a pipermail successor, etc.

While your suggestions obviously aren't something that can be talked about
for 2.0 (ever notice how many great ideas come out right before you issue
a release candidate for something? :->), I'd love to know what the take is
on this for some future major release from the current Mailman gods? And,
more importantly, how can we help make it happen?

jim

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From claw@kanga.nu  Wed Jun 21 01:17:43 2000
From: claw@kanga.nu (J C Lawrence)
Date: Tue, 20 Jun 2000 17:17:43 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: Message from Jim Hebert <jim@cosource.com>
 of "Tue, 20 Jun 2000 19:32:36 EDT." <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
Message-ID: <21635.961546663@kanga.nu>

On Tue, 20 Jun 2000 19:32:36 -0400 (EDT) 
Jim Hebert <jim@cosource.com> wrote:

> To some, making mailman depend on peices of zope might be
> ornerous, but to me it's a better call than hooking it directly up
> to something like postgres (which I've heard batted around) and
> gets you a whole lot more, too...

The problem with this is that there are a large number (majority?)
of Mailman users who specifically don't want to run Zope but do want
to run Mailman.  Bolting the ZODB underneath Mailman is not a Bad
Idea, but at the same time, for sites that already have all their
data in an SQL database, it doesn't solve their problems of
integrating Mailman with their other infrastructure (web acocunts,
LDAP, customer catabases, third part databases, etc).  As such,
Mailman moving to ZODB for them is a losing situation.

Should Mailman gain a database abstraction which allows ZODB or a
variety of SQL databases to be plugged in underneath, everybody wins
_and_ you provide an easy migration path for those people who later
want to move over to Zope proper.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From chuqui@plaidworks.com  Wed Jun 21 01:19:02 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 17:19:02 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
Message-ID: <p04320407b575b874c134@[209.239.169.197]>

At 7:32 PM -0400 6/20/2000, Jim Hebert wrote:

>Ken, thanks for brining this up! I too have been sitting here thinking
>about how Zope stuff could really be beneficial to Mailman

very, very intriguing. Looks like almost a gut job rewrite, though -- 
it seems to me we're talking about an "Apache 2.0" class job, so not 
only isn't this Mailman 2.0, it's unclear if it's Mailman 2.x -- 
perhaps mailman 3.0? But -- it looks really interesting. It sure 
ought to be investigated.

>too. I run zope and mailman one several machines for work and play and
>would love to see them working even better together. Getting list data
>into the Zope db puts mailman within striking distance of resting other
>things on zope's shoulders, such as the web interface (one which can then
>look like the rest of the web site), a pipermail successor, etc.

Me, I've been mulling over a couple of things -- one being a hotmail 
clone type of system, another being an egroups clone type of system. 
I'm thinking, at first glance, that if you do a Zope integration, 
when you come out the other side, you don't have Mailman any more, 
but instead you have an egroups clone instead. And it may well be 
that you need (or want) both, although not at the same time. not all 
Mailman users are going to want, need, or be able to use the whole 
zope world -- let's not forget that Mailman lives in a lot of places 
where you don't have a dedicated machine. Not everyone can get a Zope 
environment installed on them. So perhaps something this significant 
is its own universe, not Mailman -- and Mailman continues forward in 
parallel, serving different needs?

In fact, with a little thinking, you can build a system that is a 
hotmail clone, an egroups clone, and handles mailman's functionality, 
all together. A little thinking (hah!) and a lot of work...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Wed Jun 21 02:27:01 2000
From: jim@cosource.com (Jim Hebert)
Date: Tue, 20 Jun 2000 21:27:01 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <p04320407b575b874c134@[209.239.169.197]>
Message-ID: <Pine.LNX.4.10.10006202049590.14118-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, Chuq Von Rospach wrote:

> I'm thinking, at first glance, that if you do a Zope integration, 
> when you come out the other side, you don't have Mailman any more, 

Ah, here's where I kick myself for throwing out the post I was going to
write the other day during the pipermail thread. =)

I agree with that, but at the same time I think (as you do, I think, see
what I've quoted below) that with the right OO strategies you can come up
with a large number of classes, the ones that do a lot of the low-level
work, that are common to both. I (embarrasingly) haven't taken the time to
try to draw up what such a interface would look like, for all I know the
existing class structure for Mailman is perfect and what I'm describing is
just additional code rather than changes to existing stuff. =)

> In fact, with a little thinking, you can build a system that is a 
> hotmail clone, an egroups clone, and handles mailman's functionality, 
> all together. A little thinking (hah!) and a lot of work...

Indeed, though whereas you're thinking "all together" I may be thinking of
a separation of packages like, say,

mailman-libs: the common set, as above
mailman-db-adapter(s): the db abstraction, like J C mentioned
mailman-zope: the stuff to implement lots-o-stuff in zope (see my prev msg)
mailman-?: the stuff to implement the traditional stuff as cgi's, etc

That's a mighty tall suggestion relative to the amount of code I've
written, I know. =) I'm sure Barry is reading all of this and slapping his
forehead like "Oy! More work? Easy for them to say!" =)

If I should just leave mailman out of this and go subscribe to a zope list
and talk about a from-scratch effort there, a tap with a LART is all it'll
take. =)

jim
who had thought about trying to go off and write a mlm in zope all by
himself for all of about 10 seconds. =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox





From jim@cosource.com  Wed Jun 21 05:18:28 2000
From: jim@cosource.com (Jim Hebert)
Date: Wed, 21 Jun 2000 00:18:28 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <21635.961546663@kanga.nu>
Message-ID: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, J C Lawrence wrote:

> Should Mailman gain a database abstraction which allows ZODB or a
> variety of SQL databases to be plugged in underneath, everybody wins

Just for the same of completeness and/or if you missed it in my reply to
Chuq, I totally agree with this. Given such an abstraction, they who
wanted Zope integration can go about getting it done, which may just be me
'n' Ken for all I know. ;-)

ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
leaving zope enthusiasts to start a side project, namely "get a DB-API
interface to the ZODB" ? There's some pretty big "up" sides to that
approach. =)

jim




From chuqui@plaidworks.com  Wed Jun 21 05:22:27 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 21:22:27 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
Message-ID: <p04320401b575f3368e58@[209.239.169.197]>

At 12:18 AM -0400 6/21/2000, Jim Hebert wrote:

>ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
>leaving zope enthusiasts to start a side project, namely "get a DB-API
>interface to the ZODB" ? There's some pretty big "up" sides to that
>approach. =)

Seems to me that if you add a DBI interface, you can make a clean 
break from the current DB stuff while keeping compatibility with it. 
And then Zope does a DBI interface, and it's a generic addition to 
Zope that comes in handy for more than mailman.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mailman-developers@python.org  Wed Jun 21 05:35:39 2000
From: mailman-developers@python.org (John Morton)
Date: Wed, 21 Jun 2000 16:35:39 +1200 (NZST)
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
Message-ID: <200006210435.QAA02259@vesta.plain.co.nz>

On Wed, 21 Jun 2000 00:18:28 -0400 (EDT) you wrote:

 > On Tue, 20 Jun 2000, J C Lawrence wrote:
 >=20
 > > Should Mailman gain a database abstraction which allows ZODB or a
 > > variety of SQL databases to be plugged in underneath, everybody wins
 >=20
 > Just for the same of completeness and/or if you missed it in my reply to
 > Chuq, I totally agree with this. Given such an abstraction, they who
 > wanted Zope integration can go about getting it done, which may just be =
me
 > 'n' Ken for all I know. ;-)
=20
Sounds great to me. In fact I think that, with a bit of negotiation with
DC, the ZODB part of Zope could be distributed as a separate library with
appropriate license terms so that Mailman can use it as Just Another
Python Module, without depending on Zope being installed.=20

At the other end of the program, a similar API for the web interface stuff
would be enormously useful. I'd like to implement a Mailman interface with
Zope, and I'm sure other people would like to use PHP/mod_perl/Cold
Fusion/ASP and so forth.

 > ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
 > leaving zope enthusiasts to start a side project, namely "get a DB-API
 > interface to the ZODB" ? There's some pretty big "up" sides to that
 > approach. =3D)

As Mailman will still have to have a 'native' data store, setting up the
API to be a collection of functions that fetch data from storage and place
them into python structures of one form or another seams to be the best
bet.=20

John
(Long time lurker, first time poster).




From petrilli@amber.org  Wed Jun 21 06:07:04 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Wed, 21 Jun 2000 01:07:04 -0400
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <200006210435.QAA02259@vesta.plain.co.nz>; from jwm@plain.co.nz on Wed, Jun 21, 2000 at 04:35:39PM +1200
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com> <200006210435.QAA02259@vesta.plain.co.nz>
Message-ID: <20000621010704.B22544@trump.amber.org>

John Morton [jwm@plain.co.nz] wrote:
> On Wed, 21 Jun 2000 00:18:28 -0400 (EDT) you wrote:
> 
>  > On Tue, 20 Jun 2000, J C Lawrence wrote:
>  > 
>  > > Should Mailman gain a database abstraction which allows ZODB or a
>  > > variety of SQL databases to be plugged in underneath, everybody wins
>  > 
>  > Just for the same of completeness and/or if you missed it in my reply to
>  > Chuq, I totally agree with this. Given such an abstraction, they who
>  > wanted Zope integration can go about getting it done, which may just be me
>  > 'n' Ken for all I know. ;-)
>  
> Sounds great to me. In fact I think that, with a bit of negotiation with
> DC, the ZODB part of Zope could be distributed as a separate library with
> appropriate license terms so that Mailman can use it as Just Another
> Python Module, without depending on Zope being installed. 


As someone else at DC, I can speak for two issues.  I don't think we'd 
be opposed to separate distributions of ZODB/ZEO, this has always been 
kept as clean as possible, but there are some dependencies (like
ZServer for doing the Client/Server piece).  As for license,
well... it's our license, which is Open Source, but I don't know how
that will fly with the GPL-nazis.  My time at the FSF (many many years 
ago) leads me to believe it'd not go over well, and would make this
all a non-starter.

As for a DB-API interface, that would pretty well negate using ZODB,
since DB-API is aimed at ractangular data, not rich objects.  You
would need to create an abstraction layer much higher than that. More
like an O-R mapping (a'la EOF, or whatever).

Chris
--
| Christopher Petrilli
| petrilli@amber.org


From chuqui@plaidworks.com  Wed Jun 21 06:43:37 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 22:43:37 -0700
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <20000621010704.B22544@trump.amber.org>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
 <200006210435.QAA02259@vesta.plain.co.nz>
 <20000621010704.B22544@trump.amber.org>
Message-ID: <p04320404b57605d0eccf@[209.239.169.197]>

At 1:07 AM -0400 6/21/2000, Christopher Petrilli wrote:

>As for a DB-API interface, that would pretty well negate using ZODB,
>since DB-API is aimed at ractangular data, not rich objects.  You
>would need to create an abstraction layer much higher than that. More
>like an O-R mapping (a'la EOF, or whatever).

So if I get this correctly, there needs to be an API involved that 
could interact with DB, DBI or ZODB, much as the DBI layer abstracts 
MySQL, PostGres, ODBC, et al.

That actually isn't a bad idea at all, since the first thing that can 
be done is defining the abstraction layer for the API, then building 
the DB interface to it so that existing systems can migrate and keep 
existing systems. And then that can be extended to support the other 
data stores as time and need meet with resources and volunteers. 
That's probably the cleanest answer anyway, since the first thing 
that happens is you build the API into an existing system, so you 
isolate the complexity of defining the API and building in the new 
datastores.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Wed Jun 21 06:57:23 2000
From: jim@cosource.com (Jim Hebert)
Date: Wed, 21 Jun 2000 01:57:23 -0400 (EDT)
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <200006210435.QAA02259@vesta.plain.co.nz>
Message-ID: <Pine.LNX.4.10.10006210152140.14319-100000@ray.compu-aid.com>

On Wed, 21 Jun 2000, John Morton wrote:

> As Mailman will still have to have a 'native' data store, setting up the
> API to be a collection of functions that fetch data from storage and place
> them into python structures of one form or another seams to be the best
> bet. 

Well, as for 'native' data store in a world where DB-API was the only
abstraction we'd have, I was thinking Gadfly or something in that spirit.

<abandoning ship>

But, that said, Chuq's latest post made me realize the need to accomodate
existing installations and migrating existing data. So, rather than go for
the slam-dunk pure-db-api with nothing on top of it, I am coming back
around in my own mind to J C's original proposal that there'd need to be
some sort of custom abstraction layer. =)

jim
who used to think he was indecisive, but now he's not so sure...

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From bernhard@intevation.de  Wed Jun 21 11:28:16 2000
From: bernhard@intevation.de (Bernhard Reiter)
Date: Wed, 21 Jun 2000 12:28:16 +0200
Subject: [Mailman-Developers] New beta release needed (+ little patch)
Message-ID: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>

--6b3yLyRKT1M6kiA0
Content-Type: multipart/mixed; boundary="wj9ZLJVQDRFjGSdK"


--wj9ZLJVQDRFjGSdK
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

It looks like a new mailman beta or even pre beta release is badly=20
needed. I had to make to many little adjustments to 2.0b2.
(Also see my mail to mailman-users in April.)

So please release a bug-fix version. I see people going for the CVS
version. This creates a lot of work for people who just want to run
mailman in a stable way.

Here is another little patch so that error messages for external
archivers do not get lost. (You have to other chance to get that
information.)

Regards,
	Bernhard

--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project				            (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)

--wj9ZLJVQDRFjGSdK
Content-Type: text/plain; charset=us-ascii
Content-Description: Patch to log error messages from external archivers
Content-Disposition: attachment; filename="2.0beta2.local4.diff"
Content-Transfer-Encoding: quoted-printable

--- Mailman/Archiver/Archiver.py.org	Tue Jun 20 21:30:00 2000
+++ Mailman/Archiver/Archiver.py	Tue Jun 20 21:38:45 2000
@@ -180,8 +180,10 @@
         status =3D extarch.close()
         if status:
             self.LogMsg('error',
-                        'external archiver non-zero exit status: %d\n' %
-                        (status & 0xff00) >> 8)
+                        'external archiver non-zero exit status: %d\n'=20
+			'\t while piping mail into:\n'
+			'\t\"%s\"' %
+                        ((status & 0xff00) >> 8,cmd) )
=20
     #
     # archiving in real time  this is called from list.post(msg)

--wj9ZLJVQDRFjGSdK--

--6b3yLyRKT1M6kiA0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (SunOS)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjlQmL0ACgkQh9ag3dpKERb7pQCfd+KEvtcnTLwSCfgH8Ddp+2Wd
qrAAoNfWpsES3z6WbbrOl834+Ki9ihfo
=iwGE
-----END PGP SIGNATURE-----

--6b3yLyRKT1M6kiA0--


From paul@cr355112-a.slnt1.on.wave.home.com  Wed Jun 21 15:29:22 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Wed, 21 Jun 2000 10:29:22 -0400 (EDT)
Subject: [Mailman-Developers] Wildcards in E-mail list...
In-Reply-To: <Pine.LNX.4.10.10006180313350.12633-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <Pine.LNX.4.10.10006211026450.18820-100000@cr355112-a.slnt1.on.wave.home.com>

Is there a way to use wildcards in the "Addresses of members accepted for
posting"(privacy options) box ?

Thanks
___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca



From edelrio@icm.csic.es  Thu Jun 22 09:18:32 2000
From: edelrio@icm.csic.es (Evilio del Rio)
Date: Thu, 22 Jun 2000 10:18:32 +0200 (CEST)
Subject: [Mailman-Developers] Re: [Mailman-Users] Domain allowed to post to a list.
In-Reply-To: <394F9967.B4E77C6D@dcu.ie>
Message-ID: <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Jun 2000, Fergus Donohue wrote:

> 
> Hi,
> 
> Could someone give me some info on the following? I want to allow all
> users in a particular mail domain to post to a list - I've searched the
> archives and found the answer "add @domain.tld to the field Addresses of
> members accepted for posting to this list without implicit approval
> requirement."  I've tried this and also some regular expression
> variations on it and can't get it to work. I also tried the same in
> "Addresses always held for Approval" (making the list open and add a
> regex to hold anything not in domain @domain.tld). Again no luck! Can
> someone give me an example of how they're doing this?
> 
> Thanks,
> 
> Fergus Donohue.
>
[Note: I have already sent a message similar to this one 
	but I had no reply.]

Hi Fergus,

Some days ago I was searching for the same feature. AFAIK, this is not
possible with the current stable distribution (I haven't tried with
the developement one).

Now the good news: it is easy to patch Mailman to accept a regular
expression as the "posters" settings (addresses allowed to post to a
restricted list even if they are not members). I have patched the
following file:

/home/mailman/Mailman/Handlers/Hold.py

(/home/mailman is where I installed it)

The result of the "diff" between the patched file vs. the
original one are (you can use patch if you want to try):

32a33
> import re
120c121,123
<         posters = Utils.List2Dict(map(string.lower, mlist.posters))
- ---
>       isposter = 0
>       for poster in mlist.posters:
>               isposter = isposter or re.compile(poster,
re.I).match(sender)
122c125
<            not Utils.FindMatchingAddresses(sender, posters):
- ---
>            not isposter:

Then, you must set the "posters" settings to something like that:

	.+@my.domain.com

If you do it via Web it's on the "Privacy Options", under the label
"Addresses of members accepted for posting (...) in addition to allowing
posting by list members"

or if you use /home/mailman/bin/config_list, you must set the following in
the input config file:

	posters = ['.+@my.doma.in']

I would like to know if this is works for you.

I would also like to hear some comments about this patch because I am a
begginer in python and I do not know quite well if this is the correct
place to implement this feature. I propose that this or a similar feature 
must be included in the standard Mailman distribution (that's why I send
this message to the developers list)

HTH,

________________________________________________________________
Evilio Jose del Rio Silvan          Institut de Ciencies del Mar
edelrio@icm.csic.es          http://members.es.tripod.de/Evilio/
"He tingut una idea" - Joan Gamper, 27 de novembre de 1899
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5UcviBYZlGm2iEEIRAme1AJ47QhAOgebJe+sEItgyYoF4zRDz/wCfZOUt
EzKh2jX5gWMcSzNlCzlOqxY=
=JUaF
-----END PGP SIGNATURE-----




From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From Dan.Mick@west.sun.com  Wed Jun 21 21:22:22 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 13:22:22 -0700
Subject: [Mailman-Developers] Wildcards in E-mail list...
References: <Pine.LNX.4.10.10006211026450.18820-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <395123FE.86485F07@west.sun.com>


paul wrote:
> 
> Is there a way to use wildcards in the "Addresses of members accepted for
> posting"(privacy options) box ?

It looks to me like the answer is "no" for 1.1, and I don't see anything
different for 2.0.


From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From Dan.Mick@west.sun.com  Wed Jun 21 22:42:50 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:42:50 -0700
Subject: [Mailman-Developers] SMTPDirect doesn't log to 'posts'
Message-ID: <395136DA.26363FB7@west.sun.com>

Just decided to be brave and install the current 2.0 CVS on top of my 1.1
list.  So far so good....but I see no posts in "logs/post".  Is this 
intentional with SMTPDirect (the default Handler), and if so, why?
post is a useful little log to make sure things are getting through.


From Dan.Mick@west.sun.com  Wed Jun 21 22:48:33 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:48:33 -0700
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <39513831.A47AB59F@west.sun.com>

I had to fix this bug, which was reported in May, before I could use the current
CVS:

dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
182c182
<             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
---
>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)

Could someone with putback access clean this up, please?


From Dan.Mick@west.sun.com  Wed Jun 21 22:48:33 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:48:33 -0700
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <39513831.A47AB59F@west.sun.com>

I had to fix this bug, which was reported in May, before I could use the current
CVS:

dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
182c182
<             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
---
>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)

Could someone with putback access clean this up, please?


From Dan.Mick@west.sun.com  Wed Jun 21 23:06:47 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 15:06:47 -0700
Subject: [Mailman-Developers] Errors with current CVS
Message-ID: <39513C77.C2B79C04@west.sun.com>

Also getting errors like this:

Jun 21 14:49:09 2000 post(10558): Traceback (innermost last):
post(10558):   File "/export/home/mailman/scripts/mailowner", line 89, in ?
post(10558):      main()
post(10558):   File "/export/home/mailman/scripts/mailowner", line 79, in main
post(10558):      enqueue = HandlerAPI.DeliverToUser(mlist, msg, msgdata)
post(10558):   File "/export/home/mailman/Mailman/Handlers/HandlerAPI.py", line
146, in DeliverToUser
post(10558):      msgdata = {'pipeline' : pipeline,
post(10558): AttributeError :  recips

still trying to track down.


From Dan.Mick@west.sun.com  Wed Jun 21 23:20:16 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 15:20:16 -0700
Subject: [Mailman-Developers] Another bug in current CVS
Message-ID: <39513FA0.212BB633@west.sun.com>

scripts/mailowner calls HandlerAPI.DeliverToUser; in doing so, it must set msg.recips,
but doesn't.  

Here's a patch.

*** mailowner.orig      Wed Jun 21 15:13:54 2000
--- mailowner   Wed Jun 21 15:14:19 2000
***************
*** 76,81 ****
--- 76,82 ----
          msgdata = {'recips' : recips,
                     'toadmin': 1,
                     }
+       msg.recips = recips
          enqueue = HandlerAPI.DeliverToUser(mlist, msg, msgdata)
          if enqueue:
              msg.Enqueue(mlist, newdata=msgdata)


What's going on?  How am I running into all this stuff?  I thought others were
running the current CVS?


From Dan.Mick@west.sun.com  Thu Jun 22 01:20:52 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 17:20:52 -0700
Subject: [Mailman-Developers] test
Message-ID: <39515BE4.DFA16FA4@west.sun.com>

 


From Nigel.Metheringham@VData.co.uk  Thu Jun 22 13:51:20 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Thu, 22 Jun 2000 13:51:20 +0100
Subject: [Mailman-Developers] Indexing pipermail archives
Message-ID: <E1356S0-00036L-00@rioja.localnet>

I've just been looking at the problem of indexing/searching a large 
Mailman/pipermail archive.

htdig will do the job, but the (htdig) indexes get bloated by the 
pipermail index pages (which are *very* rarely what you want when 
searching for something).

Indexing can be controlled by meta tags.  [See http://info.webcrawler.co
m/mak/projects/robots/meta-user.html ].  The pipermail HTML generation 
is hard coded into the archiver code.

As a short term fix, would people be happy with me adding the following 
meta tags to the pipermail HTML generation:-

  On top level (ie list of weeks/months etc) and by-date index pages:-
     <meta name="robots" content="noindex,follow">
	[ie do not index the page, follow links down to the articles]

  On thread/subject/author indexes
     <meta name="robots" content="noindex,nofollow">
        [skip page and linked pages - nofollow is superluous since the
	indexing robot should realise that the pages are already included
	but it doesn't hurt much]

  On article pages
     <meta name="robots" content="index,nofollow">
	[you may disagree with the nofollow, but I think there is no general
	requirement for the indexer to follow links off the list]

Its a hack for now, but will make htdig and other indexing robots 
behave better.

Comments?

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From ckolar@admin.aurora.edu  Thu Jun 22 15:37:46 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Thu, 22 Jun 2000 09:37:46 -0500
Subject: [Mailman-Developers] Fwd: Mailman error messages.
Message-ID: <4.3.2.7.2.20000622093659.00d10e00@admin.aurora.edu>

--=====================_64945825==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

This was sent to me by someone.  No need to reply directly to me, and the 
person is not on the list.

--chris



>From: "czh" <tonytsai@ec.dayi.com>
>To: <ckolar@admin.aurora.edu>
>Subject: Mailman error messages.
>Date: Thu, 22 Jun 2000 14:30:43 +0800
>X-Mailer: Microsoft Outlook Express 5.00.2615.200
>
>Hi Ckolar,
>I just want to install Mailman into my Slackware, but got the error messages,
>   ---------------- Begin of error messages  -------------
>
>
>Bug in Mailman version 2.0beta2
>
>
>
>
>
>We're sorry, we hit a bug!
>
>
>
>If you would like to help us identify the problem, please email a copy of 
>this page to the webmaster for this site with a description of what 
>happened. Thanks!
>
>Traceback:
>
>
>
>
>Traceback (innermost last):
>   File "/home/mailman/scripts/driver", line 64, in run_main
>     immediate=1)
>   File "/home/mailman/Mailman/Logging/StampedLogger.py", line 49, in __init__
>     Logger.__init__(self, category, nofail, immediate)
>   File "/home/mailman/Mailman/Logging/Logger.py", line 40, in __init__
>     self.__get_f()
>   File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f
>     f = self.__fp = open(self.__filename, 'a+', 1)
>IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'
>
>
>
>----------
>
>
>Python information:
>
>
>
>Variable Value
>sys.version 1.5.2 (#1, Jul 17 1999, 22:10:16) [GCC egcs-2.91.66 
>19990314/Linux (egcs-
>sys.executable /usr/bin/python
>sys.prefix /usr
>sys.exec_prefix /usr
>sys.path /usr
>sys.platform linux2
>
>
>----------
>
>
>Environment variables:
>
>
>
>Variable Value
>DOCUMENT_ROOT /usr/local/etc/httpd/htdocs
>SERVER_ADDR 203.74.9.7
>HTTP_ACCEPT_ENCODING gzip, deflate, gzip, deflate
>SERVER_PORT 443
>PATH_TRANSLATED /usr/local/etc/httpd/htdocs/abcde
>ssl_unclean_shutdown 1
>SERVER_PROTOCOL HTTP/1.1
>HTTP_ACCEPT_LANGUAGE zh-tw, zh-tw
>GATEWAY_INTERFACE CGI/1.1
>nokeepalive 1
>HTTP_CONNECTION Keep-Alive
>HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
>HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
>application/vnd.ms-powerpoint, application/vnd.ms-excel, 
>application/msword, */*
>REQUEST_URI /mailman/admin/abcde
>SERVER_NAME czh.dayi.com
>PATH 
>/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:/opt/kde/bin:/usr/share/texmf/bin 
>
>QUERY_STRING
>SCRIPT_FILENAME /home/mailman/cgi-bin/admin
>HTTPS on
>PATH_INFO /abcde
>HTTP_HOST czh.dayi.com
>REQUEST_METHOD GET
>SERVER_SIGNATURE Apache/1.3.12 Server at czh.dayi.com Port 443
>SCRIPT_NAME /mailman/admin
>SERVER_ADMIN root@czh.dayi.com
>SERVER_SOFTWARE Apache/1.3.12 (Unix) PHP/4.0.0 mod_ssl/2.6.4 OpenSSL/0.9.5a
>PYTHONPATH /home/mailman
>REMOTE_ADDR 203.74.9.62
>REMOTE_PORT 64731

--=====================_64945825==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
This was sent to me by someone.&nbsp; No need to reply directly to me,
and the person is not on the list.<br>
<br>
--chris<br>
<br>
<br>
<br>
<blockquote type=cite cite>From: &quot;czh&quot;
&lt;tonytsai@ec.dayi.com&gt;<br>
To: &lt;ckolar@admin.aurora.edu&gt;<br>
Subject: Mailman error messages.<br>
Date: Thu, 22 Jun 2000 14:30:43 +0800<br>
X-Mailer: Microsoft Outlook Express 5.00.2615.200<br>
<br>
<font size=2>Hi Ckolar,</font><br>
<font size=2>I just want to install Mailman into my Slackware, but got
the error messages,</font><br>
<font size=2>&nbsp; ---------------- Begin of error messages&nbsp;
-------------</font><br>
<font size=2><br>
</font><h2><b>Bug in Mailman version 2.0beta2</b></h2><font size=2><br>
<br>
<br>
</font><h3><b>We're sorry, we hit a bug!</b></h3><font size=2><br>
<br>
If you would like to help us identify the problem, please email a copy of
this page to the webmaster for this site with a description of what
happened. Thanks! <br>
</font><h4><b>Traceback:</b></h4><font size=2><br>
<br>
<br>
</font><pre>Traceback (innermost last):
&nbsp; File &quot;/home/mailman/scripts/driver&quot;, line 64, in
run_main
&nbsp;&nbsp;&nbsp; immediate=1)
&nbsp; File &quot;/home/mailman/Mailman/Logging/StampedLogger.py&quot;,
line 49, in __init__
&nbsp;&nbsp;&nbsp; Logger.__init__(self, category, nofail, immediate)
&nbsp; File &quot;/home/mailman/Mailman/Logging/Logger.py&quot;, line 40,
in __init__
&nbsp;&nbsp;&nbsp; self.__get_f()
&nbsp; File &quot;/home/mailman/Mailman/Logging/Logger.py&quot;, line 55,
in __get_f
&nbsp;&nbsp;&nbsp; f = self.__fp = open(self.__filename, 'a+', 1)
IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'


</pre><font face="Courier New, Courier"><hr>
</font><br>
<h4><b>Python information:</b></h4><br>
<br>
Variable Value<br>
<tt>sys.version</tt> 1.5.2 (#1, Jul 17 1999, 22:10:16) [GCC egcs-2.91.66
19990314/Linux (egcs- <br>
<tt>sys.executable</tt> /usr/bin/python <br>
<tt>sys.prefix</tt> /usr <br>
<tt>sys.exec_prefix</tt> /usr <br>
<tt>sys.path</tt> /usr <br>
<tt>sys.platform</tt> linux2 <br>
<br>
<hr>
<br>
<h4><b>Environment variables:</b></h4><br>
<br>
Variable Value<br>
<tt>DOCUMENT_ROOT </tt>/usr/local/etc/httpd/htdocs <br>
<tt>SERVER_ADDR </tt>203.74.9.7 <br>
<tt>HTTP_ACCEPT_ENCODING </tt>gzip, deflate, gzip, deflate <br>
<tt>SERVER_PORT </tt>443 <br>
<tt>PATH_TRANSLATED </tt>/usr/local/etc/httpd/htdocs/abcde <br>
<tt>ssl_unclean_shutdown </tt>1 <br>
<tt>SERVER_PROTOCOL </tt>HTTP/1.1 <br>
<tt>HTTP_ACCEPT_LANGUAGE </tt>zh-tw, zh-tw <br>
<tt>GATEWAY_INTERFACE </tt>CGI/1.1 <br>
<tt>nokeepalive </tt>1 <br>
<tt>HTTP_CONNECTION </tt>Keep-Alive <br>
<tt>HTTP_USER_AGENT </tt>Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;
DigExt) <br>
<tt>HTTP_ACCEPT </tt>image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */* <br>
<tt>REQUEST_URI </tt>/mailman/admin/abcde <br>
<tt>SERVER_NAME </tt>czh.dayi.com <br>
<tt>PATH
</tt>/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:/opt/kde/bin:/usr/share/texmf/bin
<br>
<tt>QUERY_STRING </tt><br>
<tt>SCRIPT_FILENAME </tt>/home/mailman/cgi-bin/admin <br>
<tt>HTTPS </tt>on <br>
<tt>PATH_INFO </tt>/abcde <br>
<tt>HTTP_HOST </tt>czh.dayi.com <br>
<tt>REQUEST_METHOD </tt>GET <br>
<tt>SERVER_SIGNATURE </tt>Apache/1.3.12 Server at czh.dayi.com Port
443<br>
<tt>SCRIPT_NAME </tt>/mailman/admin <br>
<tt>SERVER_ADMIN </tt>root@czh.dayi.com <br>
<tt>SERVER_SOFTWARE </tt>Apache/1.3.12 (Unix) PHP/4.0.0 mod_ssl/2.6.4
OpenSSL/0.9.5a <br>
<tt>PYTHONPATH </tt>/home/mailman <br>
<tt>REMOTE_ADDR </tt>203.74.9.62 <br>
<tt>REMOTE_PORT </tt>64731 </blockquote></html>

--=====================_64945825==_.ALT--



From dereks@kd-dev.com  Thu Jun 22 15:59:13 2000
From: dereks@kd-dev.com (Derek Simkowiak)
Date: Thu, 22 Jun 2000 07:59:13 -0700 (PDT)
Subject: [Mailman-Users] Re: [Mailman-Developers] New beta release needed
 (+ little patch)
In-Reply-To: <14672.58167.653957.234326@anthem.concentric.net>
Message-ID: <Pine.LNX.4.04.10006220758020.13822-100000@archer.kd-dev.com>

	Will the new release fix the broken-archiving-if-using-resend-date
bug?  (I'm not sure that ever got entered into the bug tracking database;
I never entered it)

--Derek


On Wed, 21 Jun 2000, Barry A. Warsaw wrote:

-> 
-> >>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:
-> 
->     BR> It looks like a new mailman beta or even pre beta release is
->     BR> badly needed. I had to make to many little adjustments to
->     BR> 2.0b2.  (Also see my mail to mailman-users in April.)
-> 
-> There will be one very soon now (within hours or at most a day).  I
-> was all set to push the button and we saw errors in the logs on
-> python.org, and duplicates in the digests.  I want to see if I can fix
-> that problem first.
-> 
-> -Barry
-> 
-> ------------------------------------------------------
-> Mailman-Users maillist  -  Mailman-Users@python.org
-> http://www.python.org/mailman/listinfo/mailman-users
-> 



From fife@AnywhereYouGo.com  Thu Jun 22 18:17:51 2000
From: fife@AnywhereYouGo.com (Ryan Fife)
Date: Thu, 22 Jun 2000 12:17:51 -0500
Subject: [Mailman-Developers] including subscribe address in message
Message-ID: <20000622121751.E8010@AnywhereYouGo.com>

Before I start looking into this I thought I'd check to see if it's already
been done/investigated.

I would like to include a line that says:

You are subscribed as: fife@AnwyhereYouGo.com

in the body of the message on the way out.  I know it will increase the
needed processing of messages tremendously, but it would be good for our
subscribers as well as the list admin (me!).  Our mail server doesn't have
anything better to do anyway...

-- 
Ryan Fife
fife@AnywhereYouGo.com
 Creators of the world's first online WAP testing tool:
 http://www.AnywhereYouGo.com/Content.po?name=lab/About


From chuqui@plaidworks.com  Thu Jun 22 18:20:03 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 22 Jun 2000 10:20:03 -0700
Subject: [Mailman-Developers] including subscribe address in
 message
In-Reply-To: <20000622121751.E8010@AnywhereYouGo.com>
References: <20000622121751.E8010@AnywhereYouGo.com>
Message-ID: <p04320401b577fb1b27ee@[17.216.27.193]>

At 12:17 PM -0500 6/22/2000, Ryan Fife wrote:
>Before I start looking into this I thought I'd check to see if it's already
>been done/investigated.
>
>I would like to include a line that says:
>
>You are subscribed as: fife@AnwyhereYouGo.com
>
>in the body of the message on the way out.

That requires extensions to the delivery stuff for what's known as 
VERPing. mailman doesn't do this yet.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From claw@kanga.nu  Thu Jun 22 20:23:12 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 22 Jun 2000 12:23:12 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Domain allowed to post to a list.
In-Reply-To: Message from Evilio del Rio <edelrio@icm.csic.es>
 of "Thu, 22 Jun 2000 10:18:32 EST." <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>
References: <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>
Message-ID: <660.961701792@kanga.nu>

On Thu, 22 Jun 2000 10:18:32 +0200 (CEST) 
Evilio del Rio <edelrio@icm.csic.es> wrote:

> Now the good news: it is easy to patch Mailman to accept a regular
> expression as the "posters" settings (addresses allowed to post to
> a restricted list even if they are not members). I have patched
> the following file:

Oooo.  This one should get into the next beta.  A whole bunch of
people would be very happy to see that.  Barry?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jarrell@vt.edu  Thu Jun 22 20:31:40 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Thu, 22 Jun 2000 15:31:40 -0400
Subject: [Mailman-Developers] Bug still in current CVS
In-Reply-To: <39513831.A47AB59F@west.sun.com>
Message-ID: <4.3.2.7.2.20000622152601.00dfbab0@vtserf.cc.vt.edu>

--=====================_27531745==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 02:48 PM 6/21/00 -0700, Dan Mick wrote:
>I had to fix this bug, which was reported in May, before I could use the current
>CVS:
>
>dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
>182c182
><             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
>---
>>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)
>
>Could someone with putback access clean this up, please?


Um, Dan, you sure you have the current CVS files?  I remember putting a very similar
fix in a couple of weeks ago that Barry committed.  And, in fact, that entire section
of code that used DeliverToList isn't in the current ListAdmin any more...

I show the current version of ListAdmin.py as being 1.41.  Looks like, from the log
messages that Barry put my patch in back in 1.33 on 5/30, then removed the entire
block of code when he switched to queueing admin requests, rather than delivering them
realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...

--=====================_27531745==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:48 PM 6/21/00 -0700, Dan Mick wrote:<br>
<blockquote type=cite cite>I had to fix this bug, which was reported in
May, before I could use the current<br>
CVS:<br>
<br>
dmick@we-24-30-117-227&gt; diff ListAdmin.py.orig ListAdmin.py<br>
182c182<br>
&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)<br>
---<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)<br>
<br>
Could someone with putback access clean this up,
please?</blockquote><br>
<br>
Um, Dan, you sure you have the current CVS files?&nbsp; I remember
putting a very similar<br>
fix in a couple of weeks ago that Barry committed.&nbsp; And, in fact,
that entire section<br>
of code that used DeliverToList isn't in the current ListAdmin any
more...<br>
<br>
I show the current version of ListAdmin.py as being 1.41.&nbsp; Looks
like, from the log<br>
messages that Barry put my patch in back in 1.33 on 5/30, then removed
the entire<br>
block of code when he switched to queueing admin requests, rather than
delivering them<br>
realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...<br>
</font></html>

--=====================_27531745==_.ALT--



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 22 22:07:17 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 14:07:17 -0700 (PDT)
Subject: [Mailman-Developers] Fwd: Mailman error messages.
Message-ID: <200006222106.OAA21493@utopia.west.sun.com>

> >IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'

So this makes the problem pretty clear; the permissions on the error
log are incorrect.  Yes?



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 22 22:09:19 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 14:09:19 -0700 (PDT)
Subject: [Mailman-Developers] including subscribe address in message
Message-ID: <200006222108.OAA21601@utopia.west.sun.com>

There's been a *lot* of discussion about similar things wrt MLMs in
general (qmail/ezmlm call this "VERP").

What it means is you must send N different messages, where N is
the number of subscribers on your list, whereas now you send
1 message with M connections, where M is usually significantly
less than M.  So you drastically increase both filesystem and
network load to do something like this.

Mailman doesn't currently support anything like this, although
a custom Handlers/ module in 2.x will make it a lot easier to 
drop such a thing in, from what I can tell.

> Before I start looking into this I thought I'd check to see if it's already
> been done/investigated.
> 
> I would like to include a line that says:
> 
> You are subscribed as: fife@AnwyhereYouGo.com
> 
> in the body of the message on the way out.  I know it will increase the
> needed processing of messages tremendously, but it would be good for our
> subscribers as well as the list admin (me!).  Our mail server doesn't have
> anything better to do anyway...



From Dan Mick <Dan.Mick@west.sun.com>  Thu Jun 22 22:14:17 2000
From: Dan Mick <Dan.Mick@west.sun.com> (Dan Mick)
Date: Thu, 22 Jun 2000 14:14:17 -0700 (PDT)
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <200006222113.OAA21753@utopia.west.sun.com>

> At 02:48 PM 6/21/00 -0700, Dan Mick wrote:
> >I had to fix this bug, which was reported in May, before I could use the 
current
> >CVS:
> >
> >dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
> >182c182
> ><             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
> >---
> >>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)
> >
> >Could someone with putback access clean this up, please?
> 
> 
> Um, Dan, you sure you have the current CVS files?  I remember putting a very 
similar
> fix in a couple of weeks ago that Barry committed.  And, in fact, that entire 
section
> of code that used DeliverToList isn't in the current ListAdmin any more...
> 
> I show the current version of ListAdmin.py as being 1.41.  Looks like, from 
the log
> messages that Barry put my patch in back in 1.33 on 5/30, then removed the 
entire
> block of code when he switched to queueing admin requests, rather than 
delivering them
> realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...

I have version 1.31 from 5/8/2000.  This is after I've run
a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...

Cripes, I'm surprised the thing is running at all...



From jarrell@vt.edu  Thu Jun 22 22:41:34 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Thu, 22 Jun 2000 17:41:34 -0400
Subject: [Mailman-Developers] Bug still in current CVS
In-Reply-To: <200006222113.OAA21753@utopia.west.sun.com>
Message-ID: <4.3.2.7.2.20000622173845.00d6ac90@vtserf.cc.vt.edu>

--=====================_35321565==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 02:14 PM 6/22/00 -0700, Dan Mick wrote:
>I have version 1.31 from 5/8/2000.  This is after I've run
>a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...
>
>Cripes, I'm surprised the thing is running at all...


Look in $mailmansrc/CVS/Root

Are you pointed at ":pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman" ?

Barry moved the cvs repository a while back.  Even if you knew that, it's possible you
didn't get the change in; I tried to switch without blowing away, and it didn't take on
one server.  I ended up rm -rf'ing the entire source tree, and checking it out again from
sourceforge, after which I was fine.





--=====================_35321565==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:14 PM 6/22/00 -0700, Dan Mick wrote:<br>
<blockquote type=cite cite>I have version 1.31 from 5/8/2000.&nbsp; This
is after I've run<br>
a &quot;cvs update&quot;.&nbsp; Hmm.&nbsp; Maybe I don't understand CVS
well enough...<br>
<br>
Cripes, I'm surprised the thing is running at
all...</font></blockquote><br>
<br>
Look in $mailmansrc/CVS/Root<br>
<br>
Are you pointed at
&quot;:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman&quot;
?<br>
<br>
Barry moved the cvs repository a while back.&nbsp; Even if you knew that,
it's possible you<br>
didn't get the change in; I tried to switch without blowing away, and it
didn't take on<br>
one server.&nbsp; I ended up rm -rf'ing the entire source tree, and
checking it out again from<br>
sourceforge, after which I was fine.<br>
<br>
<br>
<br>
<br>
</html>

--=====================_35321565==_.ALT--



From Dan Mick <Dan.Mick@West.Sun.COM>  Fri Jun 23 02:54:45 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 18:54:45 -0700 (PDT)
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <200006230154.SAA04041@utopia.west.sun.com>

> X-Sender: jarrell@vtserf.cc.vt.edu
> Date: Thu, 22 Jun 2000 17:41:34 -0400
> To: Dan Mick <Dan.Mick@west.sun.com>, Dan.Mick@west.sun.com, 
mailman-developers@python.org, jarrell@vt.edu
> From: Ron Jarrell <jarrell@vt.edu>
> Subject: Re: [Mailman-Developers] Bug still in current CVS
> 
> At 02:14 PM 6/22/00 -0700, Dan Mick wrote:
> >I have version 1.31 from 5/8/2000.  This is after I've run
> >a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...
> >
> >Cripes, I'm surprised the thing is running at all...
> 
> 
> Look in $mailmansrc/CVS/Root
> 
> Are you pointed at 
":pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman" ?

Too smart for my own good.  I tried to re-root by changing
$mailmansrc/CVS/Root, but it turns out there's a CVS directory
in every subdirectory, so while things in the top level were coming
from Sourceforge, things in the lower levels were still coming
from python.org.

Eeek, now I've got a mongrel Mailman running.  Wish me luck as I
try to dig out of this one!...

Ignore my bug reports from yesterday; they're probably all 
bogus.



From Dan Mick <Dan.Mick@west.sun.com>  Fri Jun 23 03:13:02 2000
From: Dan Mick <Dan.Mick@west.sun.com> (Dan Mick)
Date: Thu, 22 Jun 2000 19:13:02 -0700 (PDT)
Subject: [Mailman-Developers] SMTPDirect doesn't log to 'posts'
Message-ID: <200006230212.TAA04377@utopia.west.sun.com>

> Just decided to be brave and install the current 2.0 CVS on top of my 1.1
> list.  So far so good....but I see no posts in "logs/post".  Is this 
> intentional with SMTPDirect (the default Handler), and if so, why?
> post is a useful little log to make sure things are getting through.

So, with the *real* CVS, this seems to really be true; Barry,
is this an oversight, or should SMTPDirect.py be logging something
to 'post'?



From Dan Mick <Dan.Mick@West.Sun.COM>  Fri Jun 23 04:05:34 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 20:05:34 -0700 (PDT)
Subject: [Mailman-Developers] Locking (oh no!)
Message-ID: <200006230304.UAA05357@utopia.west.sun.com>

So, with the latest CVS (really, I swear this time), it seems
trivial for me to create a locking deadlock.  This has happened
four times in the last five minutes.  

Scenario:

1) go to admin/ link
2) while admin page is downloading, go to admindb/ link (on same
page)

The admin process dies, but still holds the lock; the admindb process
spins waiting for the lock.

Granted, it's easier for me than some to get to admindb while admin
is still downloading, but...

Is something about the browser/webserver combination killing admin
in such a way so that its lock cleanup stuff isn't working?
Who's supposed to clean up the lock if the process dies an early
death for some reason?  (Or is this where the lock has to be 
broken?)




From smead@amplepower.com  Fri Jun 23 06:00:53 2000
From: smead@amplepower.com (David Smead)
Date: Thu, 22 Jun 2000 22:00:53 -0700 (PDT)
Subject: [Mailman-Developers] Locking (oh no!)
In-Reply-To: <200006230304.UAA05357@utopia.west.sun.com>
Message-ID: <Pine.LNX.4.10.10006222144220.10454-100000@henry.amplepower.com>

Dan,

I exchanged a few emails with Harald Meland on the lock problem.  I've
used the fntl package under python with success, however, I understand
that mailman is using the link file system as an atomic command.  BTW I
read recently that the Linux kernel is going to change its behavior for
link in the next release, so that may be a problem waiting to arrive.

I've meant to take a look at the locking code, but after losing my disk
drive on my prime workbox I've been wrapped around the axle instead.
My first suggestion, which may already be the case, is to have one place
where locks and unlocks occur in the code.

But, since a process can always be killed, or die from who knows what, a
final solution has to be a `lock server', where a process that connects to
the server can request a lock or unlock, and a granted lock has an
expiration time after which it is released and a subsequent call to unlock
from the owner is ignored.  As long as stale locks are cleaned when the
system is rebooted, (when the lock server is started or restarted), then
things should be about as robust as possible.

Performance will take a hit with the server approach, but doesn't it
always when robust behavior is demanded?

If I get my workbox here back up to speed tomorrow, I'll try to look into
the lock problem some more.


Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Thu, 22 Jun 2000, Dan Mick wrote:

> So, with the latest CVS (really, I swear this time), it seems
> trivial for me to create a locking deadlock.  This has happened
> four times in the last five minutes.  
> 
> Scenario:
> 
> 1) go to admin/ link
> 2) while admin page is downloading, go to admindb/ link (on same
> page)
> 
> The admin process dies, but still holds the lock; the admindb process
> spins waiting for the lock.
> 
> Granted, it's easier for me than some to get to admindb while admin
> is still downloading, but...
> 
> Is something about the browser/webserver combination killing admin
> in such a way so that its lock cleanup stuff isn't working?
> Who's supposed to clean up the lock if the process dies an early
> death for some reason?  (Or is this where the lock has to be 
> broken?)
> 
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From Nigel.Metheringham@VData.co.uk  Fri Jun 23 09:23:42 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 23 Jun 2000 09:23:42 +0100
Subject: [Mailman-Developers] including subscribe address in
 message
In-Reply-To: Message from Ryan Fife <fife@AnywhereYouGo.com>
 of "Thu, 22 Jun 2000 12:17:51 CDT." <20000622121751.E8010@AnywhereYouGo.com>
Message-ID: <E135OkY-00054x-00@rioja.localnet>

fife@AnywhereYouGo.com said:
> I would like to include a line that says:
> You are subscribed as: fife@AnwyhereYouGo.com

Ugh.

If you use exim (and what sane person wouldn't [*]), then you could 
modify your list handling so that a dedicated transport is used for 
outgoing list SMTP.  This transport could have the maximum recipients 
set to one, and add a header to each message - say seomthing like
	X-List-Subscription-Address: fife@AnwyhereYouGo.com

	Nigel.

[*] OK, a little too much flame bait for no good reason, but hey its a 
nice
    morning here :-)

-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From ckolar@admin.aurora.edu  Fri Jun 23 16:07:15 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Fri, 23 Jun 2000 10:07:15 -0500
Subject: [Mailman-Developers] implicit destination message?
Message-ID: <4.3.2.7.2.20000623100529.00b5cc20@admin.aurora.edu>

Hi everyone.  I recently received a note from a person strongly suggesting 
that error messages be put into the documentation.  Is there a place where 
the error messages are all laid out so that I could whack together 
descriptions?  He was particularly disturbed by the "implicit destination" 
error.  Cheers,

--chris



From fife@AnywhereYouGo.com  Fri Jun 23 17:36:51 2000
From: fife@AnywhereYouGo.com (Ryan Fife)
Date: Fri, 23 Jun 2000 11:36:51 -0500
Subject: [Mailman-Developers] including subscribe address in message
In-Reply-To: <E135OkY-00054x-00@rioja.localnet>; from Nigel.Metheringham@vdata.co.uk on Fri, Jun 23, 2000 at 09:23:42AM +0100
References: <fife@AnywhereYouGo.com> <E135OkY-00054x-00@rioja.localnet>
Message-ID: <20000623113651.B21268@AnywhereYouGo.com>

This sounds like a good interim solution.  The only problem I see is that
you are still dealing with people that don't understand headers and such
so you'll have to either:

a) explain how to find their subscription address out using headers
b) have them forward you the message

The latter one is *definitely* the least time consuming for a list admin!

Thanks to everyone for the good responses...I guess my last question/comment
is:

Anyone planning on working on VERPing capabilities (woohoo - using a term
I just learned!)?  I would love to do this, but realize that my time
limitations over the next month or so are quite tight so I probably won't
get to it - I could definitely help out if someone else was leading the
effort, however.

If not, I'll still look into it - just don't expect to see anything soon!

Thanks again,

On Fri, Jun 23, 2000 at 09:23:42AM +0100, Nigel Metheringham wrote:
> 
> fife@AnywhereYouGo.com said:
> > I would like to include a line that says:
> > You are subscribed as: fife@AnwyhereYouGo.com
> 
> Ugh.
> 
> If you use exim (and what sane person wouldn't [*]), then you could 
> modify your list handling so that a dedicated transport is used for 
> outgoing list SMTP.  This transport could have the maximum recipients 
> set to one, and add a header to each message - say seomthing like
> 	X-List-Subscription-Address: fife@AnwyhereYouGo.com
> 
> 	Nigel.
> 
> [*] OK, a little too much flame bait for no good reason, but hey its a 
> nice
>     morning here :-)
> 
> -- 
> [ - Opinions expressed are personal and may not be shared by VData - ]
> [ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
> [ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
> 

-- 
Ryan Fife
fife@AnywhereYouGo.com
 Creators of the world's first online WAP testing tool:
 http://www.AnywhereYouGo.com/Content.po?name=lab/About


From hniksic@iskon.hr  Fri Jun 23 17:40:27 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 23 Jun 2000 18:40:27 +0200
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
In-Reply-To: "Stu Ekins"'s message of "Wed, 14 Jun 2000 14:56:34 +0100"
References: <BJEKLFPEBALNOFGGKCJACECDCAAA.stu@ekins.net>
Message-ID: <dp3dm473lw.fsf@mraz.iskon.hr>

"Stu Ekins" <stu@ekins.net> writes:

> Mailman has an option in the list admin pages, which says something
> like "domain name this list prefers". Specify "bar.net" in here, and
> bob should be your mother's brother...

This works.  Thanks!


From jeremy@beopen.com  Fri Jun 23 17:43:20 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 23 Jun 2000 12:43:20 -0400 (EDT)
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: <183765175@toto.iv>
Message-ID: <14675.37800.89133.686560@localhost.localdomain>

Speaking as a non-expert, these changes sound good reasonable.  Do
robots other than htdig understand these meta tags?

Jeremy


From Nigel.Metheringham@VData.co.uk  Fri Jun 23 18:15:07 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 23 Jun 2000 18:15:07 +0100
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: Message from Jeremy Hylton <jeremy@beopen.com>
 of "Fri, 23 Jun 2000 12:43:20 EDT." <14675.37800.89133.686560@localhost.localdomain>
Message-ID: <E135X2p-0006Qp-00@rioja.localnet>

jeremy@beopen.com said:
> Speaking as a non-expert, these changes sound good reasonable.  Do
> robots other than htdig understand these meta tags? 

I only mentioned them at all because they are supposed to be a generic 
standard... what uses them is a different question.

The URL I quoted was for webcrawler, so that does use those metas.. 
unless there is good reason to do otherwise I'd like to throw my weight 
behind making a reason for other engines to take up those metas.

I have a test implementation in use - will submit patches soon.

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From claw@kanga.nu  Fri Jun 23 18:58:42 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 23 Jun 2000 10:58:42 -0700
Subject: [Mailman-Developers] including subscribe address in message
In-Reply-To: Message from Nigel Metheringham <Nigel.Metheringham@VData.co.uk>
 of "Fri, 23 Jun 2000 09:23:42 +0100." <E135OkY-00054x-00@rioja.localnet>
References: <E135OkY-00054x-00@rioja.localnet>
Message-ID: <16632.961783122@kanga.nu>

On Fri, 23 Jun 2000 09:23:42 +0100 
Nigel Metheringham <Nigel.Metheringham@VData.co.uk> wrote:

> fife@AnywhereYouGo.com said:
>> I would like to include a line that says: You are subscribed as:
>> fife@AnwyhereYouGo.com

> If you use exim (and what sane person wouldn't [*]), then you
> could modify your list handling so that a dedicated transport is
> used for outgoing list SMTP.  This transport could have the
> maximum recipients set to one, and add a header to each message -
> say seomthing like X-List-Subscription-Address:
> fife@AnwyhereYouGo.com

Ooo!  Oooo!  Who is going to be the first to write the stanza for
this (or has it been done already)?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Fri Jun 23 19:01:08 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 23 Jun 2000 11:01:08 -0700
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: Message from Jeremy Hylton <jeremy@beopen.com>
 of "Fri, 23 Jun 2000 12:43:20 EDT." <14675.37800.89133.686560@localhost.localdomain>
References: <14675.37800.89133.686560@localhost.localdomain>
Message-ID: <16696.961783268@kanga.nu>

On Fri, 23 Jun 2000 12:43:20 -0400 (EDT) 
Jeremy Hylton <jeremy@beopen.com> wrote:

> Speaking as a non-expert, these changes sound good reasonable.  Do
> robots other than htdig understand these meta tags?

My experience, from watching my Apache logs (I'm very well indexed),
is that ALL of the commercial search engine spiders and robots
honour both robots.txt and the robots meta tag.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jim@cosource.com  Fri Jun 23 23:41:30 2000
From: jim@cosource.com (Jim Hebert)
Date: Fri, 23 Jun 2000 18:41:30 -0400 (EDT)
Subject: [Mailman-Developers] bug in changing subscription options
Message-ID: <Pine.LNX.4.10.10006231835470.18082-100000@ray.compu-aid.com>

While trying to make a change (trying to set 'nomail' basically) via the
web interface, for my subscription to mailman-users, I got

We're sorry, we hit a bug!

Mailman experienced a very low level failure and could not even generate a
useful traceback for you. Please report this to the Mailman
administrator at this site. 

Got it after submitting my password, which has a requisite amount of wierd
characters in it. =) Linux 2.2, Netscape 4.73, no proxies, accepting
cookies, etc., ie pretty normal setup on my end.

(I haven't been following closely, so sorry if this is a known problem in
the snapshot that is running that list.)

jim

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox



From chuqui@plaidworks.com  Mon Jun 26 06:54:44 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 25 Jun 2000 22:54:44 -0700
Subject: [Mailman-Developers] beta 3?
Message-ID: <p04320403b57ca081a9eb@[209.239.169.197]>

How close are we to b3?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jarrell@vt.edu  Mon Jun 26 21:17:30 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Mon, 26 Jun 2000 16:17:30 -0400 (EDT)
Subject: [Mailman-Developers] Bug in admindb.py (with patch)
Message-ID: <200006262017.QAA17608@babylon5.cc.vt.edu>

(Ok, actually, a typo; Barry forgot an argument)


Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.28
diff -r1.28 admindb.py
69c69
<         syslog('No such list "%s": %s\n' % (listname, e))
---
>         syslog('error','No such list "%s": %s\n' % (listname, e))




From jarrell@vtserf.cc.vt.edu  Mon Jun 26 22:36:33 2000
From: jarrell@vtserf.cc.vt.edu (Ron Jarrell)
Date: Mon, 26 Jun 2000 17:36:33 -0400
Subject: [Mailman-Developers] admindb.py bug and patch again...
Message-ID: <200006262136.RAA13425@vtserf.cc.vt.edu>

I sent this in earlier today, from my main account, but never saw
it on the list... Nor, interestingly, is the list willing to send
me my password (although it claims to); at least I haven't
gotten it after waiting a while.  I'm getting other people's messages
from the list, so I'm sending this again from an alternate account,
as a test to see if python.org is unhappy with my main one..

Anyway, there's a bug in admindb.py that crops up when you try to
feed it an illegal address.  syslog is missing an arg.  Here's
the simple patch:

Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.28
diff -r1.28 admindb.py
69c69
<         syslog('No such list "%s": %s\n' % (listname, e))
---
>         syslog('error','No such list "%s": %s\n' % (listname, e))




From bwarsaw@python.org  Tue Jun 27 06:34:14 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 01:34:14 -0400 (EDT)
Subject: [Mailman-Developers] Bug in admindb.py (with patch)
References: <200006262017.QAA17608@babylon5.cc.vt.edu>
Message-ID: <14680.15574.891360.487372@anthem.concentric.net>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> (Ok, actually, a typo; Barry forgot an argument)

Yep, and thanks!
-Barry


From bwarsaw@python.org  Tue Jun 27 14:25:01 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 09:25:01 -0400 (EDT)
Subject: [Mailman-Developers] admindb.py bug and patch again...
References: <200006262136.RAA13425@vtserf.cc.vt.edu>
Message-ID: <14680.43821.664101.476397@anthem.concentric.net>

>>>>> "RJ" == Ron Jarrell <jarrell@vtserf.cc.vt.edu> writes:

    RJ> I sent this in earlier today, from my main account, but never
    RJ> saw it on the list... Nor, interestingly, is the list willing
    RJ> to send me my password (although it claims to); at least I
    RJ> haven't gotten it after waiting a while.  I'm getting other
    RJ> people's messages from the list, so I'm sending this again
    RJ> from an alternate account, as a test to see if python.org is
    RJ> unhappy with my main one..

What appears to have happened is that some upstream newsfeed was
re-injecting comp.lang.python, which the Mailman gateway dutifully
forwarded to python-list.  This ended up swamping the python.org mail
system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there are
still 50k+ messages in Postfix's outgoing queue.

Things are starting to clear up though.
-Barry


From jarrell@vt.edu  Tue Jun 27 18:24:54 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 27 Jun 2000 13:24:54 -0400
Subject: [Mailman-Developers] admindb.py bug and patch again...
In-Reply-To: <14680.43821.664101.476397@anthem.concentric.net>
References: <200006262136.RAA13425@vtserf.cc.vt.edu>
Message-ID: <4.3.2.7.2.20000627132420.05b24540@vtserf.cc.vt.edu>

--=====================_72977361==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 09:25 AM 6/27/00 -0400, Barry A. Warsaw wrote:

>What appears to have happened is that some upstream newsfeed was
>re-injecting comp.lang.python, which the Mailman gateway dutifully
>forwarded to python-list.  This ended up swamping the python.org mail
>system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there are
>still 50k+ messages in Postfix's outgoing queue.

Yea, I started seeing my messages several hours later...  Ah, the joys of
running a server...
--=====================_72977361==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 09:25 AM 6/27/00 -0400, Barry A. Warsaw wrote:<br>
<br>
<blockquote type=cite cite>What appears to have happened is that some
upstream newsfeed was<br>
re-injecting comp.lang.python, which the Mailman gateway dutifully<br>
forwarded to python-list.&nbsp; This ended up swamping the python.org
mail<br>
system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there 
are<br>
still 50k+ messages in Postfix's outgoing queue.</blockquote><br>
Yea, I started seeing my messages several hours later...&nbsp; Ah, the
joys of<br>
running a server...</font></html>

--=====================_72977361==_.ALT--



From brian@gweep.bc.ca  Tue Jun 27 18:09:38 2000
From: brian@gweep.bc.ca (Brian Edmonds)
Date: 27 Jun 2000 10:09:38 -0700
Subject: [Mailman-Developers] announcement list option
In-Reply-To: Chuq Von Rospach's message of "Sun, 25 Jun 2000 22:54:44 -0700"
Message-ID: <m3og4n82zx.fsf@yuri.gweep.bc.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've mentioned this before, but having used Mailman for longer I'd like
to bring it up again, as I think I have a better grasp on how it might
be integrated with the existing software.  Unfortunately I still haven't
learned Python, so my ability to hack the code myself is somewhat
limited.

Anyhow, in some of my current lists, which I'd like to migrate to
mailman, I have them set up with the usual regular and digest options,
but also have an announce option.  Mail sent to the announce list goes
to all regular subscribers, as well as immediately to all digest
subscribers (rather than being digested), and also to a third list of
announcement only subscribers.  In order to migrate these lists to
Mailman I simply have to have this functionality.

I would thus envision the following changes:
 1) An announce list option added to the subscription and member
    management HTML interfaces (and subscription database, obviously).
    Operation when both digest and announce are selected would be as if
    just digest were selected, since announce is already a subset of
    digest.
 2) An option on the regular list config interface (or an additional
    interface perhaps, like the digest one) to enable or disable the
    announce option, much like digest can be.  Also options to enable or
    disable posting priviledges to the announce list (some are
    controlled, at least one I run is on the honour system), as well as
    specifying a list of accepted posters.  Non-priviledged posters
    would be held for approval using the usual mechanism.
 3) A flag to the posting software that indicates a post is an
    announcement, which would then be sent immediately to all non-nomail
    subscribers.  An update to newlist to prompt for inclusion of an
    -announce alias (which would pass this new flag) would also be a
    good idea.

Brian.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE5WN/OcCEFQUX5+OwRAgdnAJ0aN0GWnEQa4LFMS9DesAPh80N+QACfYJie
mK3m0Kdka+wvxIacUFso2J8=
=wuyG
-----END PGP SIGNATURE-----



From goisman@physics.Arizona.EDU  Wed Jun 28 16:30:09 2000
From: goisman@physics.Arizona.EDU (Philip Goisman)
Date: Wed, 28 Jun 2000 08:30:09 -0700 (MST)
Subject: [Mailman-Developers] umbrella lists - restricted
Message-ID: <200006281530.IAA21902@electron.physics.arizona.edu>

Dear Developers,

	I'd like to request that mailman umbrella lists include
the restricted (closed) feature available to standalone mailman
lists.  Currently, moderation is required if a member of a 
sublist trys to post to its umbrella list.  To administer an
all inclusive restricted umbrella list with selected posters, I
presently have to maintain a separate all inclusive (umbrella list)
mailing list that duplicates the names of everyone in my lists I
would like to keep under an umbrella list.

Thank you for your consideration of this request.

Regards,

	Philip


From bwarsaw@beopen.com  Wed Jun 28 19:47:47 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 14:47:47 -0400 (EDT)
Subject: [Mailman-Developers] beta 3?
References: <p04320403b57ca081a9eb@[209.239.169.197]>
Message-ID: <14682.18515.929813.463810@anthem.concentric.net>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> How close are we to b3?

Wonderful question, for which I now have an answer. :)

I've actually spun the tarball 3 times in the last two weeks, but have
delayed releasing it because I'd been seeing some perplexing problems
on python.org.  There was a data consistency bug which had me quite
stumped.  It dawned on me last night what the problem was, and I just
checked in a patch for it.  Very nasty bug, but easy to fix.

So once again I am going to spin the tarballs for beta 3.  I plan on
watching the logs very closely over the next 18 hours or so and if
everything looks good, I'll push the button tomorrow morning.  I'm
confident (but crossing my fingers anyway) that I have fixed this
problem.  See the checkin messages for details.

-Barry


From chuqui@plaidworks.com  Wed Jun 28 20:31:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 28 Jun 2000 12:31:00 -0700
Subject: [Mailman-Developers] beta 3?
In-Reply-To: <14682.18515.929813.463810@anthem.concentric.net>
References: <p04320403b57ca081a9eb@[209.239.169.197]>
 <14682.18515.929813.463810@anthem.concentric.net>
Message-ID: <p04320401b580029f4841@[17.216.27.193]>

At 2:47 PM -0400 6/28/00, Barry A. Warsaw wrote:
>It dawned on me last night what the problem was, and I just
>checked in a patch for it.  Very nasty bug, but easy to fix.

God, I love those.

I'm working on an internal system that I hope to finish today. it's 
been ongoing for weeks, and the end system is going to be maybe 200 
lines of perl code. Maybe.

And thefirst time someone says "why did it take you so long to write 
200 lines of Perl", I'll laugh and say "because it took me this long 
to figure out how to NOT write 2,000 lines of Perl"

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From ricardo@rixhq.nu  Thu Jun 29 07:22:48 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 29 Jun 2000 08:22:48 +0200
Subject: [Mailman-Developers] b3 not working anymore?
Message-ID: <20000629082248.C688@miss-janet.com>

Hi,

I'm running the latest cvs (just updated again this morning just to be sure)
but their doesn't seem to be any more posts being send out on the list??
they all arrive on the approval page, but once approved they vanish into
nothing... I'm not sure how long this has been going on though...
anybody else having the same trouble?

Ricardo.

--



From bwarsaw@beopen.com  Thu Jun 29 07:45:23 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 02:45:23 -0400 (EDT)
Subject: [Mailman-Developers] b3 not working anymore?
References: <20000629082248.C688@miss-janet.com>
Message-ID: <14682.61571.230240.875717@anthem.concentric.net>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I'm running the latest cvs (just updated again this morning
    RK> just to be sure) but their doesn't seem to be any more posts
    RK> being send out on the list??  they all arrive on the approval
    RK> page, but once approved they vanish into nothing... I'm not
    RK> sure how long this has been going on though...  anybody else
    RK> having the same trouble?

Take a look in the qfiles directory.  Do you see a bunch of files with
really long names and extensions .msg and .db?  You must reload the
crontab.in file to get all the new cron scripts running at the right
intervals.  Of primary importance is qrunner which clears the messages
waiting in qfiles.

This is documented in the UPGRADING file, which I know no one will
read.  Be prepared to answer this question over and over again. ;)

-Barry



From bwarsaw@beopen.com  Thu Jun 29 07:55:12 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 02:55:12 -0400 (EDT)
Subject: [Mailman-Developers] Announcing Mailman 2.0 beta 3
Message-ID: <14682.62160.749684.66627@anthem.concentric.net>

Okay folks, I am finally releasing Mailman 2.0 beta 3.  I think I have
nailed the duplicates problem -- at least I have seen no duplicates in
the last 24 hours on python.org, so I'm feeling good about it (we'll
see if that lasts tomorrow morning :).

Please give this version a thorough test; I'd like to have a much
shorter release cycle for the next few betas.  I am aiming to release
2.0 final on July 14th, the Friday before the O'Reilly OSSCON.  I plan
on spending time between now and then on slogging through the
discussion lists and bug reports, and working on the documentation.

See below for an excerpt from the NEWS file for changes since
2.0beta2.  If you have not been following the CVS updates and are
upgrading from 2.0 beta 2 or earlier PLEASE READ THE UPGRADING FILE!
A crucial step is to reload your crontab.in file, otherwise you won't
clear your message queue often enough (or perhaps not at all).

Enjoy,
-Barry

-------------------- snip snip --------------------
2.0 beta 3 (26-Jun-2000)

    - Delivery mechanism (qrunner) refined to support immediate
      queuing, queuing directly from MTA, and queuing on any error
      along the delivery pipeline.  This means 1) that huge lists
      can't time out the MTA's program delivery channel; 2) it is much
      harder to completely lose messages; 3) eventually, qrunner will
      be elaborated to meter delivery to the MTA so as not to swamp
      it.  The tradeoff is in more disk I/O since every message coming
      into the system (and most that are generated by the system) live
      on disk for some part of their journey through Mailman.

      For now, see the Default.py variables QRUNNER_PROCESS_LIFETIME
      and QRUNNER_MAX_MESSAGES for primitive resource management.

      The API to the pipeline handler modules has changed.  See
      Mailman/Handlers/HandlerAPI.py for details.

    - Revamped admindb web page: held messages are split into headers
      and bodies so they are easier to vette; admins can now also
      preserve a held message (for spam evidence gathering) or forward
      the message to a specified email address; disposition of held
      messages can be deferred; held messages have a more context
      meaningful default rejection message.

    - Change to the semantics for `acceptable_aliases' list
      configuration variable, based on suggestions by Harald Meland.

    - New mm_cfg.py variables NNTP_USERNAME and NNTP_PASSWORD can be
      set on a site-wide basis if connection to your nntpd requires
      authentication.

    - The list attribute `num_spawns' has been removed.  The mm_cfg.py
      variables MAX_SPAWNS, and DEFAULT_NUM_SPAWNS removed too.

    - LIST_LOCK_LIFETIME cranked to 5 hours and LIST_LOCK_TIMEOUT
      shortened to 10 seconds.  QRUNNER_LOCK_LIFETIME cranked up to 10
      hours.  This should decrease the changes for bogus and harmful
      lock breaking.

    - Resent-to: is now one of the headers checked for explicit
      destinations.

    - Tons more bounce formats are recognized.  The API to the bounce
      modules has changed.

    - A written LockFile module which should fix most (hopefully all)
      bugs in the locking machinery.  Many improvements suggested by
      Thomas Wouters and Harald Meland.

    - Experimental support (disabled by default) for delivering SMTP
      chunks to the MTA via multiple threads.  Your Python executable
      must have been compiled with thread support enabled, and you
      must set MAX_DELIVERY_THREADS in mm_cfg.py.  Note that this may
      not improve your overall system performance.

    - Some changes and additions to scripts: bin/find_member now
      supports a -w/--owner flag to match regexps against mailing list
      owners; bin/find_member now supports multiple regexps;
      cron/gate_news command line option changes; new script
      bin/dumbdb for debugging purposes; bin/clone_member can now also
      remove the old address and change change the list owner
      addresses.

    - The News/Mail gateway admin page has a button that lets you do
      an explicit catchup of the newsgroup.

    - The CVS repository has been moved out to SourceForge.  For more
      information, see the project summary at

      http://sourceforge.net/project/?group_id=103

    - Lots 'o bug fixes and some performance improvements.


From r.kustner@facingfacts.nl  Thu Jun 29 07:58:11 2000
From: r.kustner@facingfacts.nl (Ricardo Kustner)
Date: Thu, 29 Jun 2000 08:58:11 +0200
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jun 29, 2000 at 02:45:23AM -0400
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>
Message-ID: <20000629085811.E688@miss-janet.com>

On Thu, Jun 29, 2000 at 02:45:23AM -0400, Barry A. Warsaw wrote:
> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
>     RK> I'm running the latest cvs (just updated again this morning
>     RK> just to be sure) but their doesn't seem to be any more posts
>     RK> being send out on the list??  they all arrive on the approval
>     RK> page, but once approved they vanish into nothing... I'm not
>     RK> sure how long this has been going on though...  anybody else
>     RK> having the same trouble?
> Take a look in the qfiles directory.  Do you see a bunch of files with
> really long names and extensions .msg and .db?  

no it's empty unfortunately...

> You must reload the
> crontab.in file to get all the new cron scripts running at the right
> intervals.  

i've already fallen in that trap earlier ;) about a month ago my digests
weren't send out for a few days... but since then I've been doing a
crontab update with every cvs upgrade... 


Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From claw@kanga.nu  Thu Jun 29 08:02:45 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 00:02:45 -0700
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: Message from Ricardo Kustner <r.kustner@facingfacts.nl>
 of "Thu, 29 Jun 2000 08:58:11 +0200." <20000629085811.E688@miss-janet.com>
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>  <20000629085811.E688@miss-janet.com>
Message-ID: <26341.962262165@kanga.nu>

On Thu, 29 Jun 2000 08:58:11 +0200 
Ricardo Kustner <r.kustner@facingfacts.nl> wrote:

> On Thu, Jun 29, 2000 at 02:45:23AM -0400, Barry A. Warsaw wrote:

>> Take a look in the qfiles directory.  Do you see a bunch of files
>> with really long names and extensions .msg and .db?

> no it's empty unfortunately...

What do your MTA logs say?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@beopen.com  Thu Jun 29 08:05:24 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 03:05:24 -0400 (EDT)
Subject: [Mailman-Developers] Announcing Mailman 2.0 beta 3
References: <14682.62160.749684.66627@anthem.concentric.net>
Message-ID: <14682.62772.737708.71176@anthem.concentric.net>

Oops, I forgot to tell you how to get the tarball.  You can down load
it from any of these urls:

ftp://www.python.org/pub/mailman/mailman.tar.gz

http://www.list.org/mailman.tar.gz

http://download.sourceforge.net/mailman/mailman-2.0beta3.tgz

It will also hopefully soon be available on ftp.gnu.org.

Cheers, and G'Night. :)
-Barry


From bwarsaw@beopen.com  Thu Jun 29 08:09:52 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 03:09:52 -0400 (EDT)
Subject: [Mailman-Developers] b3 not working anymore?
References: <20000629082248.C688@miss-janet.com>
 <14682.61571.230240.875717@anthem.concentric.net>
 <20000629085811.E688@miss-janet.com>
 <26341.962262165@kanga.nu>
Message-ID: <14682.63040.489790.863488@anthem.concentric.net>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    >> no it's empty unfortunately...

    JCL> What do your MTA logs say?

Also, check logs/errors and logs/smtp.


From ricardo@rixhq.nu  Thu Jun 29 08:24:56 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 29 Jun 2000 09:24:56 +0200
Subject: [Re: [Mailman-Users] Re: [Mailman-Developers] b3 not working anymore?]
Message-ID: <20000629092456.I688@miss-janet.com>

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

sorry for using 20 different from email addresses in 10 minutes, but forgive me
it's early in the morning... :)
anyway i can't find any errors in the log files either...
the MTA logs say nothing since postfix doesn't get contacted by mailman 
at all...

Ricardo.

--


--FCuugMFkClbJLl1L
Content-Type: message/rfc822
Content-Disposition: inline

Date: Thu, 29 Jun 2000 09:21:23 +0200
From: "Ricardo - Miss Janet . Fanclub" <ricardo@miss-janet.com>
To: "Barry A. Warsaw" <bwarsaw@beopen.com>
Subject: Re: [Mailman-Users] Re: [Mailman-Developers] b3 not working anymore?
Message-ID: <20000629092123.H688@miss-janet.com>
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jun 29, 2000 at 02:45:23AM -0400

Hi again :)

i just posted a test message, and what happens is this:
1) a file ends up in the qfiles the directory (.db and .msg)
2) a few seconds later the crontab qrunner seems to pick up 
the message since it gets removed from the directory
3) postfix doesn't seem to be contacted to send out the
message to the world...

I've to leave soon, but i'll dig more into it tonight when
I get back... since appearantly our list hasn't been running
since june 26... (the digest log hasnt been touch since then)

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com


--FCuugMFkClbJLl1L--


From claw@kanga.nu  Thu Jun 29 09:42:54 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 01:42:54 -0700
Subject: [Mailman-Developers] Large mail system configuration
Message-ID: <28192.962268174@kanga.nu>

I found this while looking data about setting up SNMP monitors for
Exim (I'm instrumenting all my systems under Cricket -- Mailman
might be next if I can think of something valuable to watch):

  "The Exim Mail Transfer Agent in a Large Scale Deployment"

  http://www.kierun.org/academic/

Most likely there are similar papers about for other MTAs.  I
haven't looked.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From Gergely Madarasz <gorgo@caesar.elte.hu>  Thu Jun 29 13:22:59 2000
From: Gergely Madarasz <gorgo@caesar.elte.hu> (Gergely Madarasz)
Date: Thu, 29 Jun 2000 14:22:59 +0200 (METDST)
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>
Message-ID: <Pine.A32.3.96.1000629141720.38725v-100000@caesar.power.elte.hu>

On Thu, 29 Jun 2000, Barry A. Warsaw wrote:

> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
> 
>     RK> I'm running the latest cvs (just updated again this morning
>     RK> just to be sure) but their doesn't seem to be any more posts
>     RK> being send out on the list??  they all arrive on the approval
>     RK> page, but once approved they vanish into nothing... I'm not
>     RK> sure how long this has been going on though...  anybody else
>     RK> having the same trouble?
> 
> Take a look in the qfiles directory.  Do you see a bunch of files with
> really long names and extensions .msg and .db?  You must reload the
> crontab.in file to get all the new cron scripts running at the right
> intervals.  Of primary importance is qrunner which clears the messages
> waiting in qfiles.
> 
> This is documented in the UPGRADING file, which I know no one will
> read.  Be prepared to answer this question over and over again. ;)

Does this mean that message delivery is not handled at all when the
incoming mail is passed to mailman, and every message needs to wait for a
cronjob to run ? 
I found the method used in 1.1 (try to deliver immediatelly, if it fails,
the cronjob will handle it) much more appropriate, even though it often
resulted in mail duplication (if the mail was handled the same time when
the cronjob was run, it was sometimes delivered by both methods), which
could have been fixed by some better locking mechanisom...

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/




From klm@digicool.com  Thu Jun 29 21:06:53 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 16:06:53 -0400 (EDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
In-Reply-To: <20000629192114.5BD1D1D4B8@dinsdale.python.org>
Message-ID: <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>

On Wed, 28 Jun 2000 Dan Mick <Dan.Mick@West.Sun.COM> wrote:

> > I also have significant problems with the new moderation interface
> > which has removed significant functionality by showing only an
> > excerpted/truncated version of the held message in a TEXTAREA rather
> > than the entire message.  The old format of showing the entire
> > message allowed me as list moderator:
> > 
> >   a) To know exactly what I was approving, and thus not miss
> >   something untoward toward the end of a message.
> 
> Yes, I miss this too.  I wish the textareas had the entire message
> in it, so that they have both wonderful attributes of 1) not taking
> up page after page of browser area, but 2) having the whole
> daggone message (or at least the first N kB, where N is configurable).

While i think the configurable N has a place, i think there's a better
way to address what i see as the underlying issue.

On the one hand, hugh (the typical list manager) sometimes wants to
preview the entire contents of an arbitrarily large message.  On the
other hand, hugh often doesn't - a preview is sufficient, and on rare
occassions numerous gargantuan holds would make for a painfully huge
admindb page (though to bulk is hidden in the textareas, it still has
to be transmitted, and the browser still has to bloat to hold it).

What i would prefer is to keep the configurable-N-Kb textarea, and add
a link that goes to a page that exhibits the entire held message.
This should be not hard to implement, afford the desired discretion,
and avoid the unnecessary bulk...

Ken
klm@digicool.com



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 29 21:31:44 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 29 Jun 2000 13:31:44 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
Message-ID: <200006292030.NAA24862@utopia.west.sun.com>

> What i would prefer is to keep the configurable-N-Kb textarea, and add
> a link that goes to a page that exhibits the entire held message.
> This should be not hard to implement, afford the desired discretion,
> and avoid the unnecessary bulk...

You're right, but it's harder to implement, and I'm always on a
broadband connection.  ;)

It would obviously be better that way.



From claw@kanga.nu  Thu Jun 29 22:15:14 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 14:15:14 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
In-Reply-To: Message from Ken Manheimer <klm@digicool.com>
 of "Thu, 29 Jun 2000 16:06:53 EDT." <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>
References: <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>
Message-ID: <10195.962313314@kanga.nu>

On Thu, 29 Jun 2000 16:06:53 -0400 (EDT) 
Ken Manheimer <klm@digicool.com> wrote:

> On Wed, 28 Jun 2000 Dan Mick <Dan.Mick@West.Sun.COM> wrote:

>> Yes, I miss this too.  I wish the textareas had the entire
>> message in it, so that they have both wonderful attributes of 1)
>> not taking up page after page of browser area, but 2) having the
>> whole daggone message (or at least the first N kB, where N is
>> configurable).
...
> What i would prefer is to keep the configurable-N-Kb textarea, and
> add a link that goes to a page that exhibits the entire held
> message.  This should be not hard to implement, afford the desired
> discretion, and avoid the unnecessary bulk...

Good point.  When I get a chance later I'll update my patch to
beta3, and then have a stab at the "other" page bit.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From ckolar@admin.aurora.edu  Thu Jun 29 22:39:45 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Thu, 29 Jun 2000 16:39:45 -0500
Subject: [Mailman-Developers] Re: [Mailman-Users] Question: signup box kluge
In-Reply-To: <200006290106.SAA27534@utopia.west.sun.com>
Message-ID: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>

At 08:07 PM 6/28/2000, Dan wrote:
>The answer was "what's the question"?
>
>What does it mean to "type an email address and hit a submit button"?
>Yeah, one could add that right away:
>
><FORM METHOD=POST ACTION=....uh....what?>

[note to developers: is there a more elegant way to implement this?]

The list is not being very helpful today.  I think that what this person 
wants is something like the quickie subscription boxes that you see for 
eGroups of ListBot.    I have been working on something like this for a few 
lists that I run.  As long as security is not that important, it is 
possible to work the subscription box into a web page.

NOTE: this is a really quick kluge.

NoTE:  this is really not secure, I only use it on lists where it does not 
matter that much.

To use:

Drop into a page.  Edit the ACTION line to point to the proper 
server/listname on your MM server.  Also edit the two password fields so 
that they are the same.  What this will do is provide an initial password 
for the user, making joining easy.  What this will also do is provide the 
same initial password for all users, so IT IS NOT REALLY SECURE.  At least 
change it to something sufficiently random looking to encourage people to 
change it themselves.

Here is the HTML:

<!-- Begin insecure MM list signup box kluge. -->

<FORM METHOD="POST"
  ACTION="http://www.aocn.aurora.edu/mailman/subscribe/ilcomnets">
<!-- You will need to customize the above line for your site and list. 
--><P> </P>
<TABLE COLS="1" BORDER="0" CELLSPACING="4" CELLPADDING="5">
<TR>
<TD COLSPAN="2" WIDTH="100%" BGCOLOR="#99CCFF" ALIGN="CENTER"> <B><FONT
COLOR="#000000" SIZE="+1">ilcomnets -- Illinois Community Networking
List</FONT></B> </TD>
</TR>
<TR>
<TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> <B><FONT
COLOR="#000000">Subscribing to ilcomnets</FONT></B> </TD>
</TR>
<TR>
<TD COLSPAN="2"> <P> Subscribe to ilcomnets by filling out the following form.
You will be sent email requesting confirmation, to prevent others from
gratuitously subscribing you. This is a private list, which means that the
members list is not available to non-members. </P>
<TABLE WIDTH="65%">
<TR>
<TD>Your email address:</TD>
<TD><INPUT TYPE="Text" NAME="email" SIZE="30"></TD>
</TR>
<TR>
<TD COLSPAN="2"><INPUT TYPE="HIDDEN" NAME="pw" SIZE="15"
VALUE="ENTERSOMETHING"><INPUT TYPE="HIDDEN" NAME="pw-conf" SIZE="15"
VALUE="ENTERSOMETHING"> </TD>
</TR>
<!-- The terms ENTERSOMETHIN should be replaced on your site with something 
random. Note that this is the default password and it will be the same for 
everyone, so do not use this on a list where you need to have real 
security.  --><TR>
<TD>Would you like to receive list mail batched in a daily digest? </TD>
<TD><INPUT TYPE="radio" NAME="digest" VALUE="0" CHECKED="CHECKED"> No
<INPUT TYPE="radio" NAME="digest" VALUE="1"> Yes </TD>
</TR>
<TR>
<TD COLSPAN="2"> <CENTER>
<INPUT TYPE="Submit" NAME="email-button" VALUE="Subscribe">
</CENTER>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</FORM>

<!-- End insecure MM list signup box kluge. -->

And if anyone posts this without modification and I start to see lots of 
subscribers to ilcomnets then I will come after you with a vengeance.

--chris


 > --- Todd LaClair <todd.laclair@mail.dreamtheater.com>
> > > wrote:
>
> > >If I wanted to have a box on my webpage where a user would type their 
> email
> > >address and hit a submit button. Would MailMan be the best product to 
> manage
> > >this user list?


--
/////\\\\\/////\\\\\
  Christopher G. Kolar
    Director, Department of Instructional Technology
    Aurora University, Aurora, Illinois
  ckolar@admin.aurora.edu  --  www.aurora.edu/~ckolar
         [PGP Public Key ID: 0xC6492C72]



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 29 22:55:15 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 29 Jun 2000 14:55:15 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Question: signup box kluge
Message-ID: <200006292154.OAA29267@utopia.west.sun.com>

> >The answer was "what's the question"?
> >
> >What does it mean to "type an email address and hit a submit button"?
> >Yeah, one could add that right away:
> >
> ><FORM METHOD=POST ACTION=....uh....what?>
> 

> The list is not being very helpful today.  I think that what this person 
> wants is something like the quickie subscription boxes that you see for 
> eGroups of ListBot. 

Ah.. Well, if the word "subscribe" had appeared anywhere in the question,
I might agree that you were right...but there's no way to tell
that.

Todd, didn't you ask the original question?  Is there some
reason you're not clarifying this?

> --- Todd LaClair <todd.laclair@mail.dreamtheater.com> wrote:
>
> If I wanted to have a box on my webpage where a user would type their
> email address and hit a submit button. Would MailMan be the best
> product to manage this user list?



From granveau@worldnet.fr  Thu Jun 29 23:49:27 2000
From: granveau@worldnet.fr (Boris Granveaud)
Date: Fri, 30 Jun 2000 00:49:27 +0200
Subject: [Mailman-Developers] Mailman 2.0b3 and gate_news
Message-ID: <395BD277.214B60F1@worldnet.fr>

Hello everybody,

I've just upgraded from b2 to b3 and I have the following error that the
cron daemon sends me by mail:

/home/python/bin/python -S /home/mailman/bigophone/cron/gate_news
produced the following output:

Traceback (innermost last):
  File "/home/mailman/bigophone/cron/gate_news", line 225, in ?
    main()
  File "/home/mailman/bigophone/cron/gate_news", line 203, in main
    process_lists(lock)
  File "/home/mailman/bigophone/cron/gate_news", line 188, in
process_lists
    syslog('fromusenet', '%s watermark: %d' %
TypeError: illegal argument type for built-in operation

Boris Granveaud.




From ricardo@rixhq.nu  Thu Jun 29 23:59:06 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 30 Jun 2000 00:59:06 +0200
Subject: [Mailman-Developers] approval & b3
Message-ID: <20000630005905.G1586@miss-janet.com>

Hi,

I just found out that our list hasn't been sending mail for a few days
now. All messages must go to approval on the admindb page, but even though
the moderators have been approving lots of mail every day, they never got
send out. I've always been running an up to date cvs version and it could
be that a certain change in de source a few days ago somehow conflicts with my setup.
I have another small list running on the same mailman that doesn't have
approval but posts are send out like they should. So it must be some
oddity in the approval code. From what I can see is that is goes like
this:
1) user sends message to list
2) mm holds it back for approval (message is stored in ~mailman/data)
3) moderator approves messages 
4) mm puts the appropiate db and msg file in ~mailman/qfiles
5) crontab runs qrunner
6) qrunner sends queued mail to list [*this seems the thing NOT working in my setup]
7) qrunner removes the files from ~mailman/qfiles (this IS working even though nothing gets send!)

some extra info:
1) postfix only logs step 1... at step 6 qrunner doesn't even contact postfix
2) Defaults.py has a 'SMTPPORT=0' -- i thought that was the problem, and that it should be 25, but
   changing it to 25 doesn't help anything :(
3) no errors or weird info in ~mailman/logs

the only way i can think of fixing everything is restart with a complete new install,
but that is going to be a lot of extra work to get all the settings back on the list...
plus i'm not 100% sure if that would fix anything at all...


Ricardo.

--



From GLeblanc@cu-portland.edu  Fri Jun 30 00:10:21 2000
From: GLeblanc@cu-portland.edu (Gregory Leblanc)
Date: Thu, 29 Jun 2000 16:10:21 -0700
Subject: [Mailman-Developers] RE: [Mailman-Users] Question: signup box kluge
Message-ID: <A5F46F4ED18FD211ABEE00105AC6CF0701093874@email.cu-portland.edu>

> -----Original Message-----
> From: Christopher Kolar [mailto:ckolar@admin.aurora.edu]
> Sent: Thursday, June 29, 2000 2:40 PM
> To: mailman-users@python.org; mailman-developers@python.org
> Cc: todd.laclair@mail.dreamtheater.com
> Subject: Re: [Mailman-Users] Question: signup box kluge
> 
> At 08:07 PM 6/28/2000, Dan wrote:
> >The answer was "what's the question"?
> >
> >What does it mean to "type an email address and hit a submit button"?
> >Yeah, one could add that right away:
> >
> ><FORM METHOD=POST ACTION=....uh....what?>
> 
> [note to developers: is there a more elegant way to implement this?]
> 
> The list is not being very helpful today.  I think that what 
> this person 
> wants is something like the quickie subscription boxes that 
> you see for 
> eGroups of ListBot.    I have been working on something like 
> this for a few 
> lists that I run.  As long as security is not that important, it is 
> possible to work the subscription box into a web page.

I was the first reply, and will take full responsibility for not being
helpful.  However, I, and at least one other person, was not clear on what
this person wanted to do.  I asked politely for some clarification, but
didn't get any.  Sorry if that offended anybody, but we really didn't
understand the question

> NOTE: this is a really quick kluge.
> 
> NoTE:  this is really not secure, I only use it on lists 
> where it does not 
> matter that much.
> 
> To use:
> 
> Drop into a page.  Edit the ACTION line to point to the proper 
> server/listname on your MM server.  Also edit the two 
> password fields so 
> that they are the same.  What this will do is provide an 
> initial password 
> for the user, making joining easy.  What this will also do is 
> provide the 
> same initial password for all users, so IT IS NOT REALLY 
> SECURE.  At least 
> change it to something sufficiently random looking to 
> encourage people to 
> change it themselves.

If you've got any sort of scripting language available on your server, like
ColdFusion, PHP, or whatever, it should be easy enough to generate a random
password here.  

[snip]
>  > --- Todd LaClair <todd.laclair@mail.dreamtheater.com>
> > > > wrote:
> >
> > > >If I wanted to have a box on my webpage where a user 
> would type their 
> > email
> > > >address and hit a submit button. Would MailMan be the 
> best product to 
> > manage
> > > >this user list?
> 
> 
> --
> /////\\\\\/////\\\\\
>   Christopher G. Kolar
>     Director, Department of Instructional Technology
>     Aurora University, Aurora, Illinois
>   ckolar@admin.aurora.edu  --  www.aurora.edu/~ckolar
>          [PGP Public Key ID: 0xC6492C72]
> 
> 
> ------------------------------------------------------
> Mailman-Users maillist  -  Mailman-Users@python.org
> http://www.python.org/mailman/listinfo/mailman-users
> 


From jim@cosource.com  Fri Jun 30 00:37:30 2000
From: jim@cosource.com (Jim Hebert)
Date: Thu, 29 Jun 2000 19:37:30 -0400 (EDT)
Subject: [Mailman-Developers] Re: Question: signup box kluge
In-Reply-To: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>
Message-ID: <Pine.LNX.4.10.10006291836480.25267-100000@ray.compu-aid.com>

[re: embed pw and pw-conf as hardcoded, hidden inputs]

You could use either a server side solution (php, xssi, whatever) or a
client side solution (javascript, etc) to give the two hidden password
fields random values.

jim
ashamed at his stupid hacks sometimes =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From chuqui@plaidworks.com  Fri Jun 30 01:35:23 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 29 Jun 2000 17:35:23 -0700
Subject: [Mailman-Developers] freshmeat...
Message-ID: <p04320409b5819bb44ccd@[209.239.169.197]>

Just a nudge, Barry, to remind you to update freshmeat to show the 
new beta release...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bwarsaw@beopen.com  Fri Jun 30 04:07:27 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 23:07:27 -0400 (EDT)
Subject: [Mailman-Developers] Re: quick-fix patch for newlist failure
References: <200006292103.OAA26391@utopia.west.sun.com>
Message-ID: <14684.3823.645620.176283@anthem.concentric.net>

>>>>> "DM" == Dan Mick <Dan.Mick@West.Sun.COM> writes:

    DM> Here's a fix that's probably safe, and fixes the "newlist"
    DM> problem.  Of course I'm not sure if it's the right final fix,
    DM> but I figure while Barry's examining the problem, this might
    DM> be worth a try for some of you.

I just got back from a gig -- thanks for the quick fix Dan.  Here's a
slightly better one that also fixes a few other ugly bits.

This is serious enough to warrant a quick beta4, but I want to spend a
couple of hours looking into Ricardo's problem (which I still can't
reproduce).  Better that then having to do a beta5 over the weekend ;}
I'm just too beat tonight.

-Barry

Index: MailList.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v
retrieving revision 1.172
diff -u -r1.172 MailList.py
--- MailList.py	2000/06/28 18:40:48	1.172
+++ MailList.py	2000/06/30 03:04:42
@@ -782,23 +782,21 @@
         Utils.MakeDirTree(os.path.join(mm_cfg.LIST_DATA_DIR, name))
 	self._full_path = os.path.join(mm_cfg.LIST_DATA_DIR, name)
 	self._internal_name = name
-	self.Lock()
-	self.InitVars(name, admin, crypted_password)
-	self._ready = 1
-	self.InitTemplates()
-	self.Save()
-	self.CreateFiles()
-
-    def CreateFiles(self):
+        # Don't use Lock() since that tries to load the non-existant config.db
+        self.__lock.lock()
+        self.InitVars(name, admin, crypted_password)
+        self._ready = 1
+        self.InitTemplates()
+        self.Save()
 	# Touch these files so they have the right dir perms no matter what.
 	# A "just-in-case" thing.  This shouldn't have to be here.
 	ou = os.umask(002)
 	try:
-	    open(os.path.join(mm_cfg.LOCK_DIR, '%s.lock' % 
-			      self._internal_name), 'a+').close()
-	    open(os.path.join(self._full_path, "next-digest"), "a+").close()
-	    open(os.path.join(self._full_path, "next-digest-topics"),
-		 "a+").close()
+            path = os.path.join(self._full_path, 'next-digest')
+            fp = open(path, "a+")
+            fp.close()
+	    fp = open(path+'-topics', "a+")
+            fp.close()
 	finally:
 	    os.umask(ou)
 	


From agemo@agemo.cc  Fri Jun 30 14:04:05 2000
From: agemo@agemo.cc (agemo@agemo.cc)
Date: Fri, 30 Jun 2000 15:04:05 +0200 (CEST)
Subject: [Mailman-Developers] Config.db
Message-ID: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>

Hi,

I'm sorry for my bad english...

I'd like to read the file config.db with a perl-program, where I can read
informations about the file format?

Thank's to all.

Ciao Davide
--
Davide Rizzo agemo@agemo.cc




From ckolar@admin.aurora.edu  Fri Jun 30 15:00:50 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Fri, 30 Jun 2000 09:00:50 -0500
Subject: [Mailman-Developers] Re: Question: signup box kluge
In-Reply-To: <Pine.LNX.4.10.10006291836480.25267-100000@ray.compu-aid.co
 m>
References: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>
Message-ID: <4.3.2.7.2.20000630084953.00b1c750@admin.aurora.edu>

At 06:37 PM 6/29/2000, Jim Hebert wrote:
>[re: embed pw and pw-conf as hardcoded, hidden inputs]
>You could use either a server side solution (php, xssi, whatever) or a
>client side solution (javascript, etc) to give the two hidden password
>fields random values.
>jim
>ashamed at his stupid hacks sometimes =)

I was wondering how the code for random assignment of password is 
implemented in the admin's membership mass-subscribe function.  What if 
there was a reserved word, say RANDU, that the subscription script would 
recognize.  If you created a subscription box like I did, but in the hidden 
field put in RANDU, it would call the random algorithm that is used by mass 
subscribe to assign a password for the user.

Those tiny boxes sure are convenient, it would be nice if a little hook 
like this could be put in to support it.

--chris



From bwarsaw@beopen.com  Fri Jun 30 16:03:57 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 11:03:57 -0400 (EDT)
Subject: [Mailman-Developers] Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
Message-ID: <14684.46813.76030.881531@anthem.concentric.net>

>>>>> "agemo" ==   <agemo@agemo.cc> writes:

    agemo> I'd like to read the file config.db with a perl-program,
    agemo> where I can read informations about the file format?

The config.db is a marshal[1] of a Python dictionary object.  The
marshal format, however, is undocumented on purpose.  The contents of
the dictionary are all the attribute/value pairs of the MailList
instance.  See MailList.Save() and MailList.Load() for details.

-Barry

[1] http://www.python.org/doc/current/lib/module-marshal.html


From Dan.Mick@west.sun.com  Fri Jun 30 19:23:10 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Fri, 30 Jun 2000 11:23:10 -0700
Subject: [Mailman-Developers] Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net>
Message-ID: <395CE58E.D4512B7B@west.sun.com>


"Barry A. Warsaw" wrote:
> 
> >>>>> "agemo" ==   <agemo@agemo.cc> writes:
> 
>     agemo> I'd like to read the file config.db with a perl-program,
>     agemo> where I can read informations about the file format?
> 
> The config.db is a marshal[1] of a Python dictionary object.  The
> marshal format, however, is undocumented on purpose.  The contents of
> the dictionary are all the attribute/value pairs of the MailList
> instance.  See MailList.Save() and MailList.Load() for details.
> 
> -Barry
> 
> [1] http://www.python.org/doc/current/lib/module-marshal.html

Perhaps a portable method would be something like "dumpdb", perhaps 
modified slightly to be a little more parsing-friendly?  (if readonly
access is all that's required..)


From dgc@uchicago.edu  Fri Jun 30 20:02:53 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 30 Jun 2000 14:02:53 -0500
Subject: [Mailman-Developers] Re: Config.db
In-Reply-To: <395CE58E.D4512B7B@west.sun.com>; from Dan.Mick@west.sun.com on Fri, Jun 30, 2000 at 11:23:10AM -0700
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net> <395CE58E.D4512B7B@west.sun.com>
Message-ID: <20000630140253.D3359@smack.uchicago.edu>

On 2000.06.30, in <395CE58E.D4512B7B@west.sun.com>,
	"Dan Mick" <Dan.Mick@west.sun.com> wrote:
> 
> Perhaps a portable method would be something like "dumpdb", perhaps 
> modified slightly to be a little more parsing-friendly?  (if readonly
> access is all that's required..)

I would appreciate being able to load an edited dump, too.  To me, this
nonportability -- and thus the mere fact of using the Marshal module --
is very disturbing.  That's considerably mitigated if there are tools
for conversion in both directions, though.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@beopen.com  Fri Jun 30 20:13:17 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 15:13:17 -0400 (EDT)
Subject: [Mailman-Developers] Re: Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
 <14684.46813.76030.881531@anthem.concentric.net>
 <395CE58E.D4512B7B@west.sun.com>
 <20000630140253.D3359@smack.uchicago.edu>
Message-ID: <14684.61773.275647.868844@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> I would appreciate being able to load an edited dump, too.  To
    DC> me, this nonportability -- and thus the mere fact of using the
    DC> Marshal module -- is very disturbing.  That's considerably
    DC> mitigated if there are tools for conversion in both
    DC> directions, though.

I'm not exactly sure why you want such conversion tools.  It's very
easy to write a little Python script to hack on or inspect config.db
(see bin/dumpdb), but I'm not even sure why you'd want to do that
either.

Suffice to say that /eventually/ config.db will go away because all
this information will live in a real database.

-Barry


From dgc@uchicago.edu  Fri Jun 30 20:31:55 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 30 Jun 2000 14:31:55 -0500
Subject: [Mailman-Developers] Re: Config.db
In-Reply-To: <14684.61773.275647.868844@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jun 30, 2000 at 03:13:17PM -0400
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net> <395CE58E.D4512B7B@west.sun.com> <20000630140253.D3359@smack.uchicago.edu> <14684.61773.275647.868844@anthem.concentric.net>
Message-ID: <20000630143155.F3359@smack.uchicago.edu>

On 2000.06.30, in <14684.61773.275647.868844@anthem.concentric.net>,
	"Barry A. Warsaw" <bwarsaw@beopen.com> wrote:
> 
> I'm not exactly sure why you want such conversion tools.  It's very

Hypothetical example: when people fill out the form to request a
mailing list, they check off boxes for the initial configuration of the
list, and we generate the list in that configuration.

Or: it's the end of an academic year, and we've just closed 6,000
accounts.  We want to either rewrite subscriptions with people's new
alumni addresses, or remove them from the list.  (The latter's not
a big problem, I know.)

Or: again, it's the end of a year, and we've just closed 40 accounts
which own mailing lists.  We need to lock the lists pending resolution
of new ownership, because our EAUP prohibits services which don't have
accounts-eligible sponsors.

Is that convincing?

> easy to write a little Python script to hack on or inspect config.db
> (see bin/dumpdb),

Yes, but it's easier if I don't need to learn Python first (and do it
in a language that I'm going to use for other, related tasks).  None
of my administrative tools written in C, Perl or shell require
integration with (correspondingly) C, Perl, or shell.  Why should my
Python software require irt with Python?

> Suffice to say that /eventually/ config.db will go away because all
> this information will live in a real database.

That's good, too, if the database isn't required to be SQL or
something.  I think JC said that it was to be pretty open, though.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@beopen.com  Fri Jun 30 20:49:16 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 15:49:16 -0400 (EDT)
Subject: [Mailman-Developers] Re: Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
 <14684.46813.76030.881531@anthem.concentric.net>
 <395CE58E.D4512B7B@west.sun.com>
 <20000630140253.D3359@smack.uchicago.edu>
 <14684.61773.275647.868844@anthem.concentric.net>
 <20000630143155.F3359@smack.uchicago.edu>
Message-ID: <14684.63932.397328.25837@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> Hypothetical example: when people fill out the form to request
    DC> a mailing list, they check off boxes for the initial
    DC> configuration of the list, and we generate the list in that
    DC> configuration.

This can be done with bin/config_list.

    DC> Or: it's the end of an academic year, and we've just closed
    DC> 6,000 accounts.  We want to either rewrite subscriptions with
    DC> people's new alumni addresses, or remove them from the list.
    DC> (The latter's not a big problem, I know.)

bin/clone_member or bin/remove_member

    DC> Or: again, it's the end of a year, and we've just closed 40
    DC> accounts which own mailing lists.  We need to lock the lists
    DC> pending resolution of new ownership, because our EAUP
    DC> prohibits services which don't have accounts-eligible
    DC> sponsors.

Hmm, that's harder and I think being able to write to config.db would
even help you there.  What's involved in `locking a list'?  Do you
mean that email to the address should bounce, should autorespond but
not forward the email, hold the mail in a quarantine for later
delivery if the list is enabled?

    DC> Is that convincing?

Somewhat.  I totally agree that you'll want to be able to have script
and command-line access to list configurations, but I believe the
tools already exist to do this without having to touch config.db
directly.  I'd maintain largely the same attitute if there was a real
db on the back-end.

    >> easy to write a little Python script to hack on or inspect
    >> config.db (see bin/dumpdb),

    DC> Yes, but it's easier if I don't need to learn Python first
    DC> (and do it in a language that I'm going to use for other,
    DC> related tasks).  None of my administrative tools written in C,
    DC> Perl or shell require integration with (correspondingly) C,
    DC> Perl, or shell.  Why should my Python software require irt
    DC> with Python?

Well, I won't answer that learning Python takes about half a day for
anybody with C or Perl experience <wink>.

    >> Suffice to say that /eventually/ config.db will go away because
    >> all this information will live in a real database.

    DC> That's good, too, if the database isn't required to be SQL or
    DC> something.  I think JC said that it was to be pretty open,
    DC> though.

My very vague thoughts at the moment are that there will be a db API
with pluggable back-ends.  We'll ship with a connection to a GPL
compatible database (e.g. PostgreSQL, MySQL, ZODB) but you'd be able
to swap out the back-end if you want.

-Barry


From mentor@alb-net.com  Thu Jun  1 04:03:42 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 31 May 2000 23:03:42 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS; multiple message approval
Message-ID: <Pine.GSO.4.21.0005312300430.20966-100000@alb-net.com>

There seems to be a problem when approving multiple messages in the latest
CVS (this evening). When approving multiple messages at least one of them
will disappear. logs/vette shows the messages as approved, however the
messages never makes it to the archives and it does not get distributed. 

I tried this with 2 and three messages waiting for approval.

Hope this helps to resolve a possible problem.

thanks,
mentor



From bwarsaw@python.org  Thu Jun  1 04:03:49 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 31 May 2000 23:03:49 -0400 (EDT)
Subject: [Mailman-Developers] approved messages in 2.0beta3 not archived
References: <Pine.GSO.4.21.0005311223310.16287-100000@alb-net.com>
Message-ID: <14645.53909.340540.557299@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> Some testing with 2.0beta3 revealed that the approved message
    MC> are not being archived properly. Actually, the messages get
    MC> into the list.mbox file but they are missing the "From " line
    MC> and therefore do not show on the archive page.

This will (finally) be fixed in the released 2.0beta3.

-Barry


From bigdog@dogpound.vnet.net  Thu Jun  1 05:17:19 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 00:17:19 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
Message-ID: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>

hate to bring this up again..  but i tried the followin..

1.  current cvs code + patch Harald fixed up
2.  current cvs code - patch Harald fixed up

Both give the same problem I was having before..  Here's the rundown..

1.  I goto the 'view other subscriptions' page with correct password an NO
lock file (no lock/davis.lock).
2.  the error comes right up with the following traceback.

Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 89, in run_main
    main()
  File "/home/mailman/Mailman/Cgi/handle_opts.py", line 80, in main
    mlist.Save()
  File "/home/mailman/Mailman/MailList.py", line 867, in Save
    self.__lock.refresh()
  File "/home/mailman/Mailman/LockFile.py", line 204, in refresh
    raise NotLockedError
NotLockedError: 

&

<< -- start lock log -- >>
Jun 01 00:03:58 2000 (6084) davis.lock laying claim
Jun 01 00:03:58 2000 (6084) davis.lock got the lock
Jun 01 00:03:58 2000 (6084) davis.lock laying claim
Jun 01 00:03:58 2000 (6084) davis.lock already locked
<< -- stop lock log -- >>

3.  Well..  I hit refresh and there is now a davis.lock file.  And it
waits (probably until 

Jun 01 00:04:24 2000 (6095) davis.lock laying claim
Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:24 2000 (6095) davis.lock waiting for claim
Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:25 2000 (6095) davis.lock unexpected linkcount <> 2: 1

<snip>  (you get the idea..)

Jun 01 00:04:51 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:04:53 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:05 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:05 2000 (6095) davis.lock waiting for claim
Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:08 2000 (6095) davis.lock unexpected linkcount <> 2: 1
Jun 01 00:06:08 2000 (6095) davis.lock lifetime has expired, breaking
Jun 01 00:06:08 2000 (6095) davis.lock got the lock
Jun 01 00:06:08 2000 (6095) davis.lock laying claim
Jun 01 00:06:08 2000 (6095) davis.lock already locked

The other weird thing is i'm using the same Lockfile.py as the one you
edited.  at least diff didnt see any differences.

PLUS i can view other subscriptions on python.org.  Is python.org using
current CVS code from sourceforge?

PS.  I'm willin to be a guinie pig again :)

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

The severity of the itch is proportional to the reach.





From bwarsaw@python.org  Thu Jun  1 05:30:54 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:30:54 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
References: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>
Message-ID: <14645.59134.480861.387333@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Is python.org using current CVS code from sourceforge?

No.  I've just fixed the qrunner problem Mentor posted about, and this
LockFile issue is probably the last one I must fix before I update
python.org's copy to CVS.  I don't think I'll get to it tonight
though.

    MD> PS.  I'm willin to be a guinie pig again :)

Mwah, ha, ha!
-Barry


From bigdog@dogpound.vnet.net  Thu Jun  1 05:42:13 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 00:42:13 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
In-Reply-To: <14645.59134.480861.387333@anthem.python.org>
Message-ID: <Pine.LNX.4.21.0006010040060.5724-100000@dogpound.vnet.net>

On Thu, 1 Jun 2000, Barry A. Warsaw wrote:

> No.  I've just fixed the qrunner problem Mentor posted about, and this
> LockFile issue is probably the last one I must fix before I update
> python.org's copy to CVS.  I don't think I'll get to it tonight
> though.

Thanks!

>     MD> PS.  I'm willin to be a guinie pig again :)
> 
> Mwah, ha, ha!

Be easy...

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

REALITY.SYS corrupted- reboot Universe (Y/N)?





From bwarsaw@python.org  Thu Jun  1 05:45:32 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:45:32 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS; multiple message approval
References: <Pine.GSO.4.21.0005312300430.20966-100000@alb-net.com>
Message-ID: <14645.60012.91457.847125@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> There seems to be a problem when approving multiple messages
    MC> in the latest CVS (this evening). When approving multiple
    MC> messages at least one of them will disappear. logs/vette shows
    MC> the messages as approved, however the messages never makes it
    MC> to the archives and it does not get distributed.

    MC> I tried this with 2 and three messages waiting for approval.

    MC> Hope this helps to resolve a possible problem.

Yes, thanks.  The current CVS should have the patch for this.  Time
for sleep.

-Barry


From bwarsaw@python.org  Thu Jun  1 05:56:08 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 00:56:08 -0400 (EDT)
Subject: [Mailman-Developers] more problems with lockfiles..
References: <Pine.LNX.4.21.0006010006560.5724-100000@dogpound.vnet.net>
Message-ID: <14645.60648.221646.191537@anthem.python.org>

Good news.  I know what the problem is, but I'm too tired to fix it
tonight.


From ricardo@rixhq.nu  Thu Jun  1 11:04:34 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 1 Jun 2000 12:04:34 +0200
Subject: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
In-Reply-To: <14645.16782.684941.668474@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 12:45:02PM -0400
References: <20000531114024.A17471@orwell.bok.net> <20000531171248.A17843@miss-janet.com> <14645.16782.684941.668474@anthem.python.org>
Message-ID: <20000601120434.B717@miss-janet.com>

On Wed, May 31, 2000 at 12:45:02PM -0400, Barry A. Warsaw wrote:
> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
>     RK> wow this is my dream come true... now i can stop bugging Barry
>     RK> about implementing this ... ;) i can't wait to get home and
>     RK> install the new cvs...  Our list relies heavily on approving
>     RK> messages so I'll report my experiences with it asap...
> Excellent, please do.  I'm on a bent to get beta3 out (and after that,
> clear my freakin' mailman-dev inbox ;).

I've installed the patch and approved about 15 posts (had to discard a lot of crap ;()
and qrunner is doing the postings now... it seems to work ok so far...
but I do notice that when I go to the admin URL while qrunner is doing it's job, it
takes more than a minute before the page is displayed... does this have something to
do with locking or it's because my server has a load average of 3+ (which isn't very
uncommon considering the hardware performance though)

> Btw, it was a one line change :)

cool :)

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From ricardo@rixhq.nu  Thu Jun  1 11:08:03 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 1 Jun 2000 12:08:03 +0200
Subject: [Mailman-Developers] logs
Message-ID: <20000601120803.C717@miss-janet.com>

Hi,

I was just looking into my logs directory and I noticed a
10mb bounce log file... maybe we should consider using something like
log rotating? ie log.0, log.1.gz, log.2.gz etc...
or should this be left as a task for the admin and/or distibution maintainer?
another option would be to set a maximum log size

Ricardo.

--



From thomas@xs4all.net  Thu Jun  1 11:19:46 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 1 Jun 2000 12:19:46 +0200
Subject: [Mailman-Developers] pipermail/hypermail mbox-archive
In-Reply-To: <14645.29500.819830.122398@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 04:17:00PM -0400
References: <20000327211501.F25139@xs4all.nl> <14645.29500.819830.122398@anthem.python.org>
Message-ID: <20000601121945.L469@xs4all.nl>

On Wed, May 31, 2000 at 04:17:00PM -0400, Barry A. Warsaw wrote:

>     TW> There was a short discussion a month or so ago about the
>     TW> hyperarch 'mbox' archives having the wrong kind of date in the
>     TW> 'From ' lines... 'unixfrom' lines should have a very specific
>     TW> dateformat, namely that which 'time.ctime' returns. The
>     TW> following patch fixes Archiver/HyperArch.py. However, I'm not
>     TW> entirely sure if it will work correctly in other
>     TW> locales... can anyone test that, and propose a
>     TW> locale-independant way of producing this format ?

> I didn't see a followup so I'm going to check this change in.

For the record, you can disregard the locale remark. ctime() is *exactly*
how the From_ line should store its date, regardless of locale or what not.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Thu Jun  1 11:23:44 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 1 Jun 2000 12:23:44 +0200
Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries
In-Reply-To: <14645.27097.449110.777191@anthem.python.org>; from bwarsaw@python.org on Wed, May 31, 2000 at 03:36:57PM -0400
References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> <20000328231400.B8665@xs4all.nl> <14645.22297.479926.425407@anthem.python.org> <14645.24708.529869.456008@anthem.python.org> <14645.27097.449110.777191@anthem.python.org>
Message-ID: <20000601122344.M469@xs4all.nl>

On Wed, May 31, 2000 at 03:36:57PM -0400, Barry A. Warsaw wrote:

> >>>>> "BAW" == Barry A Warsaw <bwarsaw@python.org> writes:

>     BAW> SMTPDirect.py uses str(msg) too and inclusion of From_ in the
>     BAW> body of the message seems to give at least Postfix all manner
>     BAW> of willies.  Maybe the thing to do is include another Message
>     BAW> method which returns just the headers and body, sans the
>     BAW> unixfrom, and use this in SMTPDirect and Sendmail?

> Is it too much of a kludge to make __repr__() return the entire
> message, including the From_ header, and make __str__() return just
> the rfc822 headers and body?  I.e.

> repr(msg) == msg.unixfrom + str(msg)

Yeah, this works. My initial reserve against making str(msg) return the
unixfrom line as well was that it broke 'compatibility' with the regular
rfc822.Message. The SMTPDirect breakage shows that, I guess ;-) Using repr
is a good idea, I think, but it's missing one thing: if unixfrom is empty,
the mailbox will still be fawlty. I think __repr__ should reproduce a
.unixfrom line if it's missing. I'll post a patch later today, I have to run
off to a huge sale at the local bookstore ;-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From bwarsaw@python.org  Thu Jun  1 15:38:23 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:38:23 -0400 (EDT)
Subject: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
References: <20000531114024.A17471@orwell.bok.net>
 <20000531171248.A17843@miss-janet.com>
 <14645.16782.684941.668474@anthem.python.org>
 <20000601120434.B717@miss-janet.com>
Message-ID: <14646.30047.980591.36124@anthem.python.org>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I've installed the patch and approved about 15 posts (had to
    RK> discard a lot of crap ;() and qrunner is doing the postings
    RK> now... it seems to work ok so far...  but I do notice that
    RK> when I go to the admin URL while qrunner is doing it's job, it
    RK> takes more than a minute before the page is displayed... does
    RK> this have something to do with locking or it's because my
    RK> server has a load average of 3+ (which isn't very uncommon
    RK> considering the hardware performance though)

Maybe a bit of both.  qrunner is careful to keep the lock only long
enough to deliver a single message.  If there are multiple messages
destined for the same list, it will release and acquire the lock in
between each delivery.  Still, for large lists, this can take a while.

One of the things to eventually do is audit the cgi scripts so that
they're locking the list only during those operations that require
it.  I.e. a listinfo probably doesn't need the lock, and setting user
options probably only needs the lock for a very short amount of time.

Won't all this just work better with a real transaction based db
underneath?  ;)

-Barry


From bwarsaw@python.org  Thu Jun  1 15:38:58 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:38:58 -0400 (EDT)
Subject: [Mailman-Developers] logs
References: <20000601120803.C717@miss-janet.com>
Message-ID: <14646.30082.513809.105235@anthem.python.org>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I was just looking into my logs directory and I noticed a 10mb
    RK> bounce log file... maybe we should consider using something
    RK> like log rotating?

Yes.


From bwarsaw@python.org  Thu Jun  1 15:39:25 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:39:25 -0400 (EDT)
Subject: [Mailman-Developers] pipermail/hypermail mbox-archive
References: <20000327211501.F25139@xs4all.nl>
 <14645.29500.819830.122398@anthem.python.org>
 <20000601121945.L469@xs4all.nl>
Message-ID: <14646.30109.127864.263705@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> For the record, you can disregard the locale remark. ctime()
    TW> is *exactly* how the From_ line should store its date,
    TW> regardless of locale or what not.

Thanks.


From bwarsaw@python.org  Thu Jun  1 15:43:15 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 10:43:15 -0400 (EDT)
Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries
References: <14560.59360.933438.313871@anthem.cnri.reston.va.us>
 <20000328213635.A8665@xs4all.nl>
 <14561.3922.358917.646194@anthem.cnri.reston.va.us>
 <20000328231400.B8665@xs4all.nl>
 <14645.22297.479926.425407@anthem.python.org>
 <14645.24708.529869.456008@anthem.python.org>
 <14645.27097.449110.777191@anthem.python.org>
 <20000601122344.M469@xs4all.nl>
Message-ID: <14646.30339.118196.198174@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Yeah, this works. My initial reserve against making str(msg)
    TW> return the unixfrom line as well was that it broke
    TW> 'compatibility' with the regular rfc822.Message.

I think the only place where concrete rfc822.Message objects are used
(as opposed to Mailman.Message.Message objects or derived), is in the
bounce detector.  At least, everything else /should/ use Mailman's own
Message class or one derived from there.  So I'm not worried about b/w
compatibility.
    
    TW> Using repr is a good idea, I think, but it's missing one
    TW> thing: if unixfrom is empty, the mailbox will still be
    TW> fawlty. I think __repr__ should reproduce a .unixfrom line if
    TW> it's missing. I'll post a patch later today, I have to run off
    TW> to a huge sale at the local bookstore ;-)

Cool.
-Barry


From claw@kanga.nu  Thu Jun  1 17:24:18 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 01 Jun 2000 09:24:18 -0700
Subject: [Mailman-Developers] logs
In-Reply-To: Message from Ricardo Kustner <ricardo@rixhq.nu>
 of "Thu, 01 Jun 2000 12:08:03 +0200." <20000601120803.C717@miss-janet.com>
References: <20000601120803.C717@miss-janet.com>
Message-ID: <10315.959876658@kanga.nu>

On Thu, 1 Jun 2000 12:08:03 +0200 
Ricardo Kustner <ricardo@rixhq.nu> wrote:

> I was just looking into my logs directory and I noticed a 10mb
> bounce log file... maybe we should consider using something like
> log rotating? ie log.0, log.1.gz, log.2.gz etc...  or should this
> be left as a task for the admin and/or distibution maintainer?

This should be left as a task for the Admin/packager, tho it should
be noted in the README.  Depending on the list environment,
sometimes that log data can also be legal data...

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Thu Jun  1 17:29:12 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 01 Jun 2000 09:29:12 -0700
Subject: [Mailman-Developers] logs
In-Reply-To: Message from bwarsaw@python.org (Barry A. Warsaw)
 of "Thu, 01 Jun 2000 10:38:58 EDT." <14646.30082.513809.105235@anthem.python.org>
References: <20000601120803.C717@miss-janet.com>  <14646.30082.513809.105235@anthem.python.org>
Message-ID: <10382.959876952@kanga.nu>

On Thu, 1 Jun 2000 10:38:58 -0400 (EDT) 
Barry A Warsaw <bwarsaw@python.org> wrote:

>>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

RK> I was just looking into my logs directory and I noticed a 10mb
RK> bounce log file... maybe we should consider using something like
RK> log rotating?

> Yes.

No.

Apache doesn't do its own log rotation, Sendmail, Postfix, and Exim
don't do their own log rotation (tho they provide tools to do it
"properly").  And all of them, like MailMan, maintain their own logs
rather than running thru syslogd.

I see no reason for Mailman to be anny different.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@python.org  Thu Jun  1 17:31:12 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 12:31:12 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005121946020.20246-100000@dogpound.vnet.net>
Message-ID: <14646.36816.721480.344363@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Using current cvs code (as of May 12 2000 19:50 EST) I get the
    MD> following error when I hit the 'view other subscriptions'
    MD> option with the correct password.

    MD> Sometimes it would take a while (maybe a minute or 2) for it
    MD> to even display this.  And i know the system is not loaded
    MD> down.

The problem turned out to be the use of map_maillists() in
handle_opts.py when viewing other subscriptions.  This had a
side-effect of unlocking the list, so when Save() tried to refresh the
lock, it bombed.  See my recent checkin for the fix.

-Barry


From bwarsaw@python.org  Thu Jun  1 22:49:47 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 1 Jun 2000 17:49:47 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
Message-ID: <14646.55931.299948.492757@anthem.python.org>

Hi Harald,

I've finally gotten around to looking at your LockFile.py changes.
Note that I checked in a different change to fix the actual problem
with "view other subscriptions", but I still want to comment on your
diffs.

    HM>  The above strangeness was probably caused by a buglet in the
    HM> current CVS LockFile.py; I believe it gets the order of
    HM> unlink() calls wrong.

    HM> As I see it, it is more important for the lock file to never
    HM> have a link count that is neither 0 or 2 than it is to make
    HM> sure there are no tempfile turds.  This implies that the real
    HM> lock file should be unlink()ed before the tempfile, and not
    HM> the other way around.  Here's a (untested) patch (which also
    HM> touches on some other issues I noticed while I was at it :):

Thinking about this more, I disagree.  I think it is perfectly fine to
expect the linkcount to be 0, 1, or 2, but never greater than 2.
Let's look at each in detail.  Remember we're talking about the link
count of the shared global file, not the process specific tmp files.

Linkcount == 0: this just means that lockfile doesn't exist, so we
don't actually ever get here (we'd get an ENOENT instead).

Linkcount == 1: One way this can happen is due to a race condition
between proc1 which is in the middle of unlocking and proc2 which has
just laid claim to the lock.  Here's how this goes:

    -- proc1 had a valid lock and is now in unlock().  It unlinks its
       tmpfname, leaving lockfile's linkcount == 1

    -- proc2 comes along and links lockfile to /its/ tmpfname.  This
       fails because lockfile already exists, but linkcount == 1.  I
       believe we can just ignore this case and loop around to attempt
       acquisition again next time.

    -- proc1 now unlinks lockfile, relinquishing the lock

    -- proc2 loops and attempts to link lockfile -> tmpfname

This situation was broken but only because the big if/else in the
OSError clause in lock() didn't take this race condition into account.
I think the better fix is to just catch the linkcount==1 case, and
essentially ignore it.  To me, the more important invariant is that if
the global lockfile exists, somebody else has the lock.  Changing the
order of unlinks breaks this invariant.

Linkcount == 2: Somebody's got a valid lock.

Linkcount > 2: Somebody's messing with us.  I cannot see any situation
where linkcount would be > 2 without "outside influences".

Okay, now to specific changes in your patch.  Apologies for the ugly
nature of the citations.

    | +                    # HM: I don't understand why the tempfile should be
    | +                    # unlinked in this situation.  I think that all it w
    | +                    # is confuse things, so I've commented it out.
    | +                    ## os.unlink(self.__tmpfname)

You're right, this should not remove the tmpfname.  This would be like
only half giving up the lock!  I've removed this unlink() call.

    | -        NotLockedError, unless optional `unconditional' is true.
    | +        NotLockedError, unless optional `unconditionally' is true.

Applied.

    | -        islocked = 0
    | -        try:
    | -            islocked = self.locked()
    | -        except OSError, e:
    | -            if e.errno <> errno.ENOENT: raise
    | +        islocked = self.locked()

Applied.

    | -        try:
    | -            winner = self.__read()
    | -            if winner:
    | -                os.unlink(winner)
    | -        except OSError, e:
    | -            if e.errno <> errno.ENOENT: raise
    | +        # Try finding the name of the old winner's temp file.  We're ass
    | +        # the winner process has hung or died, so we should try cleaning
    | +        # their mess.
    | +        winner = self.__read()

Applied.
    
        HM> I noticed another apparent inconsistency in LockFile.py,
        HM> too: The comment at the start of __break() seems to imply
        HM> that calling __touch() will totally remove the race
        HM> condition, while I believe all it does is make the race
        HM> condition a little less likely.

You're right of course.  I've updated the comment, but not changed the
code because I think we're adequately defensive in the face of this
race condition.  __break() doesn't acquire a lock and it doesn't
matter if two processes attempt to break the same lock at the same
time.

Thanks very much for looking at all this.  I'm about to check in a new
version of LockFile.py which also contains a slightly revised unit
test.

Cheers,
-Barry


From bigdog@dogpound.vnet.net  Fri Jun  2 00:49:27 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 1 Jun 2000 19:49:27 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: <14646.55931.299948.492757@anthem.python.org>
Message-ID: <Pine.LNX.4.21.0006011942340.6933-100000@dogpound.vnet.net>

On Thu, 1 Jun 2000, Barry A. Warsaw wrote:

> Thanks very much for looking at all this.  I'm about to check in a new
> version of LockFile.py which also contains a slightly revised unit
> test.

Bingo :)  Thanks you 2.  For whatever you did its working just fine.

--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

Spelling checkers at maximum!  Fire!




From bwarsaw@python.org  Fri Jun  2 04:15:17 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Thu, 1 Jun 2000 23:15:17 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <14646.55931.299948.492757@anthem.python.org>
 <Pine.LNX.4.21.0006011942340.6933-100000@dogpound.vnet.net>
Message-ID: <14647.9925.965238.902419@anthem.python.org>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> Bingo :) Thanks you 2.  For whatever you did its working just
    MD> fine.

Excellent!


From bwarsaw@python.org  Fri Jun  2 05:24:25 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 00:24:25 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <chuqui@plaidworks.com>
 <p04310101b553a3d1f7b7@[209.239.169.197]>
 <E12vFPl-0007n9-00@rioja.localnet>
Message-ID: <14647.14073.539894.758106@anthem.python.org>

Wonderful discussion guys!  Very deep, and there's plenty of good
ideas to keep a dozen clones of each of us busy for years.  And all
packed into 24 messages.

I'll try to respond in more detail over the next several days, but I
haven't seen anything that is either critical or doable for 2.0beta3,
and probably not for 2.0 final.  One possible exception is the
batching algorithm for #recipts > SMTP_MAX_RCPTS.

G'night,
-Barry


From Nigel.Metheringham@VData.co.uk  Fri Jun  2 17:53:38 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 02 Jun 2000 17:53:38 +0100
Subject: [Mailman-Developers] Old bug, new recurrance.... archiver gets some dates wrong
Message-ID: <E12xuhW-0006pW-00@rioja.localnet>

I thought I had nailed this bug before... but its back to haunt me in 
2.0b2 - I know it was fixed in my version previously and thought it had 
made it to CVS :-)

In some cases, basically when timezones on incoming messages conspire 
with the start of the month, the archiver gets the archive date not 
quite right - specifically it gets the day of the month negative and 
the month one up on what it should be.

For an example look at:-
  http://www.exim.org/pipermail/exim-users/

and admire the archive for -2 June 2000.

I'll find and fix this when I have a moment (over the w/e).  I would be 
interested if someone can tell me a better way of fixing the archive 
that delete and rebuild - that archive is huge and doing a rebuild 
takes lots of time.

	Nigel.

-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From bwarsaw@python.org  Fri Jun  2 21:38:18 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 2 Jun 2000 16:38:18 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
Message-ID: <14648.6970.199791.120070@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> The important thing is to work on optimizing dropping mail
    CVR> into the MTA, and then letting the MTA do its job (and tune
    CVR> it!). In my work, the biggest problems is the way MLMs drop
    CVR> mail off for delivery -- usually by doing nothing more than a
    CVR> single-threaded drop sorted by a reversed address. That puts
    CVR> domain names together (but really ought to be a sort by MX
    CVR> instead, it's quite sub-optimal, especially with big
    CVR> domain-hosting sites like iname.com), but still limits
    CVR> delivery to how fast the MTA will accept addresses, and
    CVR> that's limited by DNS, since sendmail resolves addresses as
    CVR> it accepts mail...

This is very interesting.  I've just added some code to SMTPDirect.py
to support multiple MTA drop-off threads.  I actually see worse
performance with this code, which either means I screwed up the
implementation or Something Else Is Going On.

i set up a 25k+ list and timed the drop-off.  With sequential, single
threaded delivery, I could deliver a small message to Postfix in about
41 seconds.  Chunking the recips to 500 gave me about 50 chunks, and
if I give each chunk it's own thread, I'm seeing no better than 58
seconds for delivery.

I have a suspicion about what else might be happening, but I'm not
sure.  Currently, Python has a fairly limited threading model.  There
is a global interpreter lock which only allows a single thread to be
running Python code at any time.  This works well if you're doing a
lot of I/O, but not so well for other cpu intensive calculations.
Eventually, Python will probably support "free threading" which will
allow multiple threads running Python code.

Now to my eyes, the drop-off part is mostly I/O, shoving data across
the socket, so I dunno.  And maybe based on what Chuq says above, the
threading approach would work better for Sendmail than for Postfix.
So I think I will keep the code, but disable it by default and let you
guys play with it.  Please note that not all Python interpreters are
built with threading enabled.  It looks like the latest RH rpms are
built with threading, but if you've built Python 1.5.2 from source,
you'll have to explicitly configure --with-threads (I hope to change
that for Python 1.6).

An alternative would be to fork off separate processes, but that seems
too heavyweight, and makes collating the failures from the
subprocesses more difficult.

    CVR> I'd guess you can get the first 90% simply by setting up
    CVR> mailman to deliver using four threads: .com, .net,
    CVR> .edu/.us/.ca and everything else, and allowing people to
    CVR> configure extra threads if the capacity allows (and I'd do
    CVR> that by splitting each feed in half), and then coming up with
    CVR> guides on how to tune the MTA for fast delivery (I'm just
    CVR> starting to figure out sendmail 8.10, but it looks like a
    CVR> nice improvement over earlier releases).

So with the next check-in, the chunking algorithm is to create 4
buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
back-filled.

Eventually we'll need to separate out the entire hand-off process from
the main process, but that's not currently feasible.  I think this is
the best I can do for 2.0.

-Barry


From bwarsaw@python.org  Fri Jun  2 22:11:15 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 17:11:15 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
Message-ID: <14648.8947.346431.40404@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> True, but a one page README.<mlm> page in the disto for each
    CVR> reasonably supported MLM isn't a bad thing, and better than
    CVR> what anyone has.

Did you typo here or am I misunderstanding?  Mailman has README's for
Qmail and Sendmail.  They could probably be elaborated on, and other
MTAs could be added, but is this what you were looking for?

-Barry


From bwarsaw@python.org  Fri Jun  2 22:17:05 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 2 Jun 2000 17:17:05 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
 <23919.959230369@kanga.nu>
Message-ID: <14648.9297.305732.107780@anthem.python.org>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    JCL> While I really have no say here, were I Barry and Co I'd be
    JCL> comfortable with targetting Mailman as able to handle a
    JCL> mid/high 6digit subscriber base list on mid-range PC-class
    JCL> hardware given suitable system configuration.  That wouldn't
    JCL> be the target of course, just the "it must be physically able
    JCL> to work here" metric.

Bingo.

    JCL> Were delivery to the MTA seperated from the receipt or CGI
    JCL> process (ie mail is received, the RCPT list attached to it,
    JCL> and the tuple placed on a queue for background processing via
    JCL> forked process or cron job), we wouldn't be having this
    JCL> discussion.  Its a fairly invasive change to the current
    JCL> Mailman architecture, but making the whole reciept/broadcast
    JCL> aspect asynchronous offers some really pleasant future
    JCL> avenues.

Yes.

    JCL> Just been poking around there and noticed that your archives
    JCL> seem to be inop (dead disk).  If you're interested I've been
    JCL> messing about with MHonArc and PHP in my spare time and have
    JCL> almost finished getting a setup that:

    JCL>   -- Allows archived messages to be replied to on the web via
    JCL> the archive page (replies post to the list).

    JCL>   -- Templates (PHPLIB) the entire archive appearance.  All
    JCL> MHonArc does is the parsing and data extraction.

    JCL>   -- Supports archive searching by MessageID.  I've an MTA
    JCL> hack that inserts a MessageID-based URL into all outgoing
    JCL> Mailman list traffic so the user can just hit the URL and be
    JCL> taken to that message in the archives (searches the MHonArc
    JCL> DB, useful for thread reference etc).

    JCL> Hopefully I'll get something worth public viewing sometime
    JCL> next week.

Please do, these sound very cool.  One of the things high on my list
is to templatize the UI for the web interface so it can be integrated
into existing sites more seamlessly.  I know some guys who are doing a
cool project in Python that might provide the necessary functionality,
but on the other hand PHP might be fun to look into to.

-Barry


From coolo@kde.org  Fri Jun  2 22:35:06 2000
From: coolo@kde.org (Stephan Kulow)
Date: Fri, 02 Jun 2000 23:35:06 +0200
Subject: [Mailman-Developers] listing subscriptions by domain
Message-ID: <3938288A.5E0C9565@kde.org>

Hi!

As the bounce detecter can't detect all bounces correctly
(which is obviously not its fault, but those not following
any standard ;( it would be from time to time very useful
beeing able to sort the members after the domain. With the
>600 subscriptions on one of our lists it can get very hairy
to find the subscription from the domain saying "the user
you wrote to doesn't exist" without saying what user.

Greetings, Stephan

-- 
... but you ain't had mine


From mentor@alb-net.com  Sat Jun  3 01:16:52 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Fri, 2 Jun 2000 20:16:52 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
Message-ID: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>

Just updated the CVS tree to the latest (@ 19:31 EST).

Below is the error I get. I sent a message to the test list (on different
installation then the production one) and got many many copies of the same
messages. They just kept coming and coming. Different date stamp with
bunch coming with the same date/time stamp. Only ne copy goes into the
archives though, with approval or without.

To stop the messages coming, I had to delete all the files in /qfiles .

later,
mentor

---
Jun 02 19:59:16 2000 (8724) Delivery exception: LogMsg
Jun 02 19:59:16 2000 (8724) Traceback (innermost last):
  File "/opt/home/mmtest/Mailman/Handlers/HandlerAPI.py", line 74, in
DeliverTo$
    func(mlist, msg, msgdata)
  File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 53, in
process
    failures = deliver(mlist, msg, chunk)
  File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 128, in
deliver
    mlist.LogMsg('smtp',
AttributeError: LogMsg




From Dan Mick <Dan.Mick@West.Sun.COM>  Sat Jun  3 01:23:01 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Fri, 2 Jun 2000 17:23:01 -0700 (PDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
Message-ID: <200006030023.RAA24087@utopia.west.sun.com>

Oops.  Looks like SMTPDirect.py didn't get the "LogMsg becomes syslog()"
fix applied to it.

> Just updated the CVS tree to the latest (@ 19:31 EST).
> 
> Below is the error I get. I sent a message to the test list (on different
> installation then the production one) and got many many copies of the same
> messages. They just kept coming and coming. Different date stamp with
> bunch coming with the same date/time stamp. Only ne copy goes into the
> archives though, with approval or without.
> 
> To stop the messages coming, I had to delete all the files in /qfiles .
> 
> later,
> mentor
> 
> ---
> Jun 02 19:59:16 2000 (8724) Delivery exception: LogMsg
> Jun 02 19:59:16 2000 (8724) Traceback (innermost last):
>   File "/opt/home/mmtest/Mailman/Handlers/HandlerAPI.py", line 74, in
> DeliverTo$
>     func(mlist, msg, msgdata)
>   File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 53, in
> process
>     failures = deliver(mlist, msg, chunk)
>   File "/opt/home/mmtest/Mailman/Handlers/SMTPDirect.py", line 128, in
> deliver
>     mlist.LogMsg('smtp',
> AttributeError: LogMsg
> 
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers




From chuqui@plaidworks.com  Sat Jun  3 01:13:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 2 Jun 2000 17:13:00 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.8947.346431.40404@anthem.python.org>
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>	<p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>	<p04310106b5523d17e16c@[209.239.169.197]>
 <14648.8947.346431.40404@anthem.python.org>
Message-ID: <p04310102b55dfdeb8610@[209.239.169.197]>

>     CVR> True, but a one page README.<mlm> page in the disto for each
>     CVR> reasonably supported MLM isn't a bad thing, and better than
>     CVR> what anyone has.
>
>Did you typo here or am I misunderstanding?  Mailman has README's for
>Qmail and Sendmail.  They could probably be elaborated on, and other
>MTAs could be added, but is this what you were looking for?

Yes, that's what I'm suggesting -- adding to or elaborating on these 
READMEs to discuss how to set them up and optimize them.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Sat Jun  3 01:18:34 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 2 Jun 2000 17:18:34 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.6970.199791.120070@anthem.python.org>
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
 <14648.6970.199791.120070@anthem.python.org>
Message-ID: <p04310103b55dfe5ba031@[209.239.169.197]>

At 4:38 PM -0400 6/2/2000, bwarsaw@python.org wrote:

>This is very interesting.  I've just added some code to SMTPDirect.py
>to support multiple MTA drop-off threads.  I actually see worse
>performance with this code, which either means I screwed up the
>implementation or Something Else Is Going On.

Are you talking about performance loading into the MTA? Or delivery?

I'll bet one thing in the Something Else category is disk I/O. That's 
what usually nukes MTA's first (and foremost).

>the socket, so I dunno.  And maybe based on what Chuq says above, the
>threading approach would work better for Sendmail than for Postfix.


I really, really need to sit down and beat postfix into a pulp. But 
I've got four sites to ship before I can (two of them based on 
mailman). I'm typing as fast as I can... but I really want to get a 
handle on postfix....

>So I think I will keep the code, but disable it by default and let you
>guys play with it.

Very fair. It's nice the hooks are there, and IMHO, figuring out how 
to use it properly, tune is and all of that stuff sounds like a 
perfect reason for a 2.1 release. I sure wouldn't hold up other parts 
of 2.0 for this...

>Eventually we'll need to separate out the entire hand-off process from
>the main process, but that's not currently feasible.  I think this is
>the best I can do for 2.0.

I think this is a great start, and I agree -- there's enough going on 
with 2.0 that we don't want to wait for this to release it. It'll 
give us time to sit down and research the beast in different 
environments more, too.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bwarsaw@python.org  Sat Jun  3 05:12:49 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:12:49 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
References: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>
Message-ID: <14648.34241.919800.925959@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> Just updated the CVS tree to the latest (@ 19:31 EST).

Yikes!  Sorry, we had a bunch of thunderstorms so I had to shut my
machine down (don't have an ups yet) before I could finish checking
things in.  I'll finish it up now.  Let's see if that fixes things for
you.

-Barry


From bwarsaw@python.org  Sat Jun  3 05:14:47 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Sat, 3 Jun 2000 00:14:47 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <E12ucWi-0003Qo-00@rioja.localnet>
 <18431.959208098@kanga.nu>
 <p04310104b5521cbd4b6f@[209.239.169.197]>
 <20932.959218689@kanga.nu>
 <p04310106b5523d17e16c@[209.239.169.197]>
 <14648.8947.346431.40404@anthem.python.org>
 <p04310102b55dfdeb8610@[209.239.169.197]>
Message-ID: <14648.34359.712339.289069@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    >>  Did you typo here or am I misunderstanding?  Mailman has
    >> README's for Qmail and Sendmail.  They could probably be
    >> elaborated on, and other MTAs could be added, but is this what
    >> you were looking for?

    CVR> Yes, that's what I'm suggesting -- adding to or elaborating
    CVR> on these READMEs to discuss how to set them up and optimize
    CVR> them.

Great idea, and I eagerly await contributions! :)

-Barry


From bwarsaw@python.org  Sat Jun  3 05:31:26 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Sat, 3 Jun 2000 00:31:26 -0400 (EDT)
Subject: [Mailman-Developers] Huge lists
References: <14634.46608.820841.306190@localhost.localdomain>
 <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es>
 <14635.15647.180980.890136@localhost.localdomain>
 <p04310100b551090293c0@[17.216.27.193]>
 <14648.6970.199791.120070@anthem.python.org>
 <p04310103b55dfe5ba031@[209.239.169.197]>
Message-ID: <14648.35358.861812.161122@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    >> This is very interesting.  I've just added some code to
    >> SMTPDirect.py to support multiple MTA drop-off threads.  I
    >> actually see worse performance with this code, which either
    >> means I screwed up the implementation or Something Else Is
    >> Going On.

    CVR> Are you talking about performance loading into the MTA? Or
    CVR> delivery?

Loading into the MTA.

    CVR> I'll bet one thing in the Something Else category is disk
    CVR> I/O. That's what usually nukes MTA's first (and foremost).

Yes.  I didn't even mention the times I was getting before shutting
off syslogd for mail.* -- it was much worse.  But the times I quoted
are (AFAICT) just the I/O that Postfix does.  Mailman isn't doing any
different I/O for threaded delivery than for sequential delivery.

    CVR> I really, really need to sit down and beat postfix into a
    CVR> pulp.

Ooo, can I watch? :)
    
    CVR> But I've got four sites to ship before I can (two of them
    CVR> based on mailman). I'm typing as fast as I can... but I
    CVR> really want to get a handle on postfix....

Cool.

    >> So I think I will keep the code, but disable it by default and
    >> let you guys play with it.

    CVR> Very fair. It's nice the hooks are there, and IMHO, figuring
    CVR> out how to use it properly, tune is and all of that stuff
    CVR> sounds like a perfect reason for a 2.1 release. I sure
    CVR> wouldn't hold up other parts of 2.0 for this...

    >> Eventually we'll need to separate out the entire hand-off
    >> process from the main process, but that's not currently
    >> feasible.  I think this is the best I can do for 2.0.

    CVR> I think this is a great start, and I agree -- there's enough
    CVR> going on with 2.0 that we don't want to wait for this to
    CVR> release it. It'll give us time to sit down and research the
    CVR> beast in different environments more, too.

That's a plan then.  I have one more thing I want to play with for
SMTPDirect.py and then that should be it.  Guido's getting married
this weekend so I'll be mostly off-line.  Figure 2.0b3 early next week
and then fast track toward 2.0 final.  I'm ready to move on.

Cheers,
-Barry


From bwarsaw@python.org  Sat Jun  3 05:49:36 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 3 Jun 2000 00:49:36 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS: errors: AttributeError: LogMsg
References: <Pine.GSO.4.21.0006022006360.21674-100000@alb-net.com>
 <14648.34241.919800.925959@anthem.python.org>
Message-ID: <14648.36448.545779.386139@anthem.python.org>

>>>>> "BAW" == Barry A Warsaw <bwarsaw@python.org> writes:

    BAW> Yikes!  Sorry, we had a bunch of thunderstorms so I had to
    BAW> shut my machine down (don't have an ups yet) before I could
    BAW> finish checking things in.  I'll finish it up now.  Let's see
    BAW> if that fixes things for you.

All done now.


From claw@kanga.nu  Sat Jun  3 06:20:47 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 02 Jun 2000 22:20:47 -0700
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from bwarsaw@python.org
 of "Sat, 03 Jun 2000 00:31:26 EDT." <14648.35358.861812.161122@anthem.python.org>
References: <14634.46608.820841.306190@localhost.localdomain> <Pine.LNX.4.04.10005231815590.6700-100000@vgg.sci.uma.es> <14635.15647.180980.890136@localhost.localdomain> <p04310100b551090293c0@[17.216.27.193]> <14648.6970.199791.120070@anthem.python.org> <p04310103b55dfe5ba031@[209.239.169.197]>  <14648.35358.861812.161122@anthem.python.org>
Message-ID: <13005.960009647@kanga.nu>

On Sat, 3 Jun 2000 00:31:26 -0400 (EDT) 
bwarsaw  <bwarsaw@python.org> wrote:

>>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

> Yes.  I didn't even mention the times I was getting before
> shutting off syslogd for mail.* -- it was much worse.  

Just setting syslog to not sync on every message can boost
performance enourmously.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From thomas@xs4all.net  Sat Jun  3 23:39:00 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 4 Jun 2000 00:39:00 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: <14648.9297.305732.107780@anthem.python.org>; from bwarsaw@python.org on Fri, Jun 02, 2000 at 05:17:05PM -0400
References: <E12ucWi-0003Qo-00@rioja.localnet> <18431.959208098@kanga.nu> <p04310104b5521cbd4b6f@[209.239.169.197]> <20932.959218689@kanga.nu> <p04310106b5523d17e16c@[209.239.169.197]> <23919.959230369@kanga.nu> <14648.9297.305732.107780@anthem.python.org>
Message-ID: <20000604003900.S469@xs4all.nl>

On Fri, Jun 02, 2000 at 05:17:05PM -0400, Barry A. Warsaw wrote:

[ JC Lawrence about archive/database/php ]

>     JCL> Hopefully I'll get something worth public viewing sometime
>     JCL> next week.

> Please do, these sound very cool.  One of the things high on my list
> is to templatize the UI for the web interface so it can be integrated
> into existing sites more seamlessly.  I know some guys who are doing a
> cool project in Python that might provide the necessary functionality,
> but on the other hand PHP might be fun to look into to.

Not that I disagree (oh, no! It sounds cool! :) but wasn't there something
about Mailman had to be coded in Python ? Or is a PHP frontend OK ? Or only
if it's optional, or not included in the distribution ?

I am still looking at HyperMail/pipermail, but if these things are in the
running, I might just do some cleanup and fix some of the performance
problems. (Like Hypermail choking on attachements and stuff.) So it's still
useable for the bare-bones kind of server ;) If not, well, I'll take some
more time and not worry too much about features such as searchable indexes
and such.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From chuqui@plaidworks.com  Sun Jun  4 07:59:11 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sat, 3 Jun 2000 23:59:11 -0700
Subject: [Mailman-Developers] failure upgrading to current CVS
Message-ID: <p04310109b55fadaf2bcd@[209.239.169.197]>

I tried to move to the current CVS tonight, and ran into a glitch.

I copied a fresh copy of mailman from CVS, copied over the 
config.status and ran it, then ran "make install". Everything went 
fine until it tried to compile versions.py, then:

Compiling /home/mailman/Mailman/versions.py ...
Upgrading from version 0x20000b2 to 0x20000b3
Updating mailing list:  test
Traceback (innermost last):
   File "bin/update", line 282, in ?
     dolist(list)
   File "bin/update", line 77, in dolist
     l = MailList.MailList(list)
   File "/home/mailman/Mailman/MailList.py", line 74, in __init__
     self.Lock()
   File "/home/mailman/Mailman/MailList.py", line 1350, in Lock
     self.__lock.lock(timeout)
   File "/home/mailman/Mailman/LockFile.py", line 284, in lock
     self.__break()
   File "/home/mailman/Mailman/LockFile.py", line 408, in __break
     os.unlink(winner)
OSError: [Errno 2] No such file or directory: '27659 
/home/mailman/locks/test.lo
ck.newboy.plaidworks.com.27659 960076921.049111\012'


I went into the locks subdir and there were a bunch of locks, some 
new, some old. I deleted everything, and ran make install again. That 
time, it worked.

Looks like b2 left something around that caused the ugprade to lurch. 
It might make sense ot have some kind of cron job that deletes locks 
older than N days, just to be safe?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From Nigel.Metheringham@VData.co.uk  Sun Jun  4 20:29:10 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Sun, 04 Jun 2000 20:29:10 +0100
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Fri, 02 Jun 2000 17:13:00 PDT." <p04310102b55dfdeb8610@[209.239.169.197]>
Message-ID: <E12yg58-0002Y3-00@rioja.localnet>

chuqui@plaidworks.com said:
> Yes, that's what I'm suggesting -- adding to or elaborating on these
> READMEs to discuss how to set them up and optimize them. 

The exim information has now got a set of boilerplate recommendations 
on how I configure exim for what I hope is optimal handling of largish 
lists on my limited machine.  I can dump that into a text file if you 
wish for a distribution based document.

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Nigel.Metheringham@VData.co.uk  Sun Jun  4 20:39:23 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Sun, 04 Jun 2000 20:39:23 +0100
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Message from bwarsaw@python.org (Barry A. Warsaw)
 of "Fri, 02 Jun 2000 17:17:05 EDT." <14648.9297.305732.107780@anthem.python.org>
Message-ID: <E12ygF1-0002Yr-00@rioja.localnet>

There is a problem that its hard to come up with metrics for best large 
recipient list delivery that work across a range of MTAs.

My own feeling (experience based feeling, but I haven't specifically 
sat down and benchmarked/analysed its behaviour) for exim is that I 
would tend to have a maximum number of recipients for a single SMTP 
transaction of ~500 recipients.  I would tend to keep simultaneous 
injects down to around 4 at a time... although this has even less basis 
that the 500 recipients limit.  Exim will take advantage of multiple 
recipients on the same MX, but you can basically assume it will not 
take advantage of multiple queued messages going to the same MX (except 
under particular circumstances).  Hence I would in general do the 
sort/clump by reversed domain name thing since that should win in many 
cases.


bwarsaw@python.org said:
> So with the next check-in, the chunking algorithm is to create 4
> buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
> these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
> back-filled. 

Thats a very parochial view of the world (he says tongue firmly in 
cheek).  Us UK based people would probably find a different balance 
would work better for us :-)

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Harald.Meland@usit.uio.no  Sun Jun  4 21:34:12 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 22:34:12 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Nigel Metheringham's message of "Sun, 04 Jun 2000 20:29:10 +0100"
References: <E12yg58-0002Y3-00@rioja.localnet>
Message-ID: <d6dd7lxdw3f.fsf@octarine.uio.no>

[Nigel Metheringham]

> chuqui@plaidworks.com said:
> > Yes, that's what I'm suggesting -- adding to or elaborating on these
> > READMEs to discuss how to set them up and optimize them. 
> 
> The exim information has now got a set of boilerplate
> recommendations on how I configure exim for what I hope is optimal
> handling of largish lists on my limited machine.  I can dump that
> into a text file if you wish for a distribution based document.

That would be great, please do.
-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 21:48:03 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 22:48:03 +0200
Subject: [Mailman-Developers] Huge lists
In-Reply-To: Nigel Metheringham's message of "Sun, 04 Jun 2000 20:39:23 +0100"
References: <E12ygF1-0002Yr-00@rioja.localnet>
Message-ID: <d6d8zwldvgc.fsf@octarine.uio.no>

[Nigel Metheringham]

> bwarsaw@python.org said:
> > So with the next check-in, the chunking algorithm is to create 4
> > buckets: .com, .net/.org, .edu/.us/.ca, everything-else.  Chunks in
> > these buckets are no bigger than SMTP_MAX_RCPTS and buckets are not
> > back-filled. 
> 
> Thats a very parochial view of the world (he says tongue firmly in 
> cheek).  Us UK based people would probably find a different balance 
> would work better for us :-)

I had to look up "parochial".  Having done so, I believe that Norway
based people would tend to agree :-)

For most people, I guess that doing this the merkin way is good enough
-- it keeps the .com/.net/.org addresses separated from their more
frequent CTLD addresses.

But: What was the reason for not simply doing a sort on reversed
domain?
-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 22:15:58 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 04 Jun 2000 23:15:58 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: bwarsaw@python.org's message of "Thu, 1 Jun 2000 17:49:47 -0400 (EDT)"
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
Message-ID: <d6d4s79du5t.fsf@octarine.uio.no>

--=-=-=

[Barry A. Warsaw]

>     HM> As I see it, it is more important for the lock file to never
>     HM> have a link count that is neither 0 or 2 than it is to make
>     HM> sure there are no tempfile turds.  This implies that the real
>     HM> lock file should be unlink()ed before the tempfile, and not
>     HM> the other way around.  Here's a (untested) patch (which also
>     HM> touches on some other issues I noticed while I was at it :):
> 
> Thinking about this more, I disagree.  I think it is perfectly fine
> to expect the linkcount to be 0, 1, or 2, but never greater than 2.

I still don't see why there's a need for the "intermediate" state
(neither fully locked nor fully unlocked) with the shared lockfile
having a link count of 1.  I think it just makes the locking logic
more complicated to understand.

Also keep in mind that calling __linkcount() is not an atomic
operation.  Doing state tests on the return value of multiple calls to
this method makes my race-condition-meter howl rather irritatingly. :)

> To me, the more important invariant is that if the global lockfile
> exists, somebody else has the lock.  Changing the order of unlinks
> breaks this invariant.

Does it?  The shared lockfile is, in the current CVS code, unlinked
from two places.

Obviously, it needs to be unlinked when someone calls unlock().  By
doing the unlink of the shared lockfile before unlinking the tempfile,
you release the lock a tad earlier -- but that's not of any
consequence, as you were going to release the lock before returning
anyway.

The other method that currently unlinks the shared lockfile is
__break().  The purpose of that method is to remove lockfiles that
some other process has failed to release within the lock's lifetime.
Thus, this method breaks the invariant you mention *by design*.

By reversing the order of unlinks, we reduce the number of lock
failure modes.  In my book, that's a good thing. :)

Here's a quick patch to illustrate how I believe things could be
changed without breaking the "lockfile exists <=> lock is taken"
invariant:


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline

Index: LockFile.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/LockFile.py,v
retrieving revision 1.18
diff -u -r1.18 LockFile.py
--- LockFile.py	2000/06/01 22:08:10	1.18
+++ LockFile.py	2000/06/04 21:14:12
@@ -300,18 +300,21 @@
         islocked = self.locked()
         if not islocked and not unconditionally:
             raise NotLockedError
-        # Remove our tempfile
-        try:
-            os.unlink(self.__tmpfname)
-        except OSError, e:
-            if e.errno <> errno.ENOENT: raise
         # If we owned the lock, remove the global file, relinquishing it.
+        # By removing the lockfile before the tempfile, we ensure that
+        # the link count of the lockfile always will be either 0 or 2,
+        # and thus reduce the number of lock failure modes.
         if islocked:
             try:
                 os.unlink(self.__lockfile)
             except OSError, e:
                 if e.errno <> errno.ENOENT: raise
         self.__writelog('unlocked')
+        # Remove our tempfile
+        try:
+            os.unlink(self.__tmpfname)
+        except OSError, e:
+            if e.errno <> errno.ENOENT: raise
 
     def locked(self):
         """Returns 1 if we own the lock, 0 if we do not.
@@ -399,18 +402,19 @@
             self.__touch(self.__lockfile)
         except OSError, e:
             if e.errno <> errno.EPERM: raise
+        # Try getting the name of the old winner's temp file.
+        winner = self.__read()
+        # Remove the global lockfile.  This actually breaks the lock.
+        try:
+            os.unlink(self.__lockfile)
+        except OSError, e:
+            if e.errno <> errno.ENOENT: raise
         # Try to remove the old winner's temp file, since we're assuming the
         # winner process has hung or died.  Don't worry too much if we can't
         # unlink their temp file -- this doesn't wreck the locking algorithm,
         # but will leave temp file turds laying around, a minor inconvenience.
-        winner = self.__read()
         if winner:
             os.unlink(winner)
-        # Now remove the global lockfile, which actually breaks the lock.
-        try:
-            os.unlink(self.__lockfile)
-        except OSError, e:
-            if e.errno <> errno.ENOENT: raise
 
     def __sleep(self):
         interval = random.random() * 2.0 + 0.01

--=-=-=
Content-Disposition: inline

-- 
Harald

--=-=-=--


From Harald.Meland@usit.uio.no  Sun Jun  4 23:02:00 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 05 Jun 2000 00:02:00 +0200
Subject: [Mailman-Developers] .nfs* lock files
In-Reply-To: bwarsaw@python.org's message of "Wed, 31 May 2000 18:38:30 -0400 (EDT)"
References: <20000517130456.J17215@hendrix.amd.com>
 <d6dbt23ho0y.fsf@octarine.uio.no>
 <14645.37990.379956.828785@anthem.python.org>
Message-ID: <d6dzop1cdgn.fsf@octarine.uio.no>

[Barry A. Warsaw]

> >>>>> "HM" == Harald Meland <Harald.Meland@usit.uio.no> writes:
> 
>     HM> Cheap shot at making this post on-topic: Should there be a
>     HM> cron script (possibly cron/checkdbs will do) to warn the site
>     HM> admin about lists that have been corrupted?
> 
> I could probably elaborate on the mechanism in MailList.Load() --
> see the CVS tree -- where if config.db is missing, it'll fallback to
> config.db.last.  If it falls back, then it shutil.copy()'s
> config.db.last to config.db so the logic in Save() doesn't need to
> be changed.

Yup, nice work!

I'm wondering whether it would be possible to take things one step
further, though.

No matter how foolproof we try making Save(), the ultimate test is
really whether Load() succeeds.  Thus, why not let Load() be the one
to do the config.db -> config.db.last rotation?

I'm thinking of a mechanism along these lines:

  Save():
    1. Write new db to tempfile, e.g. config.db.<pid>.<host>
    2. If successful, rename() tempfile on top of config.db

  Load():
    1. Try loading config.db
    2. If successful, make config.db.last a hardlink to current
       config.db (overwriting previous config.db.last)
    3. If loading config.db failed, try loading config.db.last
    4. If loading of config.db.last was successful, make config.db a
       hardlink to config.db.last
    5. Failure.  Maybe notify someone?

There are some locking issues that would have to be resolved (Load()
can be used with unlocked lists), but I think this is doable.  If it
is, we'd gain a "last known good configuration" mechanism.

> We could probably do the same thing if the unmarshalling of
> config.db fails.  But why you'd get a MemoryError is beyond me,
> unless the corruption tickles a bug in Python.

The (current) representation of some marshalled objects are on the
form

  type identifier (a single character, e.g. 's' for string)
  size of the object (a 32-bit integer, e.g. '\003\000\000\000')
  contents of the object (e.g. 'foo')

By changing the size field in a marshalled string, it is quite easy to
produce a MemoryError (assuming your machine doesn't have huge amounts
(in the example below: 1GB) of memory available, in which case
executing the statements below might not be a very good idea :)

  $ python
  Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> import marshal
  >>> marshal.loads('s\000\000\000\100')
  Traceback (innermost last):
    File "<stdin>", line 1, in ?
  MemoryError

-- 
Harald


From Harald.Meland@usit.uio.no  Sun Jun  4 23:41:13 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 05 Jun 2000 00:41:13 +0200
Subject: [Mailman-Developers] SMTPDirect.py and logs/post
In-Reply-To: Nigel Metheringham's message of "Wed, 31 May 2000 12:14:13 +0100"
References: <E12x6Rx-0002k6-00@rioja.localnet>
Message-ID: <d6dvgzpcbna.fsf@octarine.uio.no>

[Nigel Metheringham]

> bwarsaw@python.org said:
> > Sendmail.py logs the list name, the sender and the message size.  What
> > information would you like to add?  All of those? 
> 
> The SMTP response from the trailing . of the DATA section would be
> useful - that contains the MTA queue id on many systems.

I agree, although that isn't easily accessible information when using
the smtplib.SMTP.sendmail() interface.

Looking at smtplib.py, I think one might argue that the data() method
could store the text part of it's final response for later perusal,
along the same lines as is done in the ehlo() and helo() methods.

If such change isn't deemed general enough to go into smtplib.py, we
could get this behaviour of data() by making a simple subclass of
smtplib.SMTP for Mailman use.

Should I try knocking together a patch?

> If this can't be done, the message-id would be useful.

I'd say both those things can be pretty useful.
-- 
Harald


From marc_news@valinux.com  Mon Jun  5 03:07:27 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 4 Jun 2000 19:07:27 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
Message-ID: <20000604190526.A6923@marc.merlins.org>

make install fails with:
---
Compiling /var/local/mailman/Mailman/versions.py ...
Traceback (innermost last):
  File "bin/update", line 30, in ?
    from Mailman import MailList
  File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.ListAdmin import ListAdmin
  File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
    from Mailman.Handlers import HandlerAPI
  File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
    from Mailman.Logging.Syslog import syslog
ImportError: No module named Syslog
---

I was running last week's CVS before that and it worked reasonably well.

I upgraded my python (to 1.5.2-10), just in case, but that didn't help

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From marc_news@valinux.com  Mon Jun  5 05:34:41 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 4 Jun 2000 21:34:41 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
Message-ID: <20000604190526.A6923@marc.merlins.org>

make install fails with:
---
Compiling /var/local/mailman/Mailman/versions.py ...
Traceback (innermost last):
  File "bin/update", line 30, in ?
    from Mailman import MailList
  File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.ListAdmin import ListAdmin
  File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
    from Mailman.Handlers import HandlerAPI
  File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
    from Mailman.Logging.Syslog import syslog
ImportError: No module named Syslog
---

I was running last week's CVS before that and it worked reasonably well.

I upgraded my python (to 1.5.2-10), just in case, but that didn't help

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From fil@orwell.bok.net  Mon Jun  5 11:29:52 2000
From: fil@orwell.bok.net (Fil)
Date: Mon, 5 Jun 2000 12:29:52 +0200
Subject: [Mailman-Developers] mailman cvs fails precompile
In-Reply-To: <20000604190526.A6923@marc.merlins.org>; from marc_news@valinux.com on Sun, Jun 04, 2000 at 07:07:27PM -0700
References: <20000604190526.A6923@marc.merlins.org>
Message-ID: <20000605122952.H2349@orwell.bok.net>

Did you 'configure' anew? I had the same problem until I thought of redoing
'configure' and all went smoothly afterwards...


* Marc MERLIN (marc_news@valinux.com) écrivait :
> make install fails with:
> ---
> Compiling /var/local/mailman/Mailman/versions.py ...
> Traceback (innermost last):
>   File "bin/update", line 30, in ?
>     from Mailman import MailList
>   File "/var/local/mailman/Mailman/MailList.py", line 39, in ?
>     from Mailman.ListAdmin import ListAdmin
>   File "/var/local/mailman/Mailman/ListAdmin.py", line 37, in ?
>     from Mailman.Handlers import HandlerAPI
>   File "/var/local/mailman/Mailman/Handlers/HandlerAPI.py", line 24, in ?
>     from Mailman.Logging.Syslog import syslog
> ImportError: No module named Syslog
> ---


From mentor@alb-net.com  Mon Jun  5 14:56:21 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Mon, 5 Jun 2000 09:56:21 -0400 (EDT)
Subject: [Mailman-Developers] rejected notice not sent out (latest CVS)
Message-ID: <Pine.GSO.4.21.0006050954530.24203-100000@alb-net.com>

In a case of rejecting a message, the rejected notice is not sent out with
the latest CVS. This happens independently if the messages it changed or
not.

later,
mentor



From bwarsaw@python.org  Mon Jun  5 15:46:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 10:46:59 -0400 (EDT)
Subject: [Mailman-Developers] mailman cvs fails precompile
References: <20000604190526.A6923@marc.merlins.org>
 <20000605122952.H2349@orwell.bok.net>
Message-ID: <14651.48483.398908.760108@anthem.python.org>

>>>>> "F" == Fil  <fil@orwell.bok.net> writes:

    F> Did you 'configure' anew? I had the same problem until I
    F> thought of redoing 'configure' and all went smoothly
    F> afterwards...

Right, because the Makefile changed you must run config.status or
configure again.

-Barry


From bwarsaw@python.org  Mon Jun  5 15:53:17 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 10:53:17 -0400 (EDT)
Subject: [Mailman-Developers] failure upgrading to current CVS
References: <p04310109b55fadaf2bcd@[209.239.169.197]>
Message-ID: <14651.48861.463804.818286@anthem.python.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> I tried to move to the current CVS tonight, and ran into a
    CVR> glitch.

Patch appended.

    CVR> Looks like b2 left something around that caused the ugprade
    CVR> to lurch.  It might make sense ot have some kind of cron job
    CVR> that deletes locks older than N days, just to be safe?

I don't think so.  The old locks shouldn't do more than take up a
little disk space, and you can just rm them easily enough.

-Barry

Index: LockFile.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/LockFile.py,v
retrieving revision 1.18
retrieving revision 1.19
diff -c -r1.18 -r1.19
*** LockFile.py	2000/06/01 22:08:10	1.18
--- LockFile.py	2000/06/05 14:49:39	1.19
***************
*** 404,411 ****
          # unlink their temp file -- this doesn't wreck the locking algorithm,
          # but will leave temp file turds laying around, a minor inconvenience.
          winner = self.__read()
!         if winner:
!             os.unlink(winner)
          # Now remove the global lockfile, which actually breaks the lock.
          try:
              os.unlink(self.__lockfile)
--- 404,414 ----
          # unlink their temp file -- this doesn't wreck the locking algorithm,
          # but will leave temp file turds laying around, a minor inconvenience.
          winner = self.__read()
!         try:
!             if winner:
!                 os.unlink(winner)
!         except OSError, e:
!             if e.errno <> errno.ENOENT: raise
          # Now remove the global lockfile, which actually breaks the lock.
          try:
              os.unlink(self.__lockfile)


From marc_news@valinux.com  Mon Jun  5 17:13:22 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 5 Jun 2000 09:13:22 -0700
Subject: [Mailman-Developers] mailman cvs fails precompile
In-Reply-To: <14651.48483.398908.760108@anthem.python.org>; from bwarsaw@python.org on lun, jun 05, 2000 at 10:46:59 -0400
References: <20000604190526.A6923@marc.merlins.org> <20000605122952.H2349@orwell.bok.net> <14651.48483.398908.760108@anthem.python.org>
Message-ID: <20000605091322.A6070@marc.merlins.org>

On lun, jun 05, 2000 at 10:46:59 -0400, Barry A. Warsaw wrote:
> 
> >>>>> "F" == Fil  <fil@orwell.bok.net> writes:
> 
>     F> Did you 'configure' anew? I had the same problem until I
>     F> thought of redoing 'configure' and all went smoothly
>     F> afterwards...
> 
> Right, because the Makefile changed you must run config.status or
> configure again.

Duh!

Works much better now, thank you :-)

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From bwarsaw@python.org  Mon Jun  5 17:36:37 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 12:36:37 -0400 (EDT)
Subject: [Mailman-Developers] rejected notice not sent out (latest CVS)
References: <Pine.GSO.4.21.0006050954530.24203-100000@alb-net.com>
Message-ID: <14651.55061.111860.255989@anthem.python.org>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> In a case of rejecting a message, the rejected notice is not
    MC> sent out with the latest CVS. This happens independently if
    MC> the messages it changed or not.

Do you have dont_respond_to_post_requests turned on?  Try this patch.
I don't believe that Mailman should be conditionalizing on this
variable for reject notices (it is, and should be in Hold.py for the
actual hold message).

-Barry


Index: ListAdmin.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/ListAdmin.py,v
retrieving revision 1.37
diff -c -r1.37 ListAdmin.py
*** ListAdmin.py	2000/06/02 23:07:33	1.37
--- ListAdmin.py	2000/06/05 16:35:21
***************
*** 188,196 ****
          elif value == 1:
              # Rejected
              rejection = 'Refused'
!             if not self.dont_respond_to_post_requests:
!                 self.__refuse('Posting of your message titled "%s"' % subject,
!                               sender, comment or '[No reason given]')
          else:
              assert value == 2
              # Discarded
--- 188,195 ----
          elif value == 1:
              # Rejected
              rejection = 'Refused'
!             self.__refuse('Posting of your message titled "%s"' % subject,
!                           sender, comment or '[No reason given]')
          else:
              assert value == 2
              # Discarded


From thomas@xs4all.net  Mon Jun  5 17:55:56 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 18:55:56 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
Message-ID: <20000605185556.Y469@xs4all.nl>

I'm [almost] ready to post a couple of new patches, a minor fix and a medium
new feature, and perhaps maybe a minor new feature, but I'm wondering what
the Right Method is, now that Mailman has moved to Sourceforge. Should I
post the patches here, or to the patch-manager at sourceforge, or both ? :)

I used the patch-manager for the previous patches, but mostly because I'd
posted them here before, and wanted to remind people they were around. But
what's the easiest way for the developers, to accept patches ? I'm not
familiar with the admin-side of the patch manager at all, so I dont know if
it's easy to use.

As for the patches, the small one fixes the admin Membership Management
screen so that when subscribing new users, Mailman doesn't complain about
empty lines. In fact, it's so small, I've attached it :)

The medium new feature is held-unsubscribe-requests, and I'm going to test
it a bit more before I post it. It also touches quite a lot of files.

And another thing I thought up earlier today, while rejecting a few messages
on one of our lists: It would be nice to have a 'redirect' in the admindb
interface, to bounce a mail to someone else. 'redirect' as in 'MUA-bounce',
not 'Eudora-Redirect-and-mess-with-the-headers' or 'mailer-daemon-bounce'.
Currently, you have to either approve or reject the message, which can be a
bit harsh in some cases. I'll write up a patch for that later today, I hope
;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Mon Jun  5 17:57:14 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 18:57:14 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
In-Reply-To: <20000605185556.Y469@xs4all.nl>; from thomas@xs4all.net on Mon, Jun 05, 2000 at 06:55:56PM +0200
References: <20000605185556.Y469@xs4all.nl>
Message-ID: <20000605185714.A469@xs4all.nl>

--dc+cDN39EJAMEtIO
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 05, 2000 at 06:55:56PM +0200, Thomas Wouters wrote:

> As for the patches, the small one fixes the admin Membership Management
> screen so that when subscribing new users, Mailman doesn't complain about
> empty lines. In fact, it's so small, I've attached it :)

Err, no I did not. Now I did :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

--dc+cDN39EJAMEtIO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fix.diff"

diff -urN --exclude=CVS --exclude=Makefile mailman-cvs/Mailman/Cgi/admin.py mailman-new-cvs/Mailman/Cgi/admin.py
--- mailman-cvs/Mailman/Cgi/admin.py	Sat Jun  3 00:25:52 2000
+++ mailman-new-cvs/Mailman/Cgi/admin.py	Mon Jun  5 10:02:00 2000
@@ -857,7 +861,7 @@
     if cgi_info.has_key('subscribees'):
 	name_text = cgi_info['subscribees'].value
         name_text = string.replace(name_text, '\r', '')
-	names = map(string.strip, string.split(name_text, '\n'))
+	names = filter(None, map(string.strip, string.split(name_text, '\n')))
         send_welcome_msg = string.atoi(
             cgi_info["send_welcome_msg_to_this_batch"].value)
         digest = 0

--dc+cDN39EJAMEtIO--


From bwarsaw@python.org  Mon Jun  5 18:50:26 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 13:50:26 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
Message-ID: <14651.59490.620176.355049@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> I'm [almost] ready to post a couple of new patches, a minor
    TW> fix and a medium new feature, and perhaps maybe a minor new
    TW> feature, but I'm wondering what the Right Method is, now that
    TW> Mailman has moved to Sourceforge. Should I post the patches
    TW> here, or to the patch-manager at sourceforge, or both ? :)

I think in general, post the patches to SF and send an explanation and
pointer to this list.  I think using the SF database will help ensure
stuff doesn't just get buried in my inbox. ;/

The patch manager is a bit bogus though, because I marked both your
patches as Accepted, and now they are gone!  I can't find them in
either the Open, Postponed, or Closed patch categories.  They seem to
have just disappeared.

I've submitted a SF request on the matter.

-Barry


From bwarsaw@python.org  Mon Jun  5 18:52:24 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 13:52:24 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
 <20000605185714.A469@xs4all.nl>
Message-ID: <14651.59608.210274.540216@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    >> As for the patches, the small one fixes the admin Membership
    >> Management screen so that when subscribing new users, Mailman
    >> doesn't complain about empty lines. In fact, it's so small,
    >> I've attached it :)

    TW> Err, no I did not. Now I did :)

Applied.  Thanks.

-Barry


From bwarsaw@python.org  Mon Jun  5 19:00:01 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 14:00:01 -0400 (EDT)
Subject: [Mailman-Developers] forwarded message from tnorth
Message-ID: <14651.60065.205981.887416@anthem.python.org>

Interesting, eh?
-Barry

- ---------- Forwarded message ----------
Date: Sat, 3 Jun 2000 21:18:29 +0200
From: Wichert Akkerman <wichert@cistron.nl>
Reply-To: security@debian.org
To: debian-security-announce@lists.debian.org
Subject: [SECURITY] Majordomo will be removed
Resent-Date: Sat,  3 Jun 2000 15:22:52 -0400 (EDT)
Resent-From: debian-security-announce@lists.debian.org

- -----BEGIN PGP SIGNED MESSAGE-----

- - ------------------------------------------------------------------------
Debian Security Advisory                             security@debian.org
http://www.debian.org/security/                         Wichert Akkerman
June  3, 2000
- - ------------------------------------------------------------------------


Package        : majordomo
Problem type   : local exploit
Debian-specific: no

The majordomo package as shipped in the non-free section accompanying
Debian GNU/Linux 2.1/slink allows any local user to trick majordomo into
executing arbitrary code or to create or write files as the majordomo user
anywhere on the filesystem.

This is a documented issue and the advised work around it to either have
no untrusted users on a system running majordomo or to use a setuid
wrapper that the MTA delivery agent can run. 
suboptimal solution.

We feel that those options are not a good solution, but unfortunately the
majordomo license does not allow us to fix these problems and distribute a
fixed version. As a result we have decided to remove majordomo from our
archives.

If you are using majordomo we recommend that you replace it with one
of the many other mailing-list tools available such as fml, mailman
or smartlist.

- - -- 
- - ----------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable updates
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates
Mailing list: debian-security-announce@lists.debian.org

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBOTlZ/6jZR/ntlUftAQFQ6QL/XyB4EprpjY4D2eusMd9PR+UKKh0jI7Zi
IMWf0Avik9wN6HWba64kODvePxKChnh7z2jvG3hz8CIZr6siYsTuFWtu2UkVhdZj
THnYqB87Sqp7XIdO46R7qjnLU0KibPqQ
=w/uo
- -----END PGP SIGNATURE-----


- --  
To UNSUBSCRIBE, email to debian-security-announce-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------- end -------


From thomas@xs4all.net  Mon Jun  5 19:50:43 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 5 Jun 2000 20:50:43 +0200
Subject: [Mailman-Developers] Patches 'n stuff.
In-Reply-To: <14651.59490.620176.355049@anthem.python.org>; from bwarsaw@python.org on Mon, Jun 05, 2000 at 01:50:26PM -0400
References: <20000605185556.Y469@xs4all.nl> <14651.59490.620176.355049@anthem.python.org>
Message-ID: <20000605205043.B469@xs4all.nl>

On Mon, Jun 05, 2000 at 01:50:26PM -0400, Barry A. Warsaw wrote:

> The patch manager is a bit bogus though, because I marked both your
> patches as Accepted, and now they are gone!  I can't find them in
> either the Open, Postponed, or Closed patch categories.  They seem to
> have just disappeared.

I noticed the same thing.

> I've submitted a SF request on the matter.

Lets hope their bug machine doesn't exhibit the same problem :-)

Thanx for applying the blank line subscribe fix.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From bwarsaw@python.org  Mon Jun  5 20:39:52 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 5 Jun 2000 15:39:52 -0400 (EDT)
Subject: [Mailman-Developers] Patches 'n stuff.
References: <20000605185556.Y469@xs4all.nl>
 <14651.59490.620176.355049@anthem.python.org>
 <20000605205043.B469@xs4all.nl>
Message-ID: <14652.520.650981.562964@anthem.python.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> I noticed the same thing.

Looks like rejected patches just get zapped.  I have no idea (and the
SF admins didn't tell me) what happens to accepted patches.

    TW> Thanx for applying the blank line subscribe fix.

No prob.


From thomas@xs4all.net  Mon Jun  5 23:50:51 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 6 Jun 2000 00:50:51 +0200
Subject: [Mailman-Developers] unsubscription-approval
Message-ID: <20000606005050.D469@xs4all.nl>

I've just uploaded a patch to Sourceforge which adds
unsubscription-request-approval. This mirrors subscription-approval in that
unsubscribe requests get held for admin approval. This is configurable per
list, of course, just like subscribe-approval, and also has to be explicitly
enabled by the site-admin -- the default is to disallow the setting.

Some small notes:

- If a site-admin changes the default from allow to disallow, lists
which have it set need to be manually reset. This may be seen as a bug, but
it allows some lists to have it defined without allowing other list admins
to turn on the feature. I dont rely on it, though, so if someone gets
inspiration to fix it, please do ;)

- I didn't update the DATA_FILE_VERSION.

- I didn't test this particular patch overly well, since it's kind of tricky
to get a decent diff without 'cvs diff', and I couldn't use 'cvs diff'
because the patch adds a file. ('cvs diff' doesn't 'create' files, and patch
with POSUXLY_CORRECT defined (which is necessary to apply cvs-diffs) will
not create new files regardless.) I *might* have forgotten a part of the
patch, but I went over it a few times, so I dont think so.

- I had to use some trickstery to only optionally add the
unsubscription-approval feature to the list-options dictionary. This works
just fine, but I'm not sure if it's the optimal solution.

The patch should be easy to find, as it's the only patch, currently ;)

Oh, I also have two other small patches lying around, but I'm not sure if
they're suitable for inclusion. One is a 'posters-file' config setting,
which is a string containing the full path to a file with email addresses,
which gets appended to the posters list. It's very useful to us, because we
have a lot of employees with a *lot* of aliases, and they post from every
one ;) but it's not particularly secure, currently.

The other patch is a very rudementary Archive access restriction: We send a
lot of private information over the lists, and it wouldn't do for someone
from, say, a competing company to guess an employee's mailman password and
thus gain access to the list archives. However, I do want to use mailman
password checking for the archives, so I can't use a 'public' archive with a
normal .htaccess restriction.

So I've added a list of strings (containing (parts of) ipaddresses or
networks) which are matched against the REMOTE_ADDR environment, which
should contain the ipaddress of the requester. To do that, I've also added a
StringList field type, which is like the EmailList field type, stripping and
filtering the list of strings, but without the Email validation check.

Let me know if anyone wants to see those patches.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From chuqui@plaidworks.com  Tue Jun  6 00:03:03 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Mon, 5 Jun 2000 16:03:03 -0700
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
References: <20000606005050.D469@xs4all.nl>
Message-ID: <p04310109b561e1abc513@[17.216.27.193]>

At 12:50 AM +0200 6/6/2000, Thomas Wouters wrote:

>Oh, I also have two other small patches lying around, but I'm not sure if
>they're suitable for inclusion. One is a 'posters-file' config setting,
>which is a string containing the full path to a file with email addresses,
>which gets appended to the posters list. It's very useful to us,

This is a very useful thing in any number of situations. I use it on 
my lists a lot. It's quite nice if you have automatically generated 
email or gateways feeding content, where you don't really want to 
subscribe something and turn on nomail. And it' prevents some joker 
from playing with those nomailed subscriptions beyhind your back...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bigdog@dogpound.vnet.net  Tue Jun  6 00:06:22 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Mon, 5 Jun 2000 19:06:22 -0400 (EDT)
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
Message-ID: <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>

On Tue, 6 Jun 2000, Thomas Wouters wrote:

> Oh, I also have two other small patches lying around, but I'm not sure if
> they're suitable for inclusion. One is a 'posters-file' config setting,
> which is a string containing the full path to a file with email addresses,
> which gets appended to the posters list. It's very useful to us, because we
> have a lot of employees with a *lot* of aliases, and they post from every
> one ;) but it's not particularly secure, currently.

How is this edited?  Manually with 'pico' or whatever?  or via the web?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Why do they tell us to watch "The Today Show" tomorrow?
----------------------------------------------------------------
Monday, June 05, 2000 / 07:05PM



From thomas@xs4all.net  Tue Jun  6 00:16:58 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 6 Jun 2000 01:16:58 +0200
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>; from bigdog@dogpound.vnet.net on Mon, Jun 05, 2000 at 07:06:22PM -0400
References: <20000606005050.D469@xs4all.nl> <Pine.LNX.4.21.0006051905420.8733-100000@dogpound.vnet.net>
Message-ID: <20000606011658.E469@xs4all.nl>

On Mon, Jun 05, 2000 at 07:06:22PM -0400, Matt Davis wrote:
> On Tue, 6 Jun 2000, Thomas Wouters wrote:

> > Oh, I also have two other small patches lying around, but I'm not sure if
> > they're suitable for inclusion. One is a 'posters-file' config setting,
> > which is a string containing the full path to a file with email addresses,
> > which gets appended to the posters list. It's very useful to us, because we
> > have a lot of employees with a *lot* of aliases, and they post from every
> > one ;) but it's not particularly secure, currently.

> How is this edited?  Manually with 'pico' or whatever?  or via the web?

It's currently manually edited, through joe or vi usually, but most of it is
probably going to be automatically generated from our database soonish.
(hopefully, anyway :P) The patch to Mailman only handles configuring the
filename, and opening the file and appending the list of addresses to the
poster_list at the appropriate moment, not the actual editing.

This is very much a hack. A much better solution would be for lists to be
'slaved' to another, so that anyone on the master list can post to the slave
list, and subscribe to the slave list without approval, etc. Then you'd only
have to update the master lists' poster_list, and it'd also fix some of my
other problems ;) (but those are probably very rare, anyway.) The alias
problem would also go away if we had a true user database, of course, and a
means of accessing and altering it from other programs ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From troy@akropolys.com  Tue Jun  6 02:55:41 2000
From: troy@akropolys.com (Troy Morrison)
Date: Mon, 5 Jun 2000 18:55:41 -0700 (PDT)
Subject: [Mailman-Developers] unsubscription-approval
In-Reply-To: <20000606005050.D469@xs4all.nl>
Message-ID: <Pine.LNX.4.21.0006051840270.9575-100000@exeter.akropolys.com>

| The other patch is a very rudementary Archive access restriction: We send a
| lot of private information over the lists, and it wouldn't do for someone
| from, say, a competing company to guess an employee's mailman password and
| thus gain access to the list archives. However, I do want to use mailman
| password checking for the archives, so I can't use a 'public' archive with a
| normal .htaccess restriction.

I could be completely missing the point of this, but I run a small list,
mostly for friends and such, where the subscribers wanted archives, but
didn't want 'public' archives.  I wanted MIME/attachment support.  I
started out using pipermail/Mailman's archives, but didn't like them (and
this was back when they were CPU intensive too), so I switch to an
external archiver.

I'm using qmail, so I created an "archives" user, and gave him a
".qmail-default" file like:

|preline /usr/local/bin/hypermail [ ... ]
|preline cat >> ./$DEFAULT-`date +"%m-%Y" && exit 0

And then I subscribe "archives-<listname>" to each list.

Anyway, the point that's specifically relevant to what Thomas said was
that I wanted these decidedly non-Mailman archives to be accessible to
subscribers only via their list password.  So I hacked up this (probably
very ugly -- I didn't know Python and really still don't) script to
generate my .htaccess files in a cron job:

---------8< snip 8<------------
#!/usr/bin/env python

import sys, whrandom, crypt

sys.path.insert(0, '/home/mailman');
from Mailman import MailList, Utils;

passwdfile=open('/home/archives/public_html/list1/.htpasswd', 'w')
list1=MailList.MailList('list1', lock=0)
generator = whrandom.whrandom()

for x in list1.passwords.keys():
	pw = list1.passwords[x]
	passwdcrypt = crypt.crypt(pw, "L1")
	passwdfile.write(x + ":" + passwdcrypt + "\n")

passwdfile.close()

# <repeat for each list>

---------8< snip 8<------------

There is a delay between when someone subscribes or changes their password
and the corresponding update to the archives password file, which is
probably not the best thing, but I've just made sure that everyone is
aware of the delay.

So, anyway, I just thought that the idea might be useful to others using
Mailman...

Troy



From brett@iclick.com  Tue Jun  6 05:26:51 2000
From: brett@iclick.com (Brett Dikeman)
Date: Tue, 6 Jun 2000 00:26:51 -0400
Subject: [Mailman-Developers] num_spawns not used in v2.0?
Message-ID: <p04320404b56228a3e448@[192.168.111.3]>

As the little old lady says, "where's the beef?"

In 1.1, Deliverer.py used num_spawns, but v2.0 doesn't use it 
anywhere.  So, the end result is that my system isn't doing any 
splitting.  This is causing mail delivery problems(specifically, it's 
taking 30 minutes when it used to take 2-3 when I was running 1.1)

This was based on a quick look/search by a friend and I; we know next 
to nothing about Python, so I may not have things exactly right, but 
we know when we can't find a variable in use anywhere and we're 
pretty sure on that part :-)

What's the scoop?  When will this feature be re-enabled?

Thx,
Brett
-- 
----
Brett Dikeman				Systems Engineer
iClick, Inc					914-872-8043
120 Bloomingdale Rd.			914-872-8100(fax)
White Plains, NY 10605			http://www.iclick.com


From marc_news@valinux.com  Tue Jun  6 06:51:36 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 5 Jun 2000 22:51:36 -0700
Subject: [Mailman-Developers] Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue
Message-ID: <20000605225136.C7529@marc.merlins.org>

I just upgraded to 2000/06/05's CVS and I'm getting those now:

5 of these:
----- Forwarded message from Cron Daemon <root@marc.merlins.org> -----

Subject: Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue

Traceback (innermost last):
  File "/var/local/mailman/cron/run_queue", line 46, in ?
    main()
  File "/var/local/mailman/cron/run_queue", line 43, in main
    lockfile.unlock()
  File "/var/local/mailman/Mailman/LockFile.py", line 302, in unlock
    raise NotLockedError
Mailman.LockFile.NotLockedError

----- End forwarded message -----

1 of those:
----- Forwarded message from Cron Daemon <root@marc.merlins.org> -----

Subject: Cron <mailman@marc> /usr/bin/python /var/local/mailman/cron/run_queue

Traceback (innermost last):
  File "/var/local/mailman/cron/run_queue", line 46, in ?
    main()
  File "/var/local/mailman/cron/run_queue", line 39, in main
    lockfile.lock()
  File "/var/local/mailman/Mailman/LockFile.py", line 284, in lock
    self.__break()
  File "/var/local/mailman/Mailman/LockFile.py", line 408, in __break
    if winner:
OSError: [Errno 2] No such file or directory: '/var/local/mailman/locks/mmqueue_run.lock.marc.merlins.org.29127'

----- End forwarded message -----

-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From gpoo@ubiobio.cl  Tue Jun  6 16:29:52 2000
From: gpoo@ubiobio.cl (German Poo Caaman~o)
Date: Tue, 6 Jun 2000 12:29:52 -0300 (ADT)
Subject: [Mailman-Developers] Multilingual support
Message-ID: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>

I've downloaded Mailman-2.0b2 and I'v translated the templates files
to spanish, but it wasn't enough.  Some web pages appears with
english and spanish words.

Are there some language support on mind?   May be, a language file
where reside all words used on the interface (buttons, messages,
etc.).

--
German Poo Caaman~o
mailto:gpoo@ubiobio.cl
http://www.ubiobio.cl/~gpoo/chilelindo.html




From andrea@integra-italia.com  Wed Jun  7 15:21:06 2000
From: andrea@integra-italia.com (Andrea Paparelli)
Date: Wed, 7 Jun 2000 16:21:06 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
Message-ID: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>

Bug in Mailman version 1.1

We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of
this page to the webmaster for this site with a description of what
happened. Thanks!

Traceback:


Traceback (innermost last):
  File "/home/staff/mailman/scripts/driver", line 112, in run_main
    main()
  File "/home/staff/mailman/Mailman/Cgi/admin.py", line 103, in main
    is_auth = lst.WebAuthenticate(password=adminpw,
  File "/home/staff/mailman/Mailman/SecurityManager.py", line 83, in
WebAuthenticate
    return self.CheckCookie(cookie_key)
  File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
CheckCookie
    if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
IndexError: string index out of range





----------------------------------------------------------------------------
----

Environment variables:
Variable Value
DOCUMENT_ROOT  /home/httpd/docs
HTTP_ACCEPT_ENCODING  gzip, deflate
SERVER_PORT  80
PATH_TRANSLATED  /home/httpd/docs/dbsee
HTTP_ACCEPT_LANGUAGE  it
GATEWAY_INTERFACE  CGI/1.1
SERVER_NAME  mailman.starlink.it
HTTP_CONNECTION  Keep-Alive
HTTP_USER_AGENT  Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
HTTP_ACCEPT  */*
REQUEST_URI  /mailman/admin.cgi/dbsee
PATH  /sbin:/usr/sbin:/bin:/usr/bin
QUERY_STRING
SCRIPT_FILENAME  /home/staff/mailman/cgi-bin/admin.cgi
PATH_INFO  /dbsee
HTTP_HOST  mailman.starlink.it
REQUEST_METHOD  GET
SERVER_SIGNATURE
SCRIPT_NAME  /mailman/admin.cgi
SERVER_ADMIN  root@localhost
SERVER_SOFTWARE  Apache/1.3.3 (Unix) (Red Hat/Linux)
PYTHONPATH  /home/staff/mailman
HTTP_COOKIE  PUPALANGID=1
SERVER_PROTOCOL  HTTP/1.1
REMOTE_PORT  2868



From mentor@alb-net.com  Wed Jun  7 17:45:12 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 7 Jun 2000 12:45:12 -0400 (EDT)
Subject: [Mailman-Developers] multifile.Error :  sudden EOF in MultiFile.readline()
Message-ID: <Pine.GSO.4.21.0006071244180.25061-100000@alb-net.com>

FYI...

Jun 07 11:52:27 2000 post(22115): Traceback (innermost last):
post(22115):   File "/opt/home/mailman/scripts/mailowner", line 89, in ?
post(22115):      main()
post(22115):   File "/opt/home/mailman/scripts/mailowner", line 68, in main
post(22115):      if BouncerAPI.ScanMessages(mlist, msg):
post(22115):   File "/opt/home/mailman/Mailman/Bouncers/BouncerAPI.py",line 50$
post(22115):      addrs = func(msg)
post(22115):   File "/opt/home/mailman/Mailman/Bouncers/Postfix.py", line46, i$
post(22115):      s = StringIO(mfile.read())
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 118, inread
post(22115):      return string.joinfields(self.readlines(), '')
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 112, inreadl$
post(22115):      line = self.readline()
post(22115):   File "/usr/local/lib/python1.5/multifile.py", line 77, inreadli$
post(22115):      raise Error, 'sudden EOF in MultiFile.readline()'
post(22115): multifile.Error :  sudden EOF in MultiFile.readline()



From mentor@alb-net.com  Wed Jun  7 17:54:53 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Wed, 7 Jun 2000 12:54:53 -0400 (EDT)
Subject: [Mailman-Developers] again..... duplicated messages to 7356!!!! (fwd)
Message-ID: <Pine.GSO.4.21.0006071253410.25061-200000@alb-net.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-959030623-960272479=:25061
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.GSO.4.21.0006071253451.25061@alb-net.com>


I think it happened again.....

A messages sent to a list of 2000+ subscribers got distributed twice...

later,
mentor

---------- Forwarded message ----------
Date: Tue, 6 Jun 2000 02:21:19 -0400 (EDT)
From: Mentor Cana <mentor@alb-net.com>
To: "Barry A. Warsaw" <bwarsaw@python.org>
Subject: duplicated messages to 7356!!!!
Message-ID: <Pine.GSO.4.21.0006060213030.25061-200000@alb-net.com>
Organization: "http://www.alb-net.com/"
X-Loop: MENTOR
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
    BOUNDARY="-559023410-959030623-960272479=:25061"

Barry,

Tonight, using the latest CVS (6/5 afternoon), thinking that everything is
fine, I e-mailed a message to one of my lists with 7400+ users.

After some time I saw the following in my logs/smtp
---
Jun 06 00:57:18 2000 (21787) smtp for 7356 recips, completed in 387.864 seconds
Jun 06 01:01:09 2000 (22111) smtp for 1 recips, completed in 46.683 seconds
Jun 06 01:09:46 2000 (20628) smtp for 7356 recips, completed in 2249.145 seconds
---

Obviously, the message was supposed to be delivered only once. Instead, it
went out twice. When I saw this, I cleaned all the files related to
kcc-news list in the qfile/ dir. This stopped from sending any further
messages. Maybe even without my deletion of the /qfile would not have sent
any additional messages. Just to be on the safe side. 

Anyways, attached is the related portion of the logs/error file to help you
troubshoot the issue. You wold agree, this should not be happening...

the cron/qrunner was set to run every minute.....

The error file says that the kcc-news list file was corrupted, however, it
seems to be just fine.

Let me know if you need further info to troubshoot the problem. 

later,
mentor
P.S. time to get some sleep...


---559023410-959030623-960272479=:25061
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=error-1
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.21.0006060221190.25061@alb-net.com>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME=error-1

SnVuIDA2IDAwOjAyOjAyIDIwMDAgcXJ1bm5lcigyMDA4Myk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjIwOjAzIDIwMDAg
cXJ1bm5lcigyMDY1MCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjIxOjAyIDIwMDAgcXJ1bm5lcigyMDY4MCk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjIyOjAxIDIw
MDAgcXJ1bm5lcigyMDcxNSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjIzOjAzIDIwMDAgcXJ1bm5lcigyMDc0MCk6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI0OjAx
IDIwMDAgcXJ1bm5lcigyMDc3Mik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjI1OjAyIDIwMDAgcXJ1bm5lcigyMDc5Mik6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI2
OjAyIDIwMDAgcXJ1bm5lcigyMDgxMSk6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI3OjAyIDIwMDAgcXJ1bm5lcigyMDg0
MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAw
OjI4OjAxIDIwMDAgcXJ1bm5lcigyMDg3Mik6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjI5OjAxIDIwMDAgcXJ1bm5lcigy
MDg5OCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAwOjMwOjA1IDIwMDAgcXJ1bm5lcigyMDkzNyk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjMxOjAzIDIwMDAgcXJ1bm5l
cigyMDk4MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAwOjMyOjAxIDIwMDAgcXJ1bm5lcigyMTAwNik6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjMzOjAxIDIwMDAgcXJ1
bm5lcigyMTAxNSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0K
SnVuIDA2IDAwOjM0OjAyIDIwMDAgcXJ1bm5lcigyMTA1OCk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM1OjAzIDIwMDAg
cXJ1bm5lcigyMTE0NCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjM2OjAyIDIwMDAgcXJ1bm5lcigyMTE5OCk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM3OjAyIDIw
MDAgcXJ1bm5lcigyMTIyMyk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjM4OjAyIDIwMDAgcXJ1bm5lcigyMTMzNSk6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjM5OjAy
IDIwMDAgcXJ1bm5lcigyMTQwMCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjQwOjAxIDIwMDAgcXJ1bm5lcigyMTQ0Nyk6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQx
OjAyIDIwMDAgcXJ1bm5lcigyMTQ3MCk6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQyOjAyIDIwMDAgcXJ1bm5lcigyMTU2
MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAw
OjQzOjAyIDIwMDAgcXJ1bm5lcigyMTYxNSk6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ0OjAyIDIwMDAgcXJ1bm5lcigy
MTY1Nik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAwOjQ1OjAyIDIwMDAgcXJ1bm5lcigyMTY2MCk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ2OjAyIDIwMDAgcXJ1bm5l
cigyMTY4Nik6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAwOjQ3OjAyIDIwMDAgcXJ1bm5lcigyMTcyOCk6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjQ4OjAzIDIwMDAgcXJ1
bm5lcigyMTc1MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0K
SnVuIDA2IDAwOjQ5OjAyIDIwMDAgcXJ1bm5lcigyMTc1Nyk6IENvdWxkIG5v
dCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjUxOjAyIDIwMDAg
cXJ1bm5lcigyMTg0MSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9j
aw0KSnVuIDA2IDAwOjUyOjAxIDIwMDAgcXJ1bm5lcigyMTkwNyk6IENvdWxk
IG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjUzOjAzIDIw
MDAgcXJ1bm5lcigyMTk5NSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIg
bG9jaw0KSnVuIDA2IDAwOjU0OjE0IDIwMDAgcXJ1bm5lcigyMjEwMik6IENv
dWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU1OjAz
IDIwMDAgcXJ1bm5lcigyMjE1Myk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5u
ZXIgbG9jaw0KSnVuIDA2IDAwOjU2OjIwIDIwMDAgcXJ1bm5lcigyMjIwMik6
IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU4
OjMzIDIwMDAgcXJ1bm5lcigyMjMxMik6IENvdWxkIG5vdCBhY3F1aXJlIHFy
dW5uZXIgbG9jaw0KSnVuIDA2IDAwOjU4OjMzIDIwMDAgcXJ1bm5lcigyMjI0
OSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAx
OjAxOjExIDIwMDAgcG9zdCgyMjM2NCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMjM2NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIy
MzY0KTogICAgICBtYWluKCkNCnBvc3QoMjIzNjQpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyMjM2NCk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIy
MzY0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjIzNjQpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMjM2NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDIyMzY0KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyMjM2NCk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6MDE6MTIgMjAwMCBwb3N0KDIy
MTExKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMTEx
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIxMTEpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjExMSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIyMTExKTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjIxMTEpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyMjExMSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDIyMTExKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjIxMTEpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIy
MTExKTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTowMToyOSAyMDAwICgyMjQ3OCkga2NjLW5ld3MgZGIgZmlsZSB3
YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFu
L2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MDE6
MzAgMjAwMCAoMjI0ODkpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQs
IHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2Mt
bmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjAxOjMxIDIwMDAgKDIy
NDg5KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVw
DQpKdW4gMDYgMDE6MDE6MzIgMjAwMCAoMjI0NzgpIGtjYy1uZXdzIGZhbGxi
YWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTowMTo0NiAy
MDAwIHBvc3QoMjIwMTcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjIwMTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjAxNyk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyMDE3KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjIwMTcpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyMDE3KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjAxOjU1IDIwMDAgcG9zdCgyMjAzNik6IFRyYWNlYmFjayAoaW5uZXJt
b3N0IGxhc3QpOg0KcG9zdCgyMjAzNik6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMDM2KTogICAgICBtYWluKCkNCnBvc3QoMjIwMzYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjAzNik6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIwMzYpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6MDI6MDEgMjAwMCAoMjI1NDYpIGtjYy1uZXdzIGRi
IGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUv
bWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2
IDAxOjAyOjAxIDIwMDAgKDIyNTYwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBj
b3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlz
dHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTowMjowMSAy
MDAwICgyMjU1NCkga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNp
bmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdz
L2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MDI6MDEgMjAwMCAoMjI1NTgp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjAyOjAxIDIwMDAgKDIyNTQ0KSBrY2MtbmV3cyBk
YiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21l
L21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAw
NiAwMTowMjowMiAyMDAwICgyMjU0Nikga2NjLW5ld3MgZmFsbGJhY2sgd2Fz
IGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjAyOjAyIDIwMDAgKDIy
NTYwKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVw
DQpKdW4gMDYgMDE6MDI6MDIgMjAwMCAoMjI1NDQpIGtjYy1uZXdzIGZhbGxi
YWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTowMjowMiAy
MDAwICgyMjU1OCkga2NjLW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdp
dmluZyB1cA0KSnVuIDA2IDAxOjAyOjAzIDIwMDAgKDIyNTU0KSBrY2MtbmV3
cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6
MDI6MDMgMjAwMCBwb3N0KDIyNTQ2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDI6
MDMgMjAwMCBwb3N0KDIyNTQ0KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVy
IGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDI6MTQg
MjAwMCBwb3N0KDIyMDgwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIyMDgwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIwODApOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMjA4MCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIyMDgwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMjA4MCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAw
NiAwMTowMjoxNSAyMDAwIHBvc3QoMjIwNjIpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIwNjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjA2Mik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDYyKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIwNjIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMDYyKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjAyOjE5IDIwMDAgcG9zdCgyMjA3NCk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjA3NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIyMDc0KTogICAgICBtYWluKCkNCnBvc3QoMjIwNzQp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjA3NCk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIwNzQpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDI6MjAgMjAwMCBwb3N0KDIy
MDg3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMDg3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIwODcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjA4Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMDg3KTog
ICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjA4
Nyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowMjo1MyAy
MDAwIHBvc3QoMjIxMTgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjIxMTgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjExOCk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyMTE4KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjIxMTgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyMTE4KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjAzOjAxIDIwMDAgcG9zdCgyMjEyNCk6IFRyYWNlYmFjayAoaW5uZXJt
b3N0IGxhc3QpOg0KcG9zdCgyMjEyNCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMTI0KTogICAgICBtYWluKCkNCnBvc3QoMjIxMjQpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjEyNCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIxMjQpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6MDM6MTIgMjAwMCBwb3N0KDIyNDg5KTogTWFpbG1h
biBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdz
DQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjAzOjMyIDIwMDAgcXJ1bm5l
cigyMjYzMSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAxOjAzOjQ1IDIwMDAgcG9zdCgyMjE2MSk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjE2MSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIyMTYxKTogICAgICBtYWluKCkNCnBvc3QoMjIxNjEpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMjE2MSk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIxNjEpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6MDQ6MDcgMjAwMCBwb3N0KDIyMjU1KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMjU1KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjIyNTUpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjI1
NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIyMjU1KTogICAgICBtbGlz
dC5TYXZlKCkNCnBvc3QoMjIyNTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0K
cG9zdCgyMjI1NSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0
KDIyMjU1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xv
Y2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjIyNTUp
OiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIyMjU1KTogTWFp
bG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTow
NDoxMyAyMDAwIHBvc3QoMjIxNzMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjIxNzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjE3
Myk6ICAgICAgbWFpbigpDQpwb3N0KDIyMTczKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjIxNzMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyMTczKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjA0OjU1IDIwMDAgcG9zdCgyMjIxOCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjIxOCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyMjE4KTogICAgICBtYWluKCkNCnBvc3QoMjIyMTgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjIxOCk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIyMTgpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDU6MDcgMjAwMCBwb3N0KDIyMDk4KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMDk4KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjIwOTgpOiAgICAgIG1haW4oKQ0KcG9zdCgy
MjA5OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMDk4KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjA5OCk6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowNToxNSAyMDAwIHBv
c3QoMjIwMzIpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTowNToxNSAyMDAwIHBvc3QoMjIxODMpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIwMzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjAzMik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDMyKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIwMzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMTgzKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjIxODMpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjE4Myk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYx
LCBpbiBtYWluDQpwb3N0KDIyMTgzKTogICAgICBleGNlcHQgTG9ja0ZpbGUu
VGltZU91dEVycm9yOg0KcG9zdCgyMjAzMik6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCnBvc3QoMjIxODMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MDU6MTcgMjAwMCBwb3N0KDIyMjM3KTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMjM3KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjIyMzcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjIzNyk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyMjM3KTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjIzNyk6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMTowNTozOSAyMDAwIHBvc3QoMjIyNjIpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjIyNjIpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjI2Mik6ICAgICAgbWFpbigpDQpwb3N0KDIy
MjYyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjIyNjIpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMjYyKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjA1OjU2IDIwMDAgcG9z
dCgyMjI4MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjI4MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMjgwKTogICAgICBtYWlu
KCkNCnBvc3QoMjIyODApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjI4
MCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjIyODApOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDU6
NTggMjAwMCBwb3N0KDIyMjc4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyMjc4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIyNzgp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjI3OCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyMjc4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjI3OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowNjowMiAyMDAwICgyMjE5NikgRGVsaXZlcnkgZXhjZXB0aW9u
OiANCkp1biAwNiAwMTowNjowNSAyMDAwICgyMjE5NikgVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERl
bGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQog
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01U
UERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5T
YXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWls
TGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2su
cmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNl
IE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAw
MTowNjowOSAyMDAwIHBvc3QoMjIwMjIpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjIwMjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
MjAyMik6ICAgICAgbWFpbigpDQpwb3N0KDIyMDIyKTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjIwMjIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDIyMDIyKTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjA2OjE0IDIwMDAgcG9zdCgyMjE0MCk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjE0MCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIyMTQwKTogICAgICBtYWluKCkNCnBvc3QoMjIxNDApOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjE0MCk6ICAgICAgZXhjZXB0IExv
Y2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIxNDApOiBOYW1lRXJyb3Ig
OiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNTYw
KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6
IGtjYy1uZXdzDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNTU4KTog
TWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtj
Yy1uZXdzDQpKdW4gMDYgMDE6MDY6MTggMjAwMCBwb3N0KDIyNDc4KTogTWFp
bG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1u
ZXdzDQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjA2OjE5IDIwMDAgcG9z
dCgyMjU1NCk6IE1haWxtYW4gZXJyb3I6IG1haWxvd25lciBnb3QgYmFkIGxp
c3RuYW1lOiBrY2MtbmV3cw0KYmFkIG1hcnNoYWwgZGF0YUp1biAwNiAwMTow
NjoyMCAyMDAwIHBvc3QoMjIxMzIpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjIxMzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjEz
Mik6ICAgICAgbWFpbigpDQpwb3N0KDIyMTMyKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjIxMzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyMTMyKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjA2OjIxIDIwMDAgcG9zdCgyMjIyNik6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjIyNik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyMjI2KTogICAgICBtYWluKCkNCnBvc3QoMjIyMjYpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjIyNik6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIyMjYpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDY6MzMgMjAwMCBwb3N0KDIyMzA2KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMzA2KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjIzMDYpOiAgICAgIG1haW4oKQ0KcG9zdCgy
MjMwNik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyMzA2KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjMwNik6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTowNjo0NSAyMDAwIHBv
c3QoMjIzMDEpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTowNjo0NSAyMDAwIHBvc3QoMjIzMTgpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjIzMDEpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjMwMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyMzAxKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjIzMDEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyMzAxKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KcG9zdCgyMjMxOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMzE4
KTogICAgICBtYWluKCkNCnBvc3QoMjIzMTgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjMxOCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjIzMTgpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MDY6NTYgMjAwMCBwb3N0KDIyMzE2KTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyMzE2KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjIzMTYpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjMxNik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyMzE2KTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjMxNik6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMTowNjo1NyAyMDAwIHBvc3QoMjIyOTMpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjIyOTMpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjI5Myk6ICAgICAgbWFpbigpDQpwb3N0KDIy
MjkzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjIyOTMpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMjkzKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjA3OjI5IDIwMDAgcG9z
dCgyMjMzMyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjMzMyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyMzMzKTogICAgICBtYWlu
KCkNCnBvc3QoMjIzMzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjMz
Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjIzMzMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDc6
NDMgMjAwMCBwb3N0KDIyMzgxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyMzgxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjIzODEp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjM4MSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyMzgxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjM4MSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowNzo0NSAyMDAwIHBvc3QoMjIzNzgpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjIzNzgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyMjM3OCk6ICAgICAgbWFpbigpDQpwb3N0KDIyMzc4KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjIzNzgpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyMzc4KTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjA3OjQ2IDIwMDAgcG9zdCgyMjM2Mik6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjM2Mik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDIyMzYyKTogICAgICBtYWluKCkNCnBvc3QoMjIz
NjIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjM2Mik6ICAgICAgZXhj
ZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIzNjIpOiBOYW1l
RXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MDc6NTYgMjAwMCBwb3N0
KDIyMzg5KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYg
MDE6MDc6NTYgMjAwMCBwb3N0KDIyMzg3KTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIyMzg3KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjIzODcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjM4Nyk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDIyMzg3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KcG9zdCgyMjM4OSk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0
KDIyMzg5KTogICAgICBtYWluKCkNCnBvc3QoMjIzODkpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwg
aW4gbWFpbg0KcG9zdCgyMjM4OSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRp
bWVPdXRFcnJvcjoNCnBvc3QoMjIzODcpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpwb3N0KDIyMzg5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjA4OjIyIDIwMDAgcG9zdCgyMjM1Myk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjM1Myk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIyMzUzKTogICAgICBtYWluKCkNCnBvc3QoMjIzNTMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMjM1Myk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjIzNTMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6MDg6MjUgMjAwMCBxcnVubmVyKDIyMzcxKTog
Q291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MDg6
MjggMjAwMCBwb3N0KDIyNDExKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyNDExKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI0MTEp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjQxMSk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyNDExKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjQxMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTowODo0MSAyMDAwIHFydW5uZXIoMjI0MjMpOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowODo0OSAyMDAwIHFy
dW5uZXIoMjI3MjApOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sN
Ckp1biAwNiAwMTowODo1MSAyMDAwIHFydW5uZXIoMjI1NjYpOiBDb3VsZCBu
b3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowODo1MSAyMDAw
IHFydW5uZXIoMjI2OTIpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxv
Y2sNCkp1biAwNiAwMTowOToxMyAyMDAwIHFydW5uZXIoMjI4MDgpOiBDb3Vs
ZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowOToxNCAy
MDAwIHFydW5uZXIoMjI3NTMpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVy
IGxvY2sNCkp1biAwNiAwMTowOToxNSAyMDAwIHFydW5uZXIoMjI4MjEpOiBD
b3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTowOTo0
OCAyMDAwICgyMjE4OCkgRGVsaXZlcnkgZXhjZXB0aW9uOiANCkp1biAwNiAw
MTowOTo1MCAyMDAwICgyMjE4OCkgVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxl
cnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERlbGl2ZXJUb0xpc3QN
CiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQogIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01UUERpcmVjdC5weSIs
IGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5TYXZlKCkNCiAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxp
bmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQog
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHki
LCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNlIE5vdExvY2tlZEVy
cm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAwMToxMDowNCAyMDAw
IHFydW5uZXIoMjI4MzUpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxv
Y2sNCkp1biAwNiAwMToxMToxOSAyMDAwIHBvc3QoMjI2MTEpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI2MTEpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyMjYxMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyNjExKTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI2MTEpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNjExKTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjExOjIwIDIwMDAgcG9zdCgyMjYx
NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjYxNSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjE1KTogICAgICBtYWluKCkNCnBv
c3QoMjI2MTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjYxNSk6ICAg
ICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI2MTUp
OiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTE6MjEgMjAw
MCBwb3N0KDIyNjIxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpw
b3N0KDIyNjIxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI2MjEpOiAgICAg
IG1haW4oKQ0KcG9zdCgyMjYyMSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0
KDIyNjIxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0K
cG9zdCgyMjYyMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAw
MToxMjo0MCAyMDAwIHFydW5uZXIoMjI5MTMpOiBDb3VsZCBub3QgYWNxdWly
ZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMToxMjo0NyAyMDAwIHBvc3QoMjI2
NTMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI2NTMp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjY1Myk6ICAgICAgbWFpbigpDQpw
b3N0KDIyNjUzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI2NTMpOiAg
ICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNjUz
KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjEyOjUwIDIw
MDAgcG9zdCgyMjY0Myk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyMjY0Myk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjQzKTogICAg
ICBtYWluKCkNCnBvc3QoMjI2NDMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyMjY0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjI2NDMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6MTM6MDEgMjAwMCBwb3N0KDIyNzg2KTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIyNzg2KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjI3ODYpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjc4Nik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBp
biBtYWluDQpwb3N0KDIyNzg2KTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3Qo
MjI3ODYpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFp
bExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyMjc4Nik6ICAg
ICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIyNzg2KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGlu
ZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjI3ODYpOiAgICAgIHJhaXNlIE5v
dExvY2tlZEVycm9yDQpwb3N0KDIyNzg2KTogTWFpbG1hbi5Mb2NrRmlsZSAu
IE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMToxNDoxMSAyMDAwIHBvc3Qo
MjI5MzApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI5
MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjkzMCk6ICAgICAgbWFpbigp
DQpwb3N0KDIyOTMwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjI5MzAp
OiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMjkzMCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYw
LCBpbiBTYXZlDQpwb3N0KDIyOTMwKTogICAgICBzZWxmLl9fbG9jay5yZWZy
ZXNoKCkNCnBvc3QoMjI5MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
cG9zdCgyMjkzMCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3Qo
MjI5MzApOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0K
SnVuIDA2IDAxOjE1OjA3IDIwMDAgcG9zdCgyMjczNSk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjczNSk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyNzM1KTogICAgICBtYWluKCkNCnBvc3QoMjI3MzUpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjczNSk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI3MzUpOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTU6NTAgMjAwMCBwb3N0KDIyNzc3KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYgMDE6MTU6NTAg
MjAwMCBwb3N0KDIyNzgxKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIyNzc3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI3NzcpOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMjc3Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIyNzc3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMjc3Nyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3Qo
MjI3ODEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjc4MSk6ICAgICAgbWFp
bigpDQpwb3N0KDIyNzgxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI3
ODEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0
KDIyNzgxKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjE1
OjU0IDIwMDAgcG9zdCgyMjc3OSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMjc3OSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNzc5
KTogICAgICBtYWluKCkNCnBvc3QoMjI3NzkpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjc3OSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjI3NzkpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MTU6NTcgMjAwMCBwb3N0KDIyNzkxKTogVHJhY2ViYWNrIChp
bm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyNzkxKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8N
CnBvc3QoMjI3OTEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjc5MSk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDYxLCBpbiBtYWluDQpwb3N0KDIyNzkxKTogICAgICBleGNlcHQgTG9ja0Zp
bGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjc5MSk6IE5hbWVFcnJvciA6ICBM
b2NrRmlsZSANCkp1biAwNiAwMToxNTo1NyAyMDAwIHBvc3QoMjI3OTQpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjI3OTQpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMjc5NCk6ICAgICAgbWFpbigpDQpwb3N0KDIy
Nzk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjI3OTQpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIyNzk0KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjE4OjI0IDIwMDAgKDIz
MjIwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMToxODo1MSAyMDAwIHFydW5uZXIoMjI5NjEp
OiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTox
ODo1OCAyMDAwIHBvc3QoMjI4NjcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBs
YXN0KToNCnBvc3QoMjI4NjcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjg2
Nyk6ICAgICAgbWFpbigpDQpwb3N0KDIyODY3KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1h
aW4NCnBvc3QoMjI4NjcpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0
RXJyb3I6DQpwb3N0KDIyODY3KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0K
SnVuIDA2IDAxOjE4OjU5IDIwMDAgcG9zdCgyMjg3MCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjg3MCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpwb3N0KDIyODcwKTogICAgICBtYWluKCkNCnBvc3QoMjI4NzApOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjg3MCk6ICAgICAgZXhjZXB0IExvY2tG
aWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI4NzApOiBOYW1lRXJyb3IgOiAg
TG9ja0ZpbGUgDQpKdW4gMDYgMDE6MTk6MDcgMjAwMCBwb3N0KDIyODk2KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyODk2KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjI4OTYpOiAgICAgIG1haW4oKQ0KcG9zdCgy
Mjg5Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyODk2KTogICAgICBl
eGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjg5Nik6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToxOToxNiAyMDAwIHBv
c3QoMjI1OTQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3Qo
MjI1OTQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjU5NCk6ICAgICAgbWFp
bigpDQpwb3N0KDIyNTk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjI1
OTQpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMjU5NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUg
ODYwLCBpbiBTYXZlDQpwb3N0KDIyNTk0KTogICAgICBzZWxmLl9fbG9jay5y
ZWZyZXNoKCkNCnBvc3QoMjI1OTQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVz
aA0KcG9zdCgyMjU5NCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBv
c3QoMjI1OTQpOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3Ig
IA0KSnVuIDA2IDAxOjE5OjIwIDIwMDAgcG9zdCgyMjk2OCk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjk2OCk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIyOTY4KTogICAgICBtYWluKCkNCnBvc3QoMjI5NjgpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4MywgaW4gbWFpbg0KcG9zdCgyMjk2OCk6ICAgICAgbWxpc3QuU2F2
ZSgpDQpwb3N0KDIyOTY4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3Qo
MjI5NjgpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMjk2
OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDIyOTY4KTogICAg
ICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyMjk2OCk6IE1haWxtYW4u
TG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6MTk6MzMg
MjAwMCBxcnVubmVyKDIzMjM4KTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5l
ciBsb2NrDQpKdW4gMDYgMDE6MTk6MzMgMjAwMCBxcnVubmVyKDIzMTI3KTog
Q291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MTk6
MzUgMjAwMCBwb3N0KDIyOTIwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIyOTIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI5MjAp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMjkyMCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIyOTIwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMjkyMCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMToxOTo0MCAyMDAwIHFydW5uZXIoMjMwNjApOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMToxOTo0NCAyMDAwIHFy
dW5uZXIoMjMwNjkpOiBDb3VsZCBub3QgYWNxdWlyZSBxcnVubmVyIGxvY2sN
Ckp1biAwNiAwMToxOTo0NyAyMDAwICgyMzAyOCkgRGVsaXZlcnkgZXhjZXB0
aW9uOiANCkp1biAwNiAwMToxOTo0NyAyMDAwICgyMzAyOCkgVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGlu
IERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEp
DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMv
U01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlz
dC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9N
YWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xv
Y2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxt
YW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJh
aXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAw
NiAwMToxOTo1NiAyMDAwIHBvc3QoMjI5MTEpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjI5MTEpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMjkxMSk6ICAgICAgbWFpbigpDQpwb3N0KDIyOTExKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjI5MTEpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIyOTExKTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjIwOjAwIDIwMDAgcG9zdCgyMjg3NSk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMjg3NSk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIyODc1KTogICAgICBtYWluKCkNCnBvc3QoMjI4NzUp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMjg3NSk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjI4NzUpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjA6MTcgMjAwMCBwb3N0KDIy
OTUwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyOTUw
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjI5NTApOiAgICAgIG1haW4oKQ0K
cG9zdCgyMjk1MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyOTUwKTog
ICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjk1
MCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToyMDoxOCAy
MDAwIHBvc3QoMjI5NTMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjI5NTMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMjk1Myk6ICAg
ICAgbWFpbigpDQpwb3N0KDIyOTUzKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjI5NTMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIyOTUzKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjIwOjMyIDIwMDAgKDIzMDM5KSBEZWxpdmVyeSBleGNlcHRpb246IA0K
SnVuIDA2IDAxOjIwOjMyIDIwMDAgKDIzMDM5KSBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVsaXZl
clRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQRGly
ZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNhdmUo
KQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0
LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5yZWZy
ZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2Nr
RmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2UgTm90
TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVuIDA2IDAxOjIw
OjM0IDIwMDAgcG9zdCgyMjk3MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMjk3MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyOTcx
KTogICAgICBtYWluKCkNCnBvc3QoMjI5NzEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFp
bg0KcG9zdCgyMjk3MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRF
cnJvcjoNCnBvc3QoMjI5NzEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpK
dW4gMDYgMDE6MjA6NDEgMjAwMCBxcnVubmVyKDIyOTk2KTogQ291bGQgbm90
IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MjA6NDYgMjAwMCBx
cnVubmVyKDIzMTU4KTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2Nr
DQpKdW4gMDYgMDE6MjA6NTEgMjAwMCBwb3N0KDIyOTgxKTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIyOTgxKTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjI5ODEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMjk4MSk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDYxLCBpbiBtYWluDQpwb3N0KDIyOTgxKTogICAgICBleGNlcHQgTG9j
a0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMjk4MSk6IE5hbWVFcnJvciA6
ICBMb2NrRmlsZSANCkp1biAwNiAwMToyMToyOCAyMDAwICgyMzA1NSkgRGVs
aXZlcnkgZXhjZXB0aW9uOiANCkp1biAwNiAwMToyMToyOCAyMDAwICgyMzA1
NSkgVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIs
IGxpbmUgNzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBt
c2csIG1zZ2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxt
YW4vSGFuZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nl
c3MNCiAgICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQog
ICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVm
cmVzaA0KICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJv
cjogDQoNCkp1biAwNiAwMToyMToyOSAyMDAwICgyMDYyOCkgRGVsaXZlcnkg
ZXhjZXB0aW9uOiANCkp1biAwNiAwMToyMTozMiAyMDAwICgyMDYyOCkgVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUg
NzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1z
Z2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAg
ICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2Vs
Zi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoN
Ckp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2MjgpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAwNiAwMToyMTozNiAyMDAwIHFy
dW5uZXIoMjA2MjgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL2Nyb24v
cXJ1bm5lciIsIGxpbmUgMTU0LCBpbiA/DQpKdW4gMDYgMDE6MjE6MzYgMjAw
MCBxcnVubmVyKDIwNjI4KTogICAgICBtYWluKCkNCkp1biAwNiAwMToyMToz
NiAyMDAwIHFydW5uZXIoMjA2MjgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL2Nyb24vcXJ1bm5lciIsIGxpbmUgMTM3LCBpbiBtYWluDQpKdW4gMDYg
MDE6MjE6MzYgMjAwMCBxcnVubmVyKDIwNjI4KTogICAgICBtbGlzdC5TYXZl
KCkNCkp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2MjgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBs
aW5lIDg2MCwgaW4gU2F2ZQ0KSnVuIDA2IDAxOjIxOjM2IDIwMDAgcXJ1bm5l
cigyMDYyOCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpKdW4gMDYg
MDE6MjE6MzYgMjAwMCBxcnVubmVyKDIwNjI4KTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGlu
IHJlZnJlc2gNCkp1biAwNiAwMToyMTozNiAyMDAwIHFydW5uZXIoMjA2Mjgp
OiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpKdW4gMDYgMDE6MjE6MzYg
MjAwMCBxcnVubmVyKDIwNjI4KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExv
Y2tlZEVycm9yICANCkp1biAwNiAwMToyMjowMiAyMDAwIHBvc3QoMjMwNDMp
OiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMwNDMpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4OSwgaW4gPw0KcG9zdCgyMzA0Myk6ICAgICAgbWFpbigpDQpwb3N0
KDIzMDQzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjMwNDMpOiAgICAg
IGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzMDQzKTog
TmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjIyOjEyIDIwMDAg
cG9zdCgyMzA0MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyMzA0MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMDQxKTogICAgICBt
YWluKCkNCnBvc3QoMjMwNDEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgy
MzA0MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBv
c3QoMjMwNDEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6
MjI6MTIgMjAwMCBwb3N0KDIzMDMxKTogVHJhY2ViYWNrIChpbm5lcm1vc3Qg
bGFzdCk6DQpwb3N0KDIzMDMxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1h
bi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMw
MzEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzAzMSk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBt
YWluDQpwb3N0KDIzMDMxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91
dEVycm9yOg0KcG9zdCgyMzAzMSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSAN
Ckp1biAwNiAwMToyMjoxNCAyMDAwIHBvc3QoMjMwMjUpOiBUcmFjZWJhY2sg
KGlubmVybW9zdCBsYXN0KToNCkp1biAwNiAwMToyMjoxNCAyMDAwIHBvc3Qo
MjMwNDUpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMw
MjUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzAyNSk6ICAgICAgbWFpbigp
DQpwb3N0KDIzMDI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjMwMjUp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIz
MDQ1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMwNDUpOiAgICAgIG1haW4o
KQ0KcG9zdCgyMzA0NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIzMDQ1
KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgy
MzAyNSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3QoMjMwNDUpOiBO
YW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjI6MTUgMjAwMCBw
b3N0KDIzMDM3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0
KDIzMDM3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMwMzcpOiAgICAgIG1h
aW4oKQ0KcG9zdCgyMzAzNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIz
MDM3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9z
dCgyMzAzNyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMToy
MjozMyAyMDAwICgyMjY4MCkgRGVsaXZlcnkgZXhjZXB0aW9uOiANCkp1biAw
NiAwMToyMjozNCAyMDAwICgyMjY4MCkgVHJhY2ViYWNrIChpbm5lcm1vc3Qg
bGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUgNzQsIGluIERlbGl2ZXJUb0xp
c3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1zZ2RhdGEpDQogIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFuZGxlcnMvU01UUERpcmVjdC5w
eSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAgICBtbGlzdC5TYXZlKCkNCiAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIs
IGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2VsZi5fX2xvY2sucmVmcmVzaCgp
DQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUu
cHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KICAgIHJhaXNlIE5vdExvY2tl
ZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoNCkp1biAwNiAwMToyMzo0MSAy
MDAwIHBvc3QoMjMwNzMpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjMwNzMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzA3Myk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzMDczKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjMwNzMpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIzMDczKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjIzOjUwIDIwMDAgcXJ1bm5lcigyMzMzNyk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjIzOjUwIDIwMDAgcG9zdCgy
MzA4OCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzA4
OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMDg4KTogICAgICBtYWluKCkN
CnBvc3QoMjMwODgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzA4OCk6
ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjMw
ODgpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6MjQ6MzQg
MjAwMCBwb3N0KDIzMTIwKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIzMTIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjMxMjApOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMzEyMCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpw
b3N0KDIzMTIwKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9y
Og0KcG9zdCgyMzEyMCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAw
NiAwMToyNTozNiAyMDAwIHBvc3QoMjMxODgpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjMxODgpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMzE4OCk6ICAgICAgbWFpbigpDQpwb3N0KDIzMTg4KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODMs
IGluIG1haW4NCnBvc3QoMjMxODgpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9z
dCgyMzE4OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9N
YWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDIzMTg4KTog
ICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjMxODgpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBs
aW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyMzE4OCk6ICAgICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCnBvc3QoMjMxODgpOiBNYWlsbWFuLkxvY2tGaWxl
IC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjI2OjAzIDIwMDAgcG9z
dCgyMjY1MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
MjY1MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIyNjUxKTogICAgICBtYWlu
KCkNCnBvc3QoMjI2NTEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgyMjY1
MSk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIyNjUxKTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4
NjAsIGluIFNhdmUNCnBvc3QoMjI2NTEpOiAgICAgIHNlbGYuX19sb2NrLnJl
ZnJlc2goKQ0KcG9zdCgyMjY1MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNo
DQpwb3N0KDIyNjUxKTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9z
dCgyMjY1MSk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAg
DQpKdW4gMDYgMDE6MjY6MzkgMjAwMCBwb3N0KDIzMDQ4KTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzMDQ4KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjMwNDgpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzA0OCk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzMDQ4KTogICAgICBtbGlzdC5TYXZl
KCkNCnBvc3QoMjMwNDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgy
MzA0OCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzMDQ4
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCkp1biAwNiAwMToyNjo0OCAy
MDAwIHBvc3QoMjM1MDgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjM1MDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzUwOCk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzNTA4KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBv
c3QoMjM1MDgpOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMzUwOCk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIs
IGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDIzNTA4KTogICAgICBzZWxmLl9f
bG9jay5yZWZyZXNoKCkNCnBvc3QoMjM1MDgpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4g
cmVmcmVzaA0KcG9zdCgyMzUwOCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJy
b3INCnBvc3QoMjMwNDgpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpw
b3N0KDIzNTA4KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9y
ICANCnBvc3QoMjMwNDgpOiBNYWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2Vk
RXJyb3IgIA0KSnVuIDA2IDAxOjI3OjE5IDIwMDAgKDIzNTU1KSBrY2MtbmV3
cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9o
b21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1
biAwNiAwMToyNzoyMCAyMDAwICgyMzU2MSkga2NjLW5ld3MgZGIgZmlsZSB3
YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFu
L2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6Mjc6
MjEgMjAwMCAoMjM1NDgpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQs
IHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2Mt
bmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjI3OjI0IDIwMDAgKDIz
NTYwKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMToyNzozNiAyMDAwIHBvc3QoMjMyMjApOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjMyMjApOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzIyMCk6ICAgICAgbWFpbigpDQpwb3N0KDIz
MjIwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjMyMjApOiAgICAgIG1s
aXN0LlNhdmUoKQ0KcG9zdCgyMzIyMCk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZl
DQpwb3N0KDIzMjIwKTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBv
c3QoMjMyMjApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyMzIy
MCk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjMyMjApOiBN
YWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAx
OjI5OjM2IDIwMDAgKDIzMTk2KSBEZWxpdmVyeSBleGNlcHRpb246IA0KSnVu
IDA2IDAxOjI5OjQyIDIwMDAgKDIzMTk2KSBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9I
YW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVsaXZlclRv
TGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQRGlyZWN0
LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNhdmUoKQ0K
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5yZWZyZXNo
KCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2UgTm90TG9j
a2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVuIDA2IDAxOjI5OjQ5
IDIwMDAgcG9zdCgyMzE5Nik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyMzE5Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzMTk2KTog
ICAgICBtYWluKCkNCnBvc3QoMjMxOTYpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0K
cG9zdCgyMzE5Nik6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIzMTk2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjMxOTYpOiAgICAgIHNlbGYu
X19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMzE5Nik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBp
biByZWZyZXNoDQpwb3N0KDIzMTk2KTogICAgICByYWlzZSBOb3RMb2NrZWRF
cnJvcg0KcG9zdCgyMzE5Nik6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2Nr
ZWRFcnJvciAgDQpKdW4gMDYgMDE6Mjk6NTggMjAwMCAoMjM3MDkpIGtjYy1u
ZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0
L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0K
SnVuIDA2IDAxOjI5OjU3IDIwMDAgcG9zdCgyMzIwOCk6IFRyYWNlYmFjayAo
aW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/
DQpKdW4gMDYgMDE6Mjk6NTggMjAwMCAoMjM3MDIpIGtjYy1uZXdzIGRiIGZp
bGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFp
bG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAx
OjI5OjU5IDIwMDAgKDIzNjk5KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3Jy
dXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMv
a2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCnBvc3QoMjMyMDgpOiAgICAgIG1h
aW4oKQ0KcG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIz
MjA4KTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjMyMDgpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5l
IDg2MCwgaW4gU2F2ZQ0KSnVuIDA2IDAxOjMwOjAwIDIwMDAgKDIzNzE2KSBr
Y2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazog
L29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxh
c3QNCnBvc3QoMjMyMDgpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0K
cG9zdCgyMzIwOCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDIz
MjA4KTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KSnVuIDA2IDAxOjMw
OjAyIDIwMDAgcG9zdCgyMzQ2Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMzQ2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDY3
KTogICAgICBtYWluKCkNCnBvc3QoMjM0NjcpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFp
bg0KcG9zdCgyMzQ2Nyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDIzNDY3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0
LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjM0NjcpOiAgICAgIHNl
bGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyMzQ2Nyk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0
LCBpbiByZWZyZXNoDQpwb3N0KDIzNDY3KTogICAgICByYWlzZSBOb3RMb2Nr
ZWRFcnJvcg0KcG9zdCgyMzQ2Nyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RM
b2NrZWRFcnJvciAgDQpwb3N0KDIzMjA4KTogTWFpbG1hbi5Mb2NrRmlsZSAu
IE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTozMDowNCAyMDAwICgyMzcw
OSkga2NjLW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0K
SnVuIDA2IDAxOjMwOjA2IDIwMDAgKDIzNzE2KSBrY2MtbmV3cyBmYWxsYmFj
ayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzA6MDcgMjAw
MCBwb3N0KDIzNzE2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBi
YWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6MzA6MTAgMjAwMCAo
MjM2OTkpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcg
dXANCkp1biAwNiAwMTozMDoxMCAyMDAwIHBvc3QoMjM2OTkpOiBNYWlsbWFu
IGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MN
Ckp1biAwNiAwMTozMToxMyAyMDAwICgyMzc4Mikga2NjLW5ld3MgZGIgZmls
ZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWls
bWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6
MzE6MTQgMjAwMCAoMjM3NTEpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1
cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9r
Y2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMxOjE2IDIwMDAg
KDIzNzgyKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5n
IHVwDQpKdW4gMDYgMDE6MzE6MTYgMjAwMCAoMjM3NTEpIGtjYy1uZXdzIGZh
bGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMTox
OSAyMDAwICgyMzc3MCkga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwg
dXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1u
ZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6MzE6MjUgMjAwMCAoMjM3
NzApIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXAN
Ckp1biAwNiAwMTozMTo0NCAyMDAwICgyMzgxOSkga2NjLW5ld3MgZGIgZmls
ZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWls
bWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6
MzE6NDUgMjAwMCAoMjM4MTkpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3Jy
dXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMTo0NSAyMDAwIHBvc3QoMjM4
MTkpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFt
ZToga2NjLW5ld3MNCkp1biAwNiAwMTozMTo0OSAyMDAwIHBvc3QoMjM3NTEp
OiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZTog
a2NjLW5ld3MNCmJhZCBtYXJzaGFsIGRhdGFKdW4gMDYgMDE6MzE6NTEgMjAw
MCAoMjM4MzIpIGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5n
IGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9j
b25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMyOjI2IDIwMDAgKDIzODYwKSBr
Y2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazog
L29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxh
c3QNCkp1biAwNiAwMTozMjoyOSAyMDAwICgyMzg2MCkga2NjLW5ld3MgZmFs
bGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjMyOjQ2
IDIwMDAgcG9zdCgyMzQ3MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyMzQ3MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDcwKTog
ICAgICBtYWluKCkNCnBvc3QoMjM0NzApOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0K
cG9zdCgyMzQ3MCk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJv
cjoNCnBvc3QoMjM0NzApOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4g
MDYgMDE6MzM6MjAgMjAwMCBwb3N0KDIzNTAxKTogVHJhY2ViYWNrIChpbm5l
cm1vc3QgbGFzdCk6DQpwb3N0KDIzNTAxKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjM1MDEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzUwMSk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYx
LCBpbiBtYWluDQpwb3N0KDIzNTAxKTogICAgICBleGNlcHQgTG9ja0ZpbGUu
VGltZU91dEVycm9yOg0KcG9zdCgyMzUwMSk6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCkp1biAwNiAwMTozMzozMyAyMDAwIHBvc3QoMjM0OTcpOiBUcmFj
ZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM0OTcpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4
OSwgaW4gPw0KcG9zdCgyMzQ5Nyk6ICAgICAgbWFpbigpDQpwb3N0KDIzNDk3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0OTcpOiAgICAgIGV4Y2Vw
dCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDk3KTogTmFtZUVy
cm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjMzOjM2IDIwMDAgKDIzOTI2
KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFj
azogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRi
Lmxhc3QNCkp1biAwNiAwMTozMzozOCAyMDAwICgyMzkyNikga2NjLW5ld3Mg
ZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjMz
OjQwIDIwMDAgcG9zdCgyMzU1MCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxh
c3QpOg0KcG9zdCgyMzU1MCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNTUw
KTogICAgICBtYWluKCkNCnBvc3QoMjM1NTApOiBNZW1vcnlFcnJvciAgDQpK
dW4gMDYgMDE6MzM6NDMgMjAwMCAoMjM5MzcpIGtjYy1uZXdzIGRiIGZpbGUg
d2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFpbG1h
bi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAxOjMz
OjQ0IDIwMDAgKDIzOTM5KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0
LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2Nj
LW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTozMzo0NiAyMDAwIHBv
c3QoMjM1MzApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3Qo
MjM1MzApOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFp
bG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzUzMCk6ICAgICAgbWFp
bigpDQpwb3N0KDIzNTMwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjM1
MzApOiAgICAgIG1saXN0LlNhdmUoKQ0KcG9zdCgyMzUzMCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUg
ODYwLCBpbiBTYXZlDQpKdW4gMDYgMDE6MzM6NDUgMjAwMCBwb3N0KDIzNDk0
KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpKdW4gMDYgMDE6MzM6
NDYgMjAwMCAoMjM5MzcpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0
LCBnaXZpbmcgdXANCkp1biAwNiAwMTozMzo0NiAyMDAwICgyMzkzOSkga2Nj
LW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KcG9zdCgy
MzUzMCk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzNTMw
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjM0OTQpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzQ5NCk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NDk0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0OTQpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDk0KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KcG9zdCgyMzUzMCk6ICAgICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCnBvc3QoMjM1MzApOiBNYWlsbWFuLkxvY2tGaWxl
IC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjMzOjU0IDIwMDAgKDIz
OTQ3KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNDozMSAyMDAwIHBvc3QoMjM1MjkpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM1MjkpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzUyOSk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NTI5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1MjkpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTI5KTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM0OjQ0IDIwMDAgKDI0
MDA2KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNDo0NyAyMDAwICgyNDAwNikga2NjLW5l
d3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAx
OjM0OjU0IDIwMDAgcG9zdCgyMzU1Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMzU1Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIz
NTU3KTogICAgICBtYWluKCkNCnBvc3QoMjM1NTcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4g
bWFpbg0KcG9zdCgyMzU1Nyk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVP
dXRFcnJvcjoNCnBvc3QoMjM1NTcpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUg
DQpKdW4gMDYgMDE6MzU6MTEgMjAwMCAoMjQwNDIpIGtjYy1uZXdzIGRiIGZp
bGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0L2hvbWUvbWFp
bG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0KSnVuIDA2IDAx
OjM1OjE0IDIwMDAgKDI0MDQyKSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29y
cnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzU6MjcgMjAwMCAoMjQwNTcp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjM1OjI5IDIwMDAgKDI0MDU3KSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzU6
NTkgMjAwMCBxcnVubmVyKDIzNTUyKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1
bm5lciBsb2NrDQpKdW4gMDYgMDE6MzY6MDUgMjAwMCAoMjQwODcpIGtjYy1u
ZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAvb3B0
L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFzdA0K
SnVuIDA2IDAxOjM2OjA1IDIwMDAgKDI0MDg3KSBrY2MtbmV3cyBmYWxsYmFj
ayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6MzY6MDcgMjAw
MCBxcnVubmVyKDIzMzQwKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBs
b2NrDQpKdW4gMDYgMDE6MzY6MTcgMjAwMCBxcnVubmVyKDIzMzM5KTogQ291
bGQgbm90IGFjcXVpcmUgcXJ1bm5lciBsb2NrDQpKdW4gMDYgMDE6MzY6MTcg
MjAwMCBxcnVubmVyKDIzMzYzKTogQ291bGQgbm90IGFjcXVpcmUgcXJ1bm5l
ciBsb2NrDQpKdW4gMDYgMDE6MzY6MjMgMjAwMCBhZG1pbigyNDA5Mik6IEBA
QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBADQph
ZG1pbigyNDA5Mik6IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDIuMGJldGEz
IC0tLS0tXQ0KYWRtaW4oMjQwOTIpOiBbLS0tLS0gVHJhY2ViYWNrIC0tLS0t
LV0NCmFkbWluKDI0MDkyKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQphZG1pbigyNDA5Mik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9kcml2ZXIiLCBsaW5lIDg5LCBpbiBydW5fbWFpbg0KSnVuIDA2IDAx
OjM2OjI5IDIwMDAgcXJ1bm5lcigyMzYxNSk6IENvdWxkIG5vdCBhY3F1aXJl
IHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjMwIDIwMDAgcXJ1bm5lcigy
MzQ1OSk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2
IDAxOjM2OjMzIDIwMDAgcXJ1bm5lcigyMzY5MCk6IENvdWxkIG5vdCBhY3F1
aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjM1IDIwMDAgcXJ1bm5l
cigyMzY1NCk6IENvdWxkIG5vdCBhY3F1aXJlIHFydW5uZXIgbG9jaw0KSnVu
IDA2IDAxOjM2OjQyIDIwMDAgcXJ1bm5lcigyMzc1Nik6IENvdWxkIG5vdCBh
Y3F1aXJlIHFydW5uZXIgbG9jaw0KSnVuIDA2IDAxOjM2OjUxIDIwMDAgKDI0
MTEzKSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNjo1MiAyMDAwIHBvc3QoMjM1NjEpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM1NjEpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyMzU2MSk6ICAgICAgbWFpbigpDQpwb3N0KDIz
NTYxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1NjEpOiAgICAgIGV4
Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTYxKTogTmFt
ZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM3OjAwIDIwMDAgKDI0
MTM2KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxs
YmFjazogL29wdC9ob21lL21haWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmln
LmRiLmxhc3QNCkp1biAwNiAwMTozNzowMSAyMDAwICgyNDEzNCkga2NjLW5l
d3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQv
aG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpK
dW4gMDYgMDE6Mzc6MDEgMjAwMCAoMjQxMzYpIGtjYy1uZXdzIGZhbGxiYWNr
IHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAwNiAwMTozNzowMCAyMDAw
IHBvc3QoMjM0MzcpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1
biAwNiAwMTozNzowMSAyMDAwICgyNDEzNCkga2NjLW5ld3MgZmFsbGJhY2sg
d2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KcG9zdCgyMzQzNyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIzNDM3KTogICAgICBtYWluKCkNCnBvc3QoMjM0Mzcp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzQzNyk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM0MzcpOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6Mzc6MzYgMjAwMCAoMjQxNzIp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjM3OjM4IDIwMDAgKDI0MTcyKSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6Mzc6
MzkgMjAwMCBwb3N0KDIzNjY4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDIzNjY4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM2Njgp
OiAgICAgIG1haW4oKQ0KcG9zdCgyMzY2OCk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDIzNjY4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyMzY2OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTozNzo0NSAyMDAwIHFydW5uZXIoMjM4OTYpOiBDb3VsZCBub3Qg
YWNxdWlyZSBxcnVubmVyIGxvY2sNCkp1biAwNiAwMTozNzo0OSAyMDAwIHBv
c3QoMjQxNzIpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBs
aXN0bmFtZToga2NjLW5ld3MNCmJhZCBtYXJzaGFsIGRhdGFKdW4gMDYgMDE6
Mzc6NDkgMjAwMCBwb3N0KDI0MTM2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6Mzc6
NTEgMjAwMCBwb3N0KDI0MTM0KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVy
IGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hhbCBkYXRh
SnVuIDA2IDAxOjM4OjAwIDIwMDAgcG9zdCgyNDA4Nyk6IE1haWxtYW4gZXJy
b3I6IG1haWxvd25lciBnb3QgYmFkIGxpc3RuYW1lOiBrY2MtbmV3cw0KSnVu
IDA2IDAxOjM4OjAxIDIwMDAgcG9zdCgyMzYzNyk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzYzNyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDIzNjM3KTogICAgICBtYWluKCkNCnBvc3QoMjM2MzcpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyMzYzNyk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCkp1biAwNiAwMTozODowMiAyMDAwIHBvc3QoMjQw
MDYpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290IGJhZCBsaXN0bmFt
ZToga2NjLW5ld3MNCnBvc3QoMjM2MzcpOiBOYW1lRXJyb3IgOiAgTG9ja0Zp
bGUgDQpKdW4gMDYgMDE6Mzg6MDIgMjAwMCBwb3N0KDIzOTM3KTogTWFpbG1h
biBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdz
DQpKdW4gMDYgMDE6Mzg6MDMgMjAwMCBwb3N0KDIzOTI2KTogTWFpbG1hbiBl
cnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpK
dW4gMDYgMDE6Mzg6MDMgMjAwMCBwb3N0KDIzOTM5KTogTWFpbG1hbiBlcnJv
cjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4g
MDYgMDE6Mzg6MDQgMjAwMCBwb3N0KDI0MDQyKTogTWFpbG1hbiBlcnJvcjog
bWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYg
MDE6Mzg6MDQgMjAwMCBwb3N0KDI0MDU3KTogTWFpbG1hbiBlcnJvcjogbWFp
bG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hh
bCBkYXRhYmFkIG1hcnNoYWwgZGF0YUp1biAwNiAwMTozODowOCAyMDAwIHBv
c3QoMjM1NjApOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCkp1biAw
NiAwMTozODowOCAyMDAwIHBvc3QoMjM3ODIpOiBNYWlsbWFuIGVycm9yOiBt
YWlsb3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAw
MTozODowOSAyMDAwIHBvc3QoMjM4NjApOiBNYWlsbWFuIGVycm9yOiBtYWls
b3duZXIgZ290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCnBvc3QoMjM1NjAp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KSnVuIDA2IDAxOjM4OjEwIDIwMDAgcG9zdCgy
Mzc3MCk6IE1haWxtYW4gZXJyb3I6IG1haWxvd25lciBnb3QgYmFkIGxpc3Ru
YW1lOiBrY2MtbmV3cw0KcG9zdCgyMzU2MCk6ICAgICAgbWFpbigpDQpwb3N0
KDIzNTYwKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21h
aWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM1NjApOiAgICAg
IGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNTYwKTog
TmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjM4OjA5IDIwMDAg
cG9zdCgyMzQ5NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyMzQ5NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzNDk1KTogICAgICBt
YWluKCkNCnBvc3QoMjM0OTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgy
MzQ5NSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBv
c3QoMjM0OTUpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6
Mzg6MTEgMjAwMCBwb3N0KDIzNzA5KTogTWFpbG1hbiBlcnJvcjogbWFpbG93
bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1uZXdzDQpiYWQgbWFyc2hhbCBk
YXRhSnVuIDA2IDAxOjM4OjE3IDIwMDAgcG9zdCgyMzY2Nik6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzY2Nik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDIzNjY2KTogICAgICBtYWluKCkNCnBvc3QoMjM2NjYpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzY2Nik6ICAgICAgZXhjZXB0IExv
Y2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM2NjYpOiBOYW1lRXJyb3Ig
OiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDA6MzMgMjAwMCBwb3N0KDIzODMy
KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzODMyKTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgODksIGluID8NCnBvc3QoMjM4MzIpOiAgICAgIG1haW4oKQ0KcG9z
dCgyMzgzMik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDIzODMyKTogICAg
ICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyMzgzMik6
IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0MToyNCAyMDAw
ICgyNDM1Nikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcg
ZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2Nv
bmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDE6MjQgMjAwMCAoMjQzNTQpIGtj
Yy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNrOiAv
b3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIubGFz
dA0KSnVuIDA2IDAxOjQxOjI0IDIwMDAgKDI0MzYxKSBrY2MtbmV3cyBkYiBm
aWxlIHdhcyBjb3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21h
aWxtYW4vbGlzdHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAw
MTo0MToyNCAyMDAwICgyNDM0Nykga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29y
cnVwdCwgdXNpbmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3Rz
L2tjYy1uZXdzL2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDE6MjUgMjAw
MCAoMjQzNDcpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZp
bmcgdXANCkp1biAwNiAwMTo0MToyNSAyMDAwICgyNDM2MSkga2NjLW5ld3Mg
ZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2IDAxOjQx
OjI1IDIwMDAgKDI0MzU2KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMgY29ycnVw
dCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDE6MjUgMjAwMCAoMjQzNTQpIGtj
Yy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0LCBnaXZpbmcgdXANCkp1biAw
NiAwMTo0MTo0MCAyMDAwIHBvc3QoMjM1MTUpOiBUcmFjZWJhY2sgKGlubmVy
bW9zdCBsYXN0KToNCnBvc3QoMjM1MTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9z
dCgyMzUxNSk6ICAgICAgbWFpbigpDQpwb3N0KDIzNTE1KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEs
IGluIG1haW4NCnBvc3QoMjM1MTUpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5U
aW1lT3V0RXJyb3I6DQpwb3N0KDIzNTE1KTogTmFtZUVycm9yIDogIExvY2tG
aWxlIA0KSnVuIDA2IDAxOjQxOjQxIDIwMDAgcG9zdCgyMzQ4MCk6IFRyYWNl
YmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzQ4MCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5
LCBpbiA/DQpwb3N0KDIzNDgwKTogICAgICBtYWluKCkNCnBvc3QoMjM0ODAp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyMzQ4MCk6ICAgICAgZXhjZXB0
IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjM0ODApOiBOYW1lRXJy
b3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDE6NTAgMjAwMCBwb3N0KDI0
MjQ3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0MjQ3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQyNDcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyNDI0Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0MjQ3KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjQyNDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyNDI0Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDI0MjQ3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjQyNDcpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0
MjQ3KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo0MjowMSAyMDAwIHBvc3QoMjM2NzEpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjM2NzEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyMzY3MSk6ICAgICAgbWFpbigpDQpwb3N0KDIzNjcxKTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjM2NzEpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNjcxKTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQyOjIxIDIwMDAgcG9zdCgyNDI1Mik6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDI1Mik6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDI0MjUyKTogICAgICBtYWluKCkNCnBvc3QoMjQy
NTIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2OCwgaW4gbWFpbg0KcG9zdCgyNDI1Mik6ICAgICAgaWYg
Qm91bmNlckFQSS5TY2FuTWVzc2FnZXMobWxpc3QsIG1zZyk6DQpwb3N0KDI0
MjUyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0JvdW5j
ZXJzL0JvdW5jZXJBUEkucHkiLCBsaW5lIDUwLCBpbiBTY2FuTWVzc2FnZXMN
CnBvc3QoMjQyNTIpOiAgICAgIGFkZHJzID0gZnVuYyhtc2cpDQpwb3N0KDI0
MjUyKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0JvdW5j
ZXJzL0RTTi5weSIsIGxpbmUgNjAsIGluIHByb2Nlc3MNCnBvc3QoMjQyNTIp
OiAgICAgIHMgPSBTdHJpbmdJTyhtZmlsZS5yZWFkKCkpDQpwb3N0KDI0MjUy
KTogICBGaWxlICIvdXNyL2xvY2FsL2xpYi9weXRob24xLjUvbXVsdGlmaWxl
LnB5IiwgbGluZSAxMTgsIGluIHJlYWQNCnBvc3QoMjQyNTIpOiAgICAgIHJl
dHVybiBzdHJpbmcuam9pbmZpZWxkcyhzZWxmLnJlYWRsaW5lcygpLCAnJykN
CnBvc3QoMjQyNTIpOiAgIEZpbGUgIi91c3IvbG9jYWwvbGliL3B5dGhvbjEu
NS9tdWx0aWZpbGUucHkiLCBsaW5lIDExNCwgaW4gcmVhZGxpbmVzDQpwb3N0
KDI0MjUyKTogICAgICBsaXN0LmFwcGVuZChsaW5lKQ0KcG9zdCgyNDI1Mik6
IE1lbW9yeUVycm9yICANCkp1biAwNiAwMTo0Mjo0NyAyMDAwIHBvc3QoMjM0
MjkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjM0Mjkp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVy
IiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQyOSk6ICAgICAgbWFpbigpDQpw
b3N0KDIzNDI5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0MjkpOiAg
ICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDI5
KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQyOjQ5IDIw
MDAgcG9zdCgyMzk3MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyMzk3MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIzOTcxKTogICAg
ICBtYWluKCkNCnBvc3QoMjM5NzEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyMzk3MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjM5NzEpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6NDI6NTIgMjAwMCBwb3N0KDIzNDQxKTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDIzNDQxKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjM0NDEpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzQ0MSk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDIzNDQxKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KSnVuIDA2IDAxOjQyOjUzIDIwMDAgcG9zdCgyMzQ0Nik6
IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyMzQ0MSk6IE5h
bWVFcnJvciA6ICBMb2NrRmlsZSANCnBvc3QoMjM0NDYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyMzQ0Nik6ICAgICAgbWFpbigpDQpwb3N0KDIzNDQ2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjM0NDYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDIzNDQ2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQ0OjU5IDIwMDAgcG9zdCgyNDQ2
MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDQ2MSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NDYxKTogICAgICBtYWluKCkNCnBv
c3QoMjQ0NjEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgyNDQ2MSk6ICAg
ICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0NDYxKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGlu
IFNhdmUNCnBvc3QoMjQ0NjEpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2go
KQ0KcG9zdCgyNDQ2MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0
KDI0NDYxKTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyNDQ2
MSk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4g
MDYgMDE6NDU6MjIgMjAwMCBwb3N0KDI0MTEzKTogVHJhY2ViYWNrIChpbm5l
cm1vc3QgbGFzdCk6DQpwb3N0KDI0MTEzKTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBv
c3QoMjQxMTMpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDExMyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgz
LCBpbiBtYWluDQpwb3N0KDI0MTEzKTogICAgICBtbGlzdC5TYXZlKCkNCnBv
c3QoMjQxMTMpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyNDExMyk6
ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDI0MTEzKTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5Iiwg
bGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQxMTMpOiAgICAgIHJhaXNl
IE5vdExvY2tlZEVycm9yDQpwb3N0KDI0MTEzKTogTWFpbG1hbi5Mb2NrRmls
ZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo0NTo0NSAyMDAwICgy
NDUxNikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNpbmcgZmFs
bGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdzL2NvbmZp
Zy5kYi5sYXN0DQpKdW4gMDYgMDE6NDU6NDUgMjAwMCBhZG1pbigyNDUxNyk6
IEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA
DQphZG1pbigyNDUxNyk6IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDIuMGJl
dGEzIC0tLS0tXQ0KYWRtaW4oMjQ1MTcpOiBbLS0tLS0gVHJhY2ViYWNrIC0t
LS0tLV0NCmFkbWluKDI0NTE3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQphZG1pbigyNDUxNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4v
c2NyaXB0cy9kcml2ZXIiLCBsaW5lIDg5LCBpbiBydW5fbWFpbg0KSnVuIDA2
IDAxOjQ1OjQ1IDIwMDAgKDI0NTA1KSBrY2MtbmV3cyBkYiBmaWxlIHdhcyBj
b3JydXB0LCB1c2luZyBmYWxsYmFjazogL29wdC9ob21lL21haWxtYW4vbGlz
dHMva2NjLW5ld3MvY29uZmlnLmRiLmxhc3QNCkp1biAwNiAwMTo0NTo0NSAy
MDAwICgyNDUxMikga2NjLW5ld3MgZGIgZmlsZSB3YXMgY29ycnVwdCwgdXNp
bmcgZmFsbGJhY2s6IC9vcHQvaG9tZS9tYWlsbWFuL2xpc3RzL2tjYy1uZXdz
L2NvbmZpZy5kYi5sYXN0DQpKdW4gMDYgMDE6NDU6NDYgMjAwMCAoMjQ1MDcp
IGtjYy1uZXdzIGRiIGZpbGUgd2FzIGNvcnJ1cHQsIHVzaW5nIGZhbGxiYWNr
OiAvb3B0L2hvbWUvbWFpbG1hbi9saXN0cy9rY2MtbmV3cy9jb25maWcuZGIu
bGFzdA0KSnVuIDA2IDAxOjQ1OjQ3IDIwMDAgKDI0NTA1KSBrY2MtbmV3cyBm
YWxsYmFjayB3YXMgY29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDU6
NDcgMjAwMCAoMjQ1MTIpIGtjYy1uZXdzIGZhbGxiYWNrIHdhcyBjb3JydXB0
LCBnaXZpbmcgdXANCkp1biAwNiAwMTo0NTo0NyAyMDAwICgyNDUwNykga2Nj
LW5ld3MgZmFsbGJhY2sgd2FzIGNvcnJ1cHQsIGdpdmluZyB1cA0KSnVuIDA2
IDAxOjQ1OjQ5IDIwMDAgKDI0NTE2KSBrY2MtbmV3cyBmYWxsYmFjayB3YXMg
Y29ycnVwdCwgZ2l2aW5nIHVwDQpKdW4gMDYgMDE6NDU6NTkgMjAwMCBwb3N0
KDI0MTY0KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0
MTY0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQxNjQpOiAgICAgIG1haW4o
KQ0KcG9zdCgyNDE2NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0MTY0
KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgy
NDE2NCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0Njow
OCAyMDAwIHBvc3QoMjQ1MDUpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIg
Z290IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAwMTo0NjoxOCAy
MDAwIHBvc3QoMjQzNTQpOiBNYWlsbWFuIGVycm9yOiBtYWlsb3duZXIgZ290
IGJhZCBsaXN0bmFtZToga2NjLW5ld3MNCkp1biAwNiAwMTo0NjoyNCAyMDAw
IHBvc3QoMjM0MjUpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBv
c3QoMjM0MjUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQyNSk6ICAgICAg
bWFpbigpDQpwb3N0KDIzNDI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1h
bi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3Qo
MjM0MjUpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpw
b3N0KDIzNDI1KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAx
OjQ2OjMzIDIwMDAgcG9zdCgyMzQ0Myk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyMzQ0Myk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDIz
NDQzKTogICAgICBtYWluKCkNCnBvc3QoMjM0NDMpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4g
bWFpbg0KcG9zdCgyMzQ0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVP
dXRFcnJvcjoNCnBvc3QoMjM0NDMpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUg
DQpKdW4gMDYgMDE6NDY6MzcgMjAwMCBwb3N0KDIzOTk3KTogVHJhY2ViYWNr
IChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzOTk3KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGlu
ID8NCnBvc3QoMjM5OTcpOiAgICAgIG1haW4oKQ0KcG9zdCgyMzk5Nyk6ICAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBs
aW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzOTk3KTogICAgICBtbGlzdC5TYXZl
KCkNCnBvc3QoMjM5OTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01h
aWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgy
Mzk5Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzOTk3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxl
LnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjM5OTcpOiAgICAg
IHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIzOTk3KTogTWFpbG1hbi5M
b2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo0Njo0MiAy
MDAwIHBvc3QoMjM0NDkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToN
CnBvc3QoMjM0NDkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyMzQ0OSk6ICAg
ICAgbWFpbigpDQpwb3N0KDIzNDQ5KTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjM0NDkpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDIzNDQ5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2
IDAxOjQ2OjQ2IDIwMDAgcG9zdCgyNDM0Nyk6IE1haWxtYW4gZXJyb3I6IG1h
aWxvd25lciBnb3QgYmFkIGxpc3RuYW1lOiBrY2MtbmV3cw0KSnVuIDA2IDAx
OjQ2OjQ3IDIwMDAgcG9zdCgyNDMwNyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyNDMwNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0
MzA3KTogICAgICBtYWluKCkNCnBvc3QoMjQzMDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyNDMwNyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0
MzA3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQzMDcpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDMwNyk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0MzA3KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyNDMwNyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NDY6NTUgMjAwMCBwb3N0KDIz
OTQ3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDIzOTQ3
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM5NDcpOiAgICAgIG1haW4oKQ0K
cG9zdCgyMzk0Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDIzOTQ3KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjM5NDcpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyMzk0Nyk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDIzOTQ3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjM5NDcpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDIz
OTQ3KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo0Njo1NiAyMDAwIHBvc3QoMjQyMjEpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQyMjEpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDIyMSk6ICAgICAgbWFpbigpDQpwb3N0KDI0MjIxKTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjQyMjEpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjIxKTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQ3OjI0IDIwMDAgcG9zdCgyNDI0NCk6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDI0NCk6ICAgRmls
ZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5l
IDg5LCBpbiA/DQpwb3N0KDI0MjQ0KTogICAgICBtYWluKCkNCnBvc3QoMjQy
NDQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDI0NCk6ICAgICAgZXhj
ZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQyNDQpOiBOYW1l
RXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDc6MzQgMjAwMCBwb3N0
KDI0NTE2KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlz
dG5hbWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6MzUgMjAwMCBwb3N0KDI0
NTA3KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5h
bWU6IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6MzYgMjAwMCBwb3N0KDI0NTEy
KTogTWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6
IGtjYy1uZXdzDQpKdW4gMDYgMDE6NDc6NDAgMjAwMCBwb3N0KDI0MzYxKTog
TWFpbG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtj
Yy1uZXdzDQpKdW4gMDYgMDE6NDc6NDEgMjAwMCBwb3N0KDI0MzU2KTogTWFp
bG1hbiBlcnJvcjogbWFpbG93bmVyIGdvdCBiYWQgbGlzdG5hbWU6IGtjYy1u
ZXdzDQpiYWQgbWFyc2hhbCBkYXRhSnVuIDA2IDAxOjQ3OjQ2IDIwMDAgcG9z
dCgyNDIxNyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgy
NDIxNyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0MjE3KTogICAgICBtYWlu
KCkNCnBvc3QoMjQyMTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDIx
Nyk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3Qo
MjQyMTcpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NDc6
NDggMjAwMCBwb3N0KDI0MjA3KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFz
dCk6DQpwb3N0KDI0MjA3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQyMDcp
OiAgICAgIG1haW4oKQ0KcG9zdCgyNDIwNyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDI0MjA3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyNDIwNyk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1
biAwNiAwMTo0Nzo0OSAyMDAwIHBvc3QoMjQyMjQpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQyMjQpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDIyNCk6ICAgICAgbWFpbigpDQpwb3N0KDI0MjI0KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
NjEsIGluIG1haW4NCnBvc3QoMjQyMjQpOiAgICAgIGV4Y2VwdCBMb2NrRmls
ZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjI0KTogTmFtZUVycm9yIDogIExv
Y2tGaWxlIA0KSnVuIDA2IDAxOjQ4OjAzIDIwMDAgcG9zdCgyNDI4MSk6IFRy
YWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KSnVuIDA2IDAxOjQ4OjAzIDIw
MDAgcG9zdCgyNDI3Mik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyNDI4MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0MjgxKTogICAg
ICBtYWluKCkNCnBvc3QoMjQyODEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyNDI4MSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjQyNzIpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Njcmlw
dHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDI3Mik6ICAg
ICAgbWFpbigpDQpwb3N0KDI0MjcyKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBv
c3QoMjQyNzIpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6
DQpwb3N0KDI0MjcyKTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KcG9zdCgy
NDI4MSk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0ODow
NyAyMDAwIHBvc3QoMjQyNzQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0
KToNCnBvc3QoMjQyNzQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDI3NCk6
ICAgICAgbWFpbigpDQpwb3N0KDI0Mjc0KTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4N
CnBvc3QoMjQyNzQpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJy
b3I6DQpwb3N0KDI0Mjc0KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjQ4OjMxIDIwMDAgcG9zdCgyNDMwMyk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDMwMyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDI0MzAzKTogICAgICBtYWluKCkNCnBvc3QoMjQzMDMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyNDMwMyk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQzMDMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6NDg6MzkgMjAwMCBwb3N0KDI0MzA5KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0MzA5KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjQzMDkpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDMw
OSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0MzA5KTogICAgICBleGNl
cHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyNDMwOSk6IE5hbWVF
cnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo0OTozNCAyMDAwIHBvc3Qo
MjQyMzQpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQy
MzQpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDIzNCk6ICAgICAgbWFpbigp
DQpwb3N0KDI0MjM0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQyMzQp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0
MjM0KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjQ5OjQy
IDIwMDAgcG9zdCgyNDIzNik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KSnVuIDA2IDAxOjQ5OjQyIDIwMDAgcG9zdCgyNDE5Nyk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDIzNik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDI0MTk3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9z
Y3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQxOTcp
OiAgICAgIG1haW4oKQ0KcG9zdCgyNDE5Nyk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWlu
DQpwb3N0KDI0MTk3KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVy
cm9yOg0KcG9zdCgyNDIzNik6ICAgICAgbWFpbigpDQpwb3N0KDI0MjM2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQyMzYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0MjM2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KcG9zdCgyNDE5Nyk6IE5hbWVFcnJvciA6ICBMb2Nr
RmlsZSANCkp1biAwNiAwMTo1MDoxNiAyMDAwICgyNDQyOSkgRGVsaXZlcnkg
ZXhjZXB0aW9uOiANCkp1biAwNiAwMTo1MDoyMSAyMDAwICgyNDQyOSkgVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vSGFuZGxlcnMvSGFuZGxlckFQSS5weSIsIGxpbmUg
NzQsIGluIERlbGl2ZXJUb0xpc3QNCiAgICBmdW5jKG1saXN0LCBtc2csIG1z
Z2RhdGEpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vSGFu
ZGxlcnMvU01UUERpcmVjdC5weSIsIGxpbmUgNjgsIGluIHByb2Nlc3MNCiAg
ICBtbGlzdC5TYXZlKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQogICAgc2Vs
Zi5fX2xvY2sucmVmcmVzaCgpDQogIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0K
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpOb3RMb2NrZWRFcnJvcjogDQoN
Ckp1biAwNiAwMTo1MDoyMyAyMDAwIHBvc3QoMjQ0MjkpOiBUcmFjZWJhY2sg
KGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ0MjkpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4g
Pw0KcG9zdCgyNDQyOSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NDI5KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODMsIGluIG1haW4NCnBvc3QoMjQ0MjkpOiAgICAgIG1saXN0LlNhdmUo
KQ0KcG9zdCgyNDQyOSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDI0
NDI5KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjQ0Mjkp
OiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUu
cHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDQyOSk6ICAgICAg
cmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ0MjkpOiBNYWlsbWFuLkxv
Y2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjUwOjUxIDIw
MDAgcG9zdCgyNDM4NSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0K
cG9zdCgyNDM4NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0Mzg1KTogICAg
ICBtYWluKCkNCnBvc3QoMjQzODUpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9z
dCgyNDM4NSk6ICAgICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoN
CnBvc3QoMjQzODUpOiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYg
MDE6NTE6MTAgMjAwMCBwb3N0KDI0NDEyKTogVHJhY2ViYWNrIChpbm5lcm1v
c3QgbGFzdCk6DQpwb3N0KDI0NDEyKTogICBGaWxlICIvb3B0L2hvbWUvbWFp
bG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3Qo
MjQ0MTIpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDQxMik6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBp
biBtYWluDQpwb3N0KDI0NDEyKTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGlt
ZU91dEVycm9yOg0KcG9zdCgyNDQxMik6IE5hbWVFcnJvciA6ICBMb2NrRmls
ZSANCkp1biAwNiAwMTo1MTo0NSAyMDAwIHBvc3QoMjQ0MjYpOiBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ0MjYpOiAgIEZpbGUgIi9v
cHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwg
aW4gPw0KcG9zdCgyNDQyNik6ICAgICAgbWFpbigpDQpwb3N0KDI0NDI2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIs
IGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQ0MjYpOiAgICAgIGV4Y2VwdCBM
b2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0NDI2KTogTmFtZUVycm9y
IDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjUxOjU0IDIwMDAgcG9zdCgyNDQy
MSk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDQyMSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NDIxKTogICAgICBtYWluKCkNCnBv
c3QoMjQ0MjEpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMv
bWFpbG93bmVyIiwgbGluZSA2MSwgaW4gbWFpbg0KcG9zdCgyNDQyMSk6ICAg
ICAgZXhjZXB0IExvY2tGaWxlLlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQ0MjEp
OiBOYW1lRXJyb3IgOiAgTG9ja0ZpbGUgDQpKdW4gMDYgMDE6NTI6MzkgMjAw
MCBwb3N0KDI0NDQ4KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpw
b3N0KDI0NDQ4KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRz
L21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQ0NDgpOiAgICAg
IG1haW4oKQ0KcG9zdCgyNDQ0OCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0
KDI0NDQ4KTogICAgICBleGNlcHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0K
cG9zdCgyNDQ0OCk6IE5hbWVFcnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAw
MTo1Mjo0MCAyMDAwIHBvc3QoMjQ0NTgpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjQ0NTgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
NDQ1OCk6ICAgICAgbWFpbigpDQpwb3N0KDI0NDU4KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjQ0NTgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDI0NDU4KTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjUzOjMzIDIwMDAgcG9zdCgyNDc1MSk6IFRyYWNlYmFj
ayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDc1MSk6ICAgRmlsZSAiL29w
dC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBp
biA/DQpwb3N0KDI0NzUxKTogICAgICBtYWluKCkNCnBvc3QoMjQ3NTEpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwg
bGluZSA4MywgaW4gbWFpbg0KcG9zdCgyNDc1MSk6ICAgICAgbWxpc3QuU2F2
ZSgpDQpwb3N0KDI0NzUxKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3Qo
MjQ3NTEpOiAgICAgIHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDc1
MSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmls
ZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0NzUxKTogICAg
ICByYWlzZSBOb3RMb2NrZWRFcnJvcg0KcG9zdCgyNDc1MSk6IE1haWxtYW4u
TG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NTM6MzUg
MjAwMCBwb3N0KDIzNTAzKTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6
DQpwb3N0KDIzNTAzKTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgODksIGluID8NCnBvc3QoMjM1MDMpOiAg
ICAgIG1haW4oKQ0KcG9zdCgyMzUwMyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpw
b3N0KDIzNTAzKTogICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjM1MDMpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHki
LCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9zdCgyMzUwMyk6ICAgICAgc2VsZi5f
X2xvY2sucmVmcmVzaCgpDQpwb3N0KDIzNTAzKTogICBGaWxlICIvb3B0L2hv
bWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGlu
IHJlZnJlc2gNCnBvc3QoMjM1MDMpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVy
cm9yDQpwb3N0KDIzNTAzKTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tl
ZEVycm9yICANCkp1biAwNiAwMTo1NDowOCAyMDAwIHBvc3QoMjQ1OTcpOiBU
cmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1OTcpOiAgIEZp
bGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGlu
ZSA4OSwgaW4gPw0KcG9zdCgyNDU5Nyk6ICAgICAgbWFpbigpDQpwb3N0KDI0
NTk3KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxv
d25lciIsIGxpbmUgODMsIGluIG1haW4NCnBvc3QoMjQ1OTcpOiAgICAgIG1s
aXN0LlNhdmUoKQ0KcG9zdCgyNDU5Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZl
DQpwb3N0KDI0NTk3KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBv
c3QoMjQ1OTcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4v
TG9ja0ZpbGUucHkiLCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDU5
Nyk6ICAgICAgcmFpc2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ1OTcpOiBN
YWlsbWFuLkxvY2tGaWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAx
OjU0OjM3IDIwMDAgcG9zdCgyNDY1NCk6IFRyYWNlYmFjayAoaW5uZXJtb3N0
IGxhc3QpOg0KcG9zdCgyNDY1NCk6ICAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0
NjU0KTogICAgICBtYWluKCkNCnBvc3QoMjQ2NTQpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4g
bWFpbg0KcG9zdCgyNDY1NCk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0
NjU0KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ2NTQpOiAgICAg
IHNlbGYuX19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDY1NCk6ICAgRmlsZSAi
L29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUg
MjA0LCBpbiByZWZyZXNoDQpwb3N0KDI0NjU0KTogICAgICByYWlzZSBOb3RM
b2NrZWRFcnJvcg0KcG9zdCgyNDY1NCk6IE1haWxtYW4uTG9ja0ZpbGUgLiBO
b3RMb2NrZWRFcnJvciAgDQpKdW4gMDYgMDE6NTQ6NTIgMjAwMCBwb3N0KDI0
NzI1KTogVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NzI1
KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25l
ciIsIGxpbmUgODksIGluID8NCnBvc3QoMjQ3MjUpOiAgICAgIG1haW4oKQ0K
cG9zdCgyNDcyNSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0
cy9tYWlsb3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0NzI1KTog
ICAgICBtbGlzdC5TYXZlKCkNCnBvc3QoMjQ3MjUpOiAgIEZpbGUgIi9vcHQv
aG9tZS9tYWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwg
aW4gU2F2ZQ0KcG9zdCgyNDcyNSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVz
aCgpDQpwb3N0KDI0NzI1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9N
YWlsbWFuL0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBv
c3QoMjQ3MjUpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0
NzI1KTogTWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1
biAwNiAwMTo1NToxMCAyMDAwIHBvc3QoMjQ1NTUpOiBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1NTUpOiAgIEZpbGUgIi9vcHQvaG9t
ZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0K
cG9zdCgyNDU1NSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NTU1KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODMsIGluIG1haW4NCnBvc3QoMjQ1NTUpOiAgICAgIG1saXN0LlNhdmUoKQ0K
cG9zdCgyNDU1NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1h
bi9NYWlsTGlzdC5weSIsIGxpbmUgODYwLCBpbiBTYXZlDQpwb3N0KDI0NTU1
KTogICAgICBzZWxmLl9fbG9jay5yZWZyZXNoKCkNCnBvc3QoMjQ1NTUpOiAg
IEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL01haWxtYW4vTG9ja0ZpbGUucHki
LCBsaW5lIDIwNCwgaW4gcmVmcmVzaA0KcG9zdCgyNDU1NSk6ICAgICAgcmFp
c2UgTm90TG9ja2VkRXJyb3INCnBvc3QoMjQ1NTUpOiBNYWlsbWFuLkxvY2tG
aWxlIC4gTm90TG9ja2VkRXJyb3IgIA0KSnVuIDA2IDAxOjU1OjEwIDIwMDAg
cG9zdCgyNDU2Nyk6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3QpOg0KcG9z
dCgyNDU2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9t
YWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0NTY3KTogICAgICBt
YWluKCkNCnBvc3QoMjQ1NjcpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0KcG9zdCgy
NDU2Nyk6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0NTY3KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5IiwgbGlu
ZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ1NjcpOiAgICAgIHNlbGYuX19sb2Nr
LnJlZnJlc2goKQ0KcG9zdCgyNDU2Nyk6ICAgRmlsZSAiL29wdC9ob21lL21h
aWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZy
ZXNoDQpwb3N0KDI0NTY3KTogICAgICByYWlzZSBOb3RMb2NrZWRFcnJvcg0K
cG9zdCgyNDU2Nyk6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2NrZWRFcnJv
ciAgDQpKdW4gMDYgMDE6NTU6MTcgMjAwMCBwb3N0KDI0NTc5KTogVHJhY2Vi
YWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NTc5KTogICBGaWxlICIv
b3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgODks
IGluID8NCnBvc3QoMjQ1NzkpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDU3OSk6
ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIi
LCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0NTc5KTogICAgICBtbGlzdC5T
YXZlKCkNCnBvc3QoMjQ1NzkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFu
L01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2ZQ0KcG9z
dCgyNDU3OSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpwb3N0KDI0
NTc5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0xvY2tG
aWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQ1NzkpOiAg
ICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0NTc5KTogTWFpbG1h
bi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAwMTo1NToz
MiAyMDAwIHBvc3QoMjQ1NDgpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0
KToNCnBvc3QoMjQ1NDgpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3Nj
cmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDU0OCk6
ICAgICAgbWFpbigpDQpwb3N0KDI0NTQ4KTogICBGaWxlICIvb3B0L2hvbWUv
bWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4N
CnBvc3QoMjQ1NDgpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJy
b3I6DQpwb3N0KDI0NTQ4KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVu
IDA2IDAxOjU1OjMzIDIwMDAgcG9zdCgyNDU0Myk6IFRyYWNlYmFjayAoaW5u
ZXJtb3N0IGxhc3QpOg0KcG9zdCgyNDU0Myk6ICAgRmlsZSAiL29wdC9ob21l
L21haWxtYW4vc2NyaXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpw
b3N0KDI0NTQzKTogICAgICBtYWluKCkNCnBvc3QoMjQ1NDMpOiAgIEZpbGUg
Ii9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA2
MSwgaW4gbWFpbg0KcG9zdCgyNDU0Myk6ICAgICAgZXhjZXB0IExvY2tGaWxl
LlRpbWVPdXRFcnJvcjoNCnBvc3QoMjQ1NDMpOiBOYW1lRXJyb3IgOiAgTG9j
a0ZpbGUgDQpKdW4gMDYgMDE6NTY6MDcgMjAwMCBwb3N0KDI0NTg2KTogVHJh
Y2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0NTg2KTogICBGaWxl
ICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUg
ODksIGluID8NCnBvc3QoMjQ1ODYpOiAgICAgIG1haW4oKQ0KcG9zdCgyNDU4
Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWlsb3du
ZXIiLCBsaW5lIDYxLCBpbiBtYWluDQpwb3N0KDI0NTg2KTogICAgICBleGNl
cHQgTG9ja0ZpbGUuVGltZU91dEVycm9yOg0KcG9zdCgyNDU4Nik6IE5hbWVF
cnJvciA6ICBMb2NrRmlsZSANCkp1biAwNiAwMTo1NjoxNyAyMDAwIHBvc3Qo
MjQ1OTkpOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCnBvc3QoMjQ1
OTkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWlsbWFuL3NjcmlwdHMvbWFpbG93
bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgyNDU5OSk6ICAgICAgbWFpbigp
DQpwb3N0KDI0NTk5KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3Jp
cHRzL21haWxvd25lciIsIGxpbmUgNjEsIGluIG1haW4NCnBvc3QoMjQ1OTkp
OiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1lT3V0RXJyb3I6DQpwb3N0KDI0
NTk5KTogTmFtZUVycm9yIDogIExvY2tGaWxlIA0KSnVuIDA2IDAxOjU2OjMx
IDIwMDAgcG9zdCgyNDg2Nik6IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp
Og0KcG9zdCgyNDg2Nik6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2Ny
aXB0cy9tYWlsb3duZXIiLCBsaW5lIDg5LCBpbiA/DQpwb3N0KDI0ODY2KTog
ICAgICBtYWluKCkNCnBvc3QoMjQ4NjYpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4MywgaW4gbWFpbg0K
cG9zdCgyNDg2Nik6ICAgICAgbWxpc3QuU2F2ZSgpDQpwb3N0KDI0ODY2KTog
ICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5
IiwgbGluZSA4NjAsIGluIFNhdmUNCnBvc3QoMjQ4NjYpOiAgICAgIHNlbGYu
X19sb2NrLnJlZnJlc2goKQ0KcG9zdCgyNDg2Nik6ICAgRmlsZSAiL29wdC9o
b21lL21haWxtYW4vTWFpbG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBp
biByZWZyZXNoDQpwb3N0KDI0ODY2KTogICAgICByYWlzZSBOb3RMb2NrZWRF
cnJvcg0KcG9zdCgyNDg2Nik6IE1haWxtYW4uTG9ja0ZpbGUgLiBOb3RMb2Nr
ZWRFcnJvciAgDQpKdW4gMDYgMDE6NTY6MzUgMjAwMCBwb3N0KDI0Njk1KTog
VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQpwb3N0KDI0Njk1KTogICBG
aWxlICIvb3B0L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxp
bmUgODksIGluID8NCnBvc3QoMjQ2OTUpOiAgICAgIG1haW4oKQ0KcG9zdCgy
NDY5NSk6ICAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vc2NyaXB0cy9tYWls
b3duZXIiLCBsaW5lIDgzLCBpbiBtYWluDQpwb3N0KDI0Njk1KTogICAgICBt
bGlzdC5TYXZlKCkNCnBvc3QoMjQ2OTUpOiAgIEZpbGUgIi9vcHQvaG9tZS9t
YWlsbWFuL01haWxtYW4vTWFpbExpc3QucHkiLCBsaW5lIDg2MCwgaW4gU2F2
ZQ0KcG9zdCgyNDY5NSk6ICAgICAgc2VsZi5fX2xvY2sucmVmcmVzaCgpDQpw
b3N0KDI0Njk1KTogICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFu
L0xvY2tGaWxlLnB5IiwgbGluZSAyMDQsIGluIHJlZnJlc2gNCnBvc3QoMjQ2
OTUpOiAgICAgIHJhaXNlIE5vdExvY2tlZEVycm9yDQpwb3N0KDI0Njk1KTog
TWFpbG1hbi5Mb2NrRmlsZSAuIE5vdExvY2tlZEVycm9yICANCkp1biAwNiAw
MTo1Njo0MCAyMDAwIHBvc3QoMjQ2MjkpOiBUcmFjZWJhY2sgKGlubmVybW9z
dCBsYXN0KToNCnBvc3QoMjQ2MjkpOiAgIEZpbGUgIi9vcHQvaG9tZS9tYWls
bWFuL3NjcmlwdHMvbWFpbG93bmVyIiwgbGluZSA4OSwgaW4gPw0KcG9zdCgy
NDYyOSk6ICAgICAgbWFpbigpDQpwb3N0KDI0NjI5KTogICBGaWxlICIvb3B0
L2hvbWUvbWFpbG1hbi9zY3JpcHRzL21haWxvd25lciIsIGxpbmUgNjEsIGlu
IG1haW4NCnBvc3QoMjQ2MjkpOiAgICAgIGV4Y2VwdCBMb2NrRmlsZS5UaW1l
T3V0RXJyb3I6DQpwb3N0KDI0NjI5KTogTmFtZUVycm9yIDogIExvY2tGaWxl
IA0KSnVuIDA2IDAxOjU3OjA3IDIwMDAgKDI0NjEyKSBEZWxpdmVyeSBleGNl
cHRpb246IA0KSnVuIDA2IDAxOjU3OjA3IDIwMDAgKDI0NjEyKSBUcmFjZWJh
Y2sgKGlubmVybW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxt
YW4vTWFpbG1hbi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwg
aW4gRGVsaXZlclRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0
YSkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVy
cy9TTVRQRGlyZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1s
aXN0LlNhdmUoKQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFu
L01haWxMaXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9f
bG9jay5yZWZyZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9Mb2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAg
cmFpc2UgTm90TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg0KSnVu
IDA2IDAxOjU3OjE1IDIwMDAgKDI0NzExKSBEZWxpdmVyeSBleGNlcHRpb246
IA0KSnVuIDA2IDAxOjU3OjE1IDIwMDAgKDI0NzExKSBUcmFjZWJhY2sgKGlu
bmVybW9zdCBsYXN0KToNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFp
bG1hbi9IYW5kbGVycy9IYW5kbGVyQVBJLnB5IiwgbGluZSA3NCwgaW4gRGVs
aXZlclRvTGlzdA0KICAgIGZ1bmMobWxpc3QsIG1zZywgbXNnZGF0YSkNCiAg
RmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9IYW5kbGVycy9TTVRQ
RGlyZWN0LnB5IiwgbGluZSA2OCwgaW4gcHJvY2Vzcw0KICAgIG1saXN0LlNh
dmUoKQ0KICBGaWxlICIvb3B0L2hvbWUvbWFpbG1hbi9NYWlsbWFuL01haWxM
aXN0LnB5IiwgbGluZSA4NjAsIGluIFNhdmUNCiAgICBzZWxmLl9fbG9jay5y
ZWZyZXNoKCkNCiAgRmlsZSAiL29wdC9ob21lL21haWxtYW4vTWFpbG1hbi9M
b2NrRmlsZS5weSIsIGxpbmUgMjA0LCBpbiByZWZyZXNoDQogICAgcmFpc2Ug
Tm90TG9ja2VkRXJyb3INCk5vdExvY2tlZEVycm9yOiANCg==
---559023410-959030623-960272479=:25061--


From bwarsaw@python.org  Thu Jun  8 04:45:36 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 7 Jun 2000 23:45:36 -0400 (EDT)
Subject: [Mailman-Developers] multifile.Error :  sudden EOF in MultiFile.readline()
References: <Pine.GSO.4.21.0006071244180.25061-100000@alb-net.com>
Message-ID: <14655.5856.797357.860746@anthem.concentric.net>

In situations like this, it would be nice to have the original
message, because it's probably incomplete or otherwise misformated.
But in any case, please try this patch.

-Barry

Index: Postfix.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Postfix.py,v
retrieving revision 1.6
diff -c -r1.6 Postfix.py
*** Postfix.py	2000/06/05 15:54:47	1.6
--- Postfix.py	2000/06/08 03:41:18
***************
*** 43,49 ****
          if not more:
              # we didn't find it
              return None
!         s = StringIO(mfile.read())
          msg2 = mimetools.Message(s)
          if msg2.gettype() == 'text/plain':
              desc = msg2.get('content-description')
--- 43,53 ----
          if not more:
              # we didn't find it
              return None
!         try:
!             s = StringIO(mfile.read())
!         except multifile.Error:
!             # It is a mis-formated or incomplete message
!             return None
          msg2 = mimetools.Message(s)
          if msg2.gettype() == 'text/plain':
              desc = msg2.get('content-description')



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun  8 04:45:16 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Wed, 7 Jun 2000 20:45:16 -0700 (PDT)
Subject: [Mailman-Developers] Mass unsubscription
Message-ID: <200006080345.UAA03544@utopia.west.sun.com>

Anyone have any comments?

Barry/Harald/whoever, as much discussion as this engendered on
mailman-users, if this looks good, maybe it could get squeezed into
beta3 (due any second now, right)?

------------- Begin Forwarded Message -------------

Date: Wed, 7 Jun 2000 20:21:30 -0700 (PDT)
From: Dan Mick <Dan.Mick@west.sun.com>
To: mailman-users@python.org
Subject: [Mailman-Users] Mass unsubscription
X-Beenthere: mailman-users@python.org
X-Mailman-Version: 2.0beta3
List-Id: Mailman mailing list management users <mailman-users.python.org>

In the "put up or shut up" category, I volunteer this patch to
add and process a "mass-unsubscribe" text box to the "Membership
Management" page for Mailman 1.1 (I haven't tried to make it 
apply to any 2.0 yet, although I'm sure the code will be similar).

It seems to work for me for a test list.  YMMV.  I'll submit
it over on mailman-developers too and see if anyone has any
criticism.

The file that changes is Cgi/admin.py:



*** admin.py.orig       Thu Jun  1 23:09:46 2000
--- admin.py    Wed Jun  7 20:18:52 2000
***************
*** 612,617 ****
--- 612,626 ----
      container.AddItem(Center(t))
      container.AddItem(Center(TextArea(name='subscribees',
                                        rows=10,cols=60,wrap=None)))
+     t = Table(width="90%")
+     t.AddRow([Center(Header(4, "Mass Remove Members"))])
+     t.AddCellInfo(t.GetCurrentRowIndex(),
+                   t.GetCurrentCellIndex(),
+                   bgcolor="#cccccc", colspan=8)
+     t.AddRow(["Enter one address to remove per line: <p>"])
+     container.AddItem(Center(t))
+     container.AddItem(Center(TextArea(name='unsubscribees',
+                                       rows=10,cols=60,wrap=None)))
      return container
  
  def FormatPasswordStuff():
***************
*** 877,882 ****
--- 886,920 ----
                      dirty = 1
          if unsubscribe_errors:
              document.AddItem(Header(5, "Error Unsubscribing:"))
+             items = map(lambda x: "%s -- %s" % (x[0], x[1]), 
unsubscribe_errors)
+             document.AddItem(apply(UnorderedList, tuple((items))))
+             document.AddItem("<p>")
+ 
+     #
+     # mass unsubscription processing for members category
+     #
+     if cgi_info.has_key('unsubscribees'):
+       name_text = cgi_info['unsubscribees'].value
+         name_text = string.replace(name_text, '\r', '')
+       names = map(string.strip, string.split(name_text, '\n'))
+         unsubscribe_errors = []
+         unsubscribe_success = []
+       for name in names:
+          try:
+             lst.DeleteMember(name)
+          except:
+             unsubscribe_errors.append(name, "No such user")
+          else:
+             unsubscribe_success.append(name)
+ 
+         if unsubscribe_success:
+             document.AddItem(Header(5, "Successfully Unsubscribed:"))
+             document.AddItem(apply(UnorderedList, 
tuple((unsubscribe_success))))
+             document.AddItem("<p>")
+             dirty = 1
+ 
+         if unsubscribe_errors:
+             document.AddItem(Header(5, "Error Unsubscribing:"))
              items = map(lambda x: "%s -- %s" % (x[0], x[1]), 
unsubscribe_errors)
              document.AddItem(apply(UnorderedList, tuple((items))))
              document.AddItem("<p>")


------------------------------------------------------
Mailman-Users maillist  -  Mailman-Users@python.org
http://www.python.org/mailman/listinfo/mailman-users

------------- End Forwarded Message -------------





From chuqui@plaidworks.com  Thu Jun  8 07:04:55 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 7 Jun 2000 23:04:55 -0700
Subject: [Mailman-Developers] an issue with the listinfo/<listname> page...
Message-ID: <p04310101b564e6ca796f@[209.239.169.197]>


I was working upgrading to the latest CVS tonight, and realized 
there's a problem with the list page put up when you go to 
.../listinfo/listname.

that's the URL used when someone wants to access the list or 
subscribe to it, but there's no link there that allows a user to log 
on and change their subscription option. that's a different URL 
(../listinfo/listname/emailaddr) that's sent to them when they 
subscribe, but you can't assume they'll save that (in fact, you can 
guarantee most of them won't), so the user dead-ends trying to get 
into the web site to try to change their options.

There really needs to be a way, both on the listinfo/ page and the 
listinfo/listname page, for an existing subscriber to sign in and get 
to their subscription configuration page. Otherwise, people are going 
to get lost and end up annoying the admin for help...

I'd classify this as a medium to medium-high problem, because it's a 
huge dead end in the interface with a significant number of users 
who'll be looking for it.

chuq
-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jwt@dskk.co.jp  Thu Jun  8 08:20:36 2000
From: jwt@dskk.co.jp (Jim Tittsler)
Date: Thu, 8 Jun 2000 16:20:36 +0900
Subject: [Mailman-Developers] Multilingual support
In-Reply-To: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>; from gpoo@ubiobio.cl on Tue, Jun 06, 2000 at 12:29:52PM -0300
References: <Pine.A32.4.10.10006061117430.5839-100000@zeus.dci.ubiobio.cl>
Message-ID: <20000608162036.A19873@mail.dskk.co.jp>

On Tue, Jun 06, 2000 at 12:29:52PM -0300, German Poo Caaman~o wrote:
> 
> I've downloaded Mailman-2.0b2 and I'v translated the templates files
> to spanish, but it wasn't enough.  Some web pages appears with
> english and spanish words.
> 
> Are there some language support on mind?   May be, a language file
> where reside all words used on the interface (buttons, messages,
> etc.).

There is a I18n effort with its own mailing list
http://www.python.org/mailman/listinfo/mailman-i18n

I believe the I18n work is essentially on hold until after the basic
features for version 2.0 are complete.

-- 
Jim Tittsler, Tokyo
Python Starship     http://starship.python.net/crew/jwt/



From gorgo@caesar.elte.hu  Thu Jun  8 12:23:00 2000
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Thu, 8 Jun 2000 13:23:00 +0200 (METDST)
Subject: [Mailman-Developers] subscription notification
Message-ID: <Pine.A32.3.96.1000608132202.42066M-100000@caesar.power.elte.hu>

Hello,

I have noticed another change between 1.1 and 2.0beta2... on a closed list
when the list admin approves someones subscription, he doesn't get an
email notification of the subscription

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From gorgo@caesar.elte.hu  Thu Jun  8 13:09:14 2000
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Thu, 8 Jun 2000 14:09:14 +0200 (METDST)
Subject: [Mailman-Developers] subscription notification
In-Reply-To: <Pine.A32.3.96.1000608132202.42066M-100000@caesar.power.elte.hu>
Message-ID: <Pine.A32.3.96.1000608140852.42066Q-100000@caesar.power.elte.hu>

On Thu, 8 Jun 2000, Gergely Madarasz wrote:

> Hello,
> 
> I have noticed another change between 1.1 and 2.0beta2... on a closed list
> when the list admin approves someones subscription, he doesn't get an
> email notification of the subscription

Ah, sorry, the notification arrived, just a bit late... :)

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From ricardo@rixhq.nu  Fri Jun  9 08:16:11 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 9 Jun 2000 09:16:11 +0200
Subject: [Mailman-Developers] userdatabases
Message-ID: <20000609091611.A1188@miss-janet.com>

Hi,

I know this subject has been touched before... but I was wondering if
anybody has yet implemented some system where mailman is used next to
a userdatabase where every subscriber is linked somehow to a user in
that database. There are probably 1001 ways to synchronize mailman
subscribers with an external user database, but the problem is finding
the best solution. At this moment our programmers have several projects
where announce mail lists are going to be needed, but of course
customers want to have more details for every subscriber than just
their email address. I've been pushing them to use mailman and I've been 
successfull so far, but we still haven't come up with a solution for the problem above...

My job-description doesn't officially include programming :) but I'm
willing to invest some of my own time in creating some standard solution
for this which I could contribute back to mailman...

So if anybody has any ideas... please let me know!

Ricardo.

--



From ricardo@rixhq.nu  Sat Jun 10 10:03:49 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 10 Jun 2000 11:03:49 +0200
Subject: [Mailman-Developers] Mass unsubscription
In-Reply-To: <200006080345.UAA03544@utopia.west.sun.com>; from Dan.Mick@West.Sun.COM on Wed, Jun 07, 2000 at 08:45:16PM -0700
References: <200006080345.UAA03544@utopia.west.sun.com>
Message-ID: <20000610110349.B872@miss-janet.com>

On Wed, Jun 07, 2000 at 08:45:16PM -0700, Dan Mick wrote:
> Anyone have any comments?
> Barry/Harald/whoever, as much discussion as this engendered on
> mailman-users, if this looks good, maybe it could get squeezed into
> beta3 (due any second now, right)?

i added something simular to a local copy of mailman a while ago,
but it got lost with updating cvs versions... anyway I personally
think this is a good feature to add -- I know I will be using it...

ps: i notice my posts sometimes don't arrive on the develop list or
are very late... am I'm being victim of the mailman code post restricting
behavior? ;) [now i know how our users feel who keep complaining about
posts arriving late due to the moderating feature LOL]

Ricardo.


From ricardo@rixhq.nu  Sat Jun 10 10:09:01 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 10 Jun 2000 11:09:01 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
In-Reply-To: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>; from andrea@integra-italia.com on Wed, Jun 07, 2000 at 04:21:06PM +0200
References: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>
Message-ID: <20000610110901.C872@miss-janet.com>

On Wed, Jun 07, 2000 at 04:21:06PM +0200, Andrea Paparelli wrote:
> Bug in Mailman version 1.1
>   File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
> CheckCookie
>     if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
> IndexError: string index out of range

I stumbled on this a few times too... but it is very hard to reproduce...
what I think went wrong in my situation most of those times is that somehow
the cookie got mixed up with a different cookie which was set by a different
program at the exact same server as mailman...
anybody had simular experiences?

Ricardo.


From chuqui@plaidworks.com  Sun Jun 11 23:55:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 15:55:00 -0700
Subject: [Mailman-Developers] updating templates..
Message-ID: <p0431010eb569c85c9b4d@[209.239.169.197]>

Been playing with the templates today (or trying to... ), and 
couldn't figure out why updates to the templates weren't showing up 
in the browser. It's because, of course, when a list is created it 
copies templates into the /lists/<listname>/ subdirectory, so changes 
to the /templates subdirectory only work on new lists.

It looks like there's no "update existing lists" makefile or script, either.

I'd suggest that the newlist function create symlinks into the 
templates directory instead of copying the file, so that changes 
automatically propogate to all of the lists, while still allowing 
admins to break the link and create a custom page if they want to. 
Otherwise, updating a site with lots of lists is going to be a royal 
pain if you want to redo the look and feel.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Mon Jun 12 04:33:17 2000
From: jim@cosource.com (Jim Hebert)
Date: Sun, 11 Jun 2000 23:33:17 -0400 (EDT)
Subject: [Mailman-Developers] updating templates..
In-Reply-To: <p0431010eb569c85c9b4d@[209.239.169.197]>
Message-ID: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>

On Sun, 11 Jun 2000, Chuq Von Rospach wrote:

> I'd suggest that the newlist function create symlinks into the 
[...]

When I ran a Smartlist installation in a former life, it did a similar
thing, only it used hardlinks to accomplish the task.

Is there any wisdom in doing one over the other? I don't recall why
smartlist used hardlinks, though something makes me wonder if it wasn't to
satisfy anti-symlink sanity checks, e.g. in procmail.

jim
who probably should just assume that Chuq has already done that
calculation and decided on symlinks =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox



From chuqui@plaidworks.com  Mon Jun 12 04:39:45 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 20:39:45 -0700
Subject: [Mailman-Developers] updating templates..
In-Reply-To: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006112329100.3753-100000@ray.compu-aid.com>
Message-ID: <p04310110b56a0ae43c2b@[209.239.169.197]>

At 11:33 PM -0400 6/11/2000, Jim Hebert wrote:

>When I ran a Smartlist installation in a former life, it did a similar
>thing, only it used hardlinks to accomplish the task.
>
>Is there any wisdom in doing one over the other? I don't recall why
>smartlist used hardlinks,

Not really. I'm sure there are some flavors of unix without symlinks 
in them, but I wouldn't use one. Hard links don't work across 
filesystems. If, for instance, a site wanted to move the 
list/listname folder into a users home directory for access and/or 
quota regulation, symlinks work great, hard links might of might not.

>who probably should just assume that Chuq has already done that
>calculation and decided on symlinks =)

Nah. I just use symlinks unless there's some overriding reason not to.

About the only real advantage of hard links is if someone rm's the 
thing the symlink is pointing to, everyone's copy breaks, but if you 
use hard links, only that instance goes away. On the other hand, what 
happens more often is someone unlinks a copy thinking it's the 
master, changes it,a nd simply breaks the link rather than updating 
all of the copies.

In this case, I chose symlinks because the files aren't next to each 
other, so figuring out what they're linked to is going to be 
impossible with hard links. I hate hard links that aren't in the same 
directory -- but that's a religious issue, not any hard technical one.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 05:17:26 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 21:17:26 -0700
Subject: [Mailman-Developers] updated listinfo.html template...
Message-ID: <p04310111b56a1444700e@[209.239.169.197]>

I've been whacking on this today, and I thought I'd pass off a copy. 
If you want to see this in action, take a quick gander at 
<http://newboy.plaidworks.com/mailman/listinfo/test>

It doesn't include some minor tweaks to the text in HTMLformatter.py, 
but those are fairly minor rewordings. Once I'm done, I'll get the 
whole thing packaged up.

<!-- $Revision: 1.20 $ -->
<HTML>
     <HEAD>
	<TITLE>The <MM-List-Name> Mailing List</TITLE>
     </HEAD>
     <BODY BGCOLOR="#ffffff">
	<table width="100%" border="0" cellpadding="10">
	    <tr><td><A HREF="/"><img src="/images/plaidworks.logo.gif"
		width="168" height="169"></a>
	    </td><td> <img src="/images/mainlogo.gif" width="601" height="124">
	    </td></tr>
	    <tr><td COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC" ALIGN="RIGHT">
		<B>
		<A HREF="/">Home</a> -+-
		<A HREF="/lists">Mailing Lists home</a> -+-
		<A HREF="#About">About <MM-List-Name></a>
		<BR>
		<A HREF="#Subscribe">Subscribe</a> -+-
		<A HREF="#Unsubscribe">Unsubscribe</a> -+-
		<A HREF="#Unsubscribe">Change Subscription</a>
		<BR>
		<A HREF="#Posting">Posting</a> -+-
		<A HREF="#Archives">Archives</a> -+-
		<A HREF="#Subscribers">Subscribers</a>
		</B>
	    </td></tr>
	</table>
	<MM-Subscribe-Form-Start>
	<P>
	<TABLE COLS="2" BORDER="0" CELLSPACING="4" CELLPADDING="5">
	<TR><TD COLSPAN="2" WIDTH="100%" ALIGN="CENTER">
	    <A NAME="About"><B><FONT COLOR="#000000" SIZE="+2"><MM-List-Name>:
	    <MM-List-Description></FONT></B>
	</TD></TR>
	<tr><td colspan="2"><p>&nbsp;
	</td></tr>
	<tr> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <B><FONT COLOR="#000000" SIZE="+1">About The <MM-List-Name>
	    Mailing List</FONT></B>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    <P><MM-List-Info></P>
	</TD></TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Subscribe">
	    <B><FONT COLOR="#000000" SIZE="+1">Subscribing to <MM-List-Name>
	    </FONT></B>
	</TD></TR>
	<tr><td colspan="2">
	    <P>To subscribe to <B><MM-List-Name></B>, fill out this form.
	    <MM-List-Subscription-Msg>
	    <BLOCKQUOTE>
	    <TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2"
		WIDTH="70%" HEIGHT= "112">
		<TR><TD BGCOLOR="#cccccc" WIDTH="55%">Your email address:</TD>
		<TD WIDTH="33%"><MM-Subscribe-Box></TD>
		<TD WIDTH="12%">&nbsp;</TD></TR><TR>
		<TD COLSPAN="3">
		    <BLOCKQUOTE>
		    You must enter a privacy
		    password. This provides only mild security, but should
		    prevent others from modifying your subscription.  <b>Do
		    not use the password to your account</b>. Use something
		    you will remember, but which won't give someone access to
		    your accounts if they somehow get their hands on it.
		    <MM-Reminder>
		    </BLOCKQUOTE>
		</TD></TR>
		<TR><TD BGCOLOR="#cccccc">Pick a password:</TD>
		<TD><MM-New-Password-Box></TD>
		<TD>&nbsp;</TD></TR>
		<TR> <TD BGCOLOR="#cccccc">Re-enter password to confirm:</TD>
		<TD><MM-Confirm-Password></TD>
		<TD>&nbsp; </TD></TR>
		<tr><td>Would you like to receive list mail batched in a daily
		    digest?
		</td><td><MM-Undigest-Radio-Button> No
		    <MM-Digest-Radio-Button>  Yes
		</TD></tr>
		<tr><td colspan="3">
		    <center><MM-Subscribe-Button></P></center>
		</TD></tr>
	    </TABLE>
	    <MM-Form-End>
	    </BLOCKQUOTE>
	    </td></tr>
	    <TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
		<a name="Unsubscribe">
		<B><FONT COLOR="#000000" SIZE="+1">Unsubscribe and Change
		    Subscription Options</FONT></B>
	    </TD></TR>
	    <TR><TD COLSPAN="2" WIDTH="100%">
		<MM-Subscribe-Form-Start>
		<MM-Editing-Options>
		<MM-Form-End>
	    </td></tr>
	</TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Posting">
	    <B><FONT COLOR="#000000" <FONT SIZE="+1">Posting to
		<MM-List-Name></FONT></B>
	</TD></TR>
	<tr><td colspan="2">
	    To post a message to all the list members, send email to
	    <A HREF="mailto:<MM-Posting-Addr>"><MM-Posting-Addr></A>.
	</td></tr>
	<tr><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <A NAME="Archives">
	    <B><FONT COLOR="#000000" SIZE="+1"><MM-List-Name> Archives
	    </FONT></B>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    To see the collection of prior postings to the list,
	    visit the <MM-Archive><MM-List-Name> Archives</MM-Archive>.
	    <MM-Restricted-List-Message>
	</TD></TR>
	<TR><TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCCCC">
	    <a name="Subscribers">
	    <B><FONT COLOR="#000000" SIZE = "+1">
	    <MM-List-Name> Subscribers</FONT></B></a>
	</TD></TR>
	<tr><TD COLSPAN="2" WIDTH="100%">
	    <MM-Roster-Form-Start>
	    <MM-Roster-Option>
	    <MM-Form-End>
	    <p>
	</TD></TR>
     </table>
     <MM-Mailman-Footer>
</BODY>
</HTML>

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 05:26:13 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 21:26:13 -0700
Subject: [Mailman-Developers] dead pipermail link
Message-ID: <p04310112b56a16af0185@[209.239.169.197]>

the link generated by pipermail in the archives to the pipermail site 
is dead....

<http://starship.skyport.net/crew/amk/maintained/pipermail.html> no 
longer exists.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From chuqui@plaidworks.com  Mon Jun 12 06:15:08 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 11 Jun 2000 22:15:08 -0700
Subject: [Mailman-Developers] GetRelativeScriptURL problem
Message-ID: <p04310113b56a218c8eca@[209.239.169.197]>

--============_-1251335476==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"


There's a problem with GetRelativeScriptURL. If you go to

..mailman/listinfo/<listname> and from there, go into the edit 
options page, on that page, (..mailman/subscribe/<listname>), the 
link at the bottom of the page back to <listname> is wrong. 
GetRelativeScriptURL generates

<hr><address><a href="../../listinfo/test">Test</a> list run by

which is incorrect. It really ought to be ../listinfo/test

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"
--============_-1251335476==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>GetRelativeScriptURL problem</title></head><body>
<div><br></div>
<div>There's a problem with GetRelativeScriptURL. If you go to</div>
<div><br></div>
<div>..mailman/listinfo/&lt;listname&gt; and from there, go into the
edit options page, on that page,
(..mailman/subscribe/&lt;listname&gt;), the link at the bottom of the
page back to &lt;listname&gt; is wrong. GetRelativeScriptURL
generates</div>
<div><br></div>
<div><font face="Monaco" color="#000000">&lt;</font><font
face="Monaco" color="#0000FF">hr</font><font face="Monaco"
color="#000000">&gt;&lt;</font><font face="Monaco"
color="#0000FF">address</font><font face="Monaco"
color="#000000">&gt;&lt;</font><font face="Monaco"
color="#0000FF">a</font><font face="Monaco" color="#000000">
href=&quot;../../listinfo/test&quot;&gt;Test&lt;</font><font
face="Monaco" color="#0000FF">/a</font><font face="Monaco"
color="#000000">&gt; list run by</font></div>
<div><font face="Monaco" color="#000000"><br></font></div>
<div><font face="Monaco" color="#000000">which is incorrect. It
really ought to be ../listinfo/test</font></div>
<div><font face="Monaco" color="#000000"><br></font></div>

<div>-- <br>
Chuq Von Rospach - Plaidworks Consulting
(mailto:chuqui@plaidworks.com) <br>
Apple Mail List Gnome (mailto:chuq@apple.com) <br>
<br>
And they sit at the bar and put bread in my jar<br>
and say 'Man, what are you doing here?'&quot;</div>
</body>
</html>
--============_-1251335476==_ma============--


From dan@feld.cvut.cz  Mon Jun 12 17:09:26 2000
From: dan@feld.cvut.cz (Dan Ohnesorg)
Date: Mon, 12 Jun 2000 18:09:26 +0200 (CEST)
Subject: [Mailman-Developers] using https for admin purposes
Message-ID: <Pine.LNX.4.21.0006121734490.27940-200000@poli.feld.cvut.cz>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--546564545-459075905-960824974=:27940
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0006121807381.27940@poli.feld.cvut.cz>

I have tried last CVS version and I have find some bug, which was also in
1.x version too. The admin.py (and other) uses for members addresses
formating function:

mlist.GetAbsoluteOptionsURL(member, obscure=1)

which will use http://, when it is set in list options. I think it will be
match better to use GetOptionsURL(...relative=1), becouse it is legal to
use http for users and https for admins.

Patch which makes this is attached. It will be possible to switch https X
https according to enviroment created by webserver, but I think, so it is
good enought.

cheers
dan


-- 
                    ________________________________________
DDDDDD             
DD   DD                Dan Ohnesorg, supervisor on POWER     
DD  OOOO               Dan@feld.cvut.cz
DD OODDOO              Dep. of Power Engineering
DDDDDD OO              CTU FEL Prague, Bohemia
   OO  OO              work: +420 2 24352785;+420 2 24972109
    OOOO               home: +420 311 679679;+420 311 679311
                    ________________________________________

Nejztracenejsi den naseho zivota
je ten, kdy jsme se nezasmali.

--546564545-459075905-960824974=:27940
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman.https.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0006121809260.27940@poli.feld.cvut.cz>
Content-Description: 
Content-Disposition: attachment; filename="mailman.https.patch"

ZGlmZiAtdXIgbWFpbG1hbjIub2xkL01haWxtYW4vQ2dpL2FkbWluLnB5IG1h
aWxtYW4yL01haWxtYW4vQ2dpL2FkbWluLnB5DQotLS0gbWFpbG1hbjIub2xk
L01haWxtYW4vQ2dpL2FkbWluLnB5CU1vbiBKdW4gMTIgMTY6NTg6MTIgMjAw
MA0KKysrIG1haWxtYW4yL01haWxtYW4vQ2dpL2FkbWluLnB5CU1vbiBKdW4g
MTIgMTc6NDI6MjAgMjAwMA0KQEAgLTU3MSw3ICs1NzEsNyBAQA0KICAgICAg
ICAgYnV0dG9ucyA9IFtdDQogICAgICAgICBmb3IgY2kgaW4gY2h1bmtfaW5k
aWNlczoNCiAgICAgICAgICAgICBzdGFydCwgZW5kID0gY2h1bmtzW2NpXVsw
XSwgY2h1bmtzW2NpXVstMV0NCi0JICAgIHVybCA9IG1saXN0LkdldEFic29s
dXRlU2NyaXB0VVJMKCdhZG1pbicpDQorCSAgICB1cmwgPSBtbGlzdC5HZXRT
Y3JpcHRVUkwoJ2FkbWluJywgcmVsYXRpdmU9MSkNCiAgICAgICAgICAgICBi
dXR0b25zLmFwcGVuZCgiPGEgaHJlZj0lcy9tZW1iZXJzP2NodW5rPSVkPiBm
cm9tICVzIHRvICVzIDwvYT4iDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJSAoIHVybCwgIGNpLCBzdGFydCwgZW5kKSkNCiAgICAgICAgIGJ1dHRv
bnMgPSBhcHBseShVbm9yZGVyZWRMaXN0LCB0dXBsZShidXR0b25zKSkNCkBA
IC01ODEsNyArNTgxLDcgQEANCiAgICAgICAgIGZvb3RlciA9ICI8cD4iDQog
ICAgIGZvciBtZW1iZXIgaW4gYWxsOg0KICAgICAgICAgbXRleHQgPSAnPGEg
aHJlZj0iJXMiPiVzPC9hPicgJSAoDQotICAgICAgICAgICAgbWxpc3QuR2V0
QWJzb2x1dGVPcHRpb25zVVJMKG1lbWJlciwgb2JzY3VyZT0xKSwNCisgICAg
ICAgICAgICBtbGlzdC5HZXRPcHRpb25zVVJMKG1lbWJlciwgb2JzY3VyZT0x
LCByZWxhdGl2ZT0xKSwNCiAgICAgICAgICAgICBtbGlzdC5HZXRVc2VyU3Vi
c2NyaWJlZEFkZHJlc3MobWVtYmVyKSkNCiAgICAgICAgIGNlbGxzID0gW210
ZXh0ICsgIjxpbnB1dCB0eXBlPWhpZGRlbiBuYW1lPXVzZXIgdmFsdWU9JXM+
IiAlIChtZW1iZXIpLA0KICAgICAgICAgICAgICAgICAgQ2VudGVyKENoZWNr
Qm94KG1lbWJlciArICJfc3Vic2NyaWJlZCIsICJvbiIsIDEpLkZvcm1hdCgp
KV0NCmRpZmYgLXVyIG1haWxtYW4yLm9sZC9NYWlsbWFuL0NnaS9oYW5kbGVf
b3B0cy5weSBtYWlsbWFuMi9NYWlsbWFuL0NnaS9oYW5kbGVfb3B0cy5weQ0K
LS0tIG1haWxtYW4yLm9sZC9NYWlsbWFuL0NnaS9oYW5kbGVfb3B0cy5weQlN
b24gSnVuIDEyIDE2OjU4OjEyIDIwMDANCisrKyBtYWlsbWFuMi9NYWlsbWFu
L0NnaS9oYW5kbGVfb3B0cy5weQlNb24gSnVuIDEyIDE3OjQ2OjA0IDIwMDAN
CkBAIC0xNjIsNyArMTYyLDcgQEANCiAgICAgICAgICAgICAgICAgICAgIGFk
ZHIgPSBVdGlscy5PYnNjdXJlRW1haWwoYWRkcnNbMF0pDQogICAgICAgICAg
ICAgICAgICAgICBpZiBtbGlzdC5vYnNjdXJlX2FkZHJlc3NlczoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICBhZGRyID0gVXRpbHMuT2JzY3VyZUVtYWls
KGFkZHIpDQotICAgICAgICAgICAgICAgICAgICB1cmwgPSBtbGlzdC5HZXRB
YnNvbHV0ZU9wdGlvbnNVUkwoYWRkcikNCisgICAgICAgICAgICAgICAgICAg
IHVybCA9IG1saXN0LkdldE9wdGlvbnNVUkwoYWRkciwgcmVsYXRpdmU9MSkN
CiAgICAgICAgICAgICAgICAgICAgIGxpbmsgPSBMaW5rKHVybCwgbWxpc3Qu
cmVhbF9uYW1lKQ0KICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIG1saXN0
LmludGVybmFsX25hbWUoKSwgbGluaw0KIA0KZGlmZiAtdXIgbWFpbG1hbjIu
b2xkL01haWxtYW4vSFRNTEZvcm1hdHRlci5weSBtYWlsbWFuMi9NYWlsbWFu
L0hUTUxGb3JtYXR0ZXIucHkNCi0tLSBtYWlsbWFuMi5vbGQvTWFpbG1hbi9I
VE1MRm9ybWF0dGVyLnB5CU1vbiBKdW4gMTIgMTY6NTg6MTIgMjAwMA0KKysr
IG1haWxtYW4yL01haWxtYW4vSFRNTEZvcm1hdHRlci5weQlNb24gSnVuIDEy
IDE4OjA0OjAxIDIwMDANCkBAIC0yOTksNyArMjk5LDcgQEANCiAgICAgICAg
IHJldHVybiBjb250YWluZXINCiANCiAgICAgZGVmIEZvcm1hdEZvcm1TdGFy
dChzZWxmLCBuYW1lLCBleHRyYT0nJyk6DQotCWJhc2VfdXJsID0gc2VsZi5H
ZXRBYnNvbHV0ZVNjcmlwdFVSTChuYW1lKQ0KKwliYXNlX3VybCA9IHNlbGYu
R2V0U2NyaXB0VVJMKG5hbWUsIHJlbGF0aXZlPTEpDQogICAgICAgICBpZiBl
eHRyYToNCiAgICAgICAgICAgICBmdWxsX3VybCA9ICIlcy8lcyIgJSAoYmFz
ZV91cmwsIGV4dHJhKQ0KICAgICAgICAgZWxzZToNCg==
--546564545-459075905-960824974=:27940--


From Harald.Meland@usit.uio.no  Mon Jun 12 17:28:29 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 12 Jun 2000 18:28:29 +0200
Subject: [Mailman-Developers] Bug Found in Mailman
In-Reply-To: Ricardo Kustner's message of "Sat, 10 Jun 2000 11:09:01 +0200"
References: <HDEFLINFLAIJEOGMABMEGECPCBAA.andrea@integra-italia.com>
 <20000610110901.C872@miss-janet.com>
Message-ID: <d6daegqn9si.fsf@octarine.uio.no>

[Ricardo Kustner]

> On Wed, Jun 07, 2000 at 04:21:06PM +0200, Andrea Paparelli wrote:
> > Bug in Mailman version 1.1
> >   File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in
> > CheckCookie
> >     if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"':
> > IndexError: string index out of range
> 
> I stumbled on this a few times too... but it is very hard to reproduce...
> what I think went wrong in my situation most of those times is that somehow
> the cookie got mixed up with a different cookie which was set by a different
> program at the exact same server as mailman...
> anybody had simular experiences?

I haven't seen this happen with my users, but as the offending piece
of code indeed is a hack that won't work reliably if the browser sends
multiple cookies, I think this should be addressed somehow.

The real problem, I think, is that there's confusion on the subject of
cookie content syntax.

The original Netscape proposal uses this (not very well-defined, IMO)
cookie content syntax:

: NAME=VALUE
:      This string is a sequence of characters excluding semi-colon,
:      comma and white space. If there is a need to place such data in
:      the name or value, some encoding method such as URL style %XX
:      encoding is recommended, though no encoding is defined or
:      required.

A quick example:
[ Server -> Client ]
  Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

[ Client -> Server ]
  Cookie: CUSTOMER=WILE_E_COYOTE

Note that there are no quotes around the cookie value.


RFC 2109, however, has a more well-defined, but ever so slightly
different content syntax:

: 4.1  Syntax:  General
: 
:    The two state management headers, Set-Cookie and Cookie, have common
:    syntactic properties involving attribute-value pairs.  The following
:    grammar uses the notation, and tokens DIGIT (decimal digits) and
:    token (informally, a sequence of non-special, non-white space
:    characters) from the HTTP/1.1 specification [RFC 2068] to describe
:    their syntax.
: 
:    av-pairs        =       av-pair *(";" av-pair)
:    av-pair         =       attr ["=" value]        ; optional value
:    attr            =       token
:    value           =       word
:    word            =       token | quoted-string

Note that the cookies value can be a quoted-string.  The example from
the Netscape spec could look like this using the RFC syntax:

[ Server -> Client ]
  Set-Cookie: CUSTOMER="WILE_E_COYOTE"; Version="1"; Path="/"; Max-Age="3600"

[ Client -> Server ]
  Cookie: $Version="1"; CUSTOMER="WILE_E_COYOTE"; $Path="/"


(Some time back) I looked over misc/Cookie.py trying to find some way
to make it cope reliably with both kinds of cookies, but wasn't really
able to discover what's wrong with _CookiePattern :(

I suspect that using "Max-Age" attributes on Mailman cookies instead
of the current (non-RFC) "Expires" attribute *might* help, but I
really don't have any idea whether such a change will stop Mailman
from working with certain browsers.
-- 
Harald


From jmackenzie@local.ie  Tue Jun 13 12:05:32 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Tue, 13 Jun 2000 12:05:32 +0100
Subject: [Mailman-Developers] Issue with one List, Upgraded To 2.0 last friday
Message-ID: <00061312070500.01462@samsara.local.ie>

Hey guys, 

I've got an issue with A Mailman list I'm running, it worked fine until the
upgrade. 

I Attached the bug report it generated... Any ideas ?

Bug in Mailman version 2.0beta2

We're sorry, we hit a bug!

If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! 

Traceback:

Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 89, in run_main
    main()
  File "/home/mailman/Mailman/Cgi/admindb.py", line 125, in main
    mlist.Save()
  File "/home/mailman/Mailman/MailList.py", line 853, in Save
    self.SaveRequestsDb()
  File "/home/mailman/Mailman/ListAdmin.py", line 89, in SaveRequestsDb
    self.__closedb()
  File "/home/mailman/Mailman/ListAdmin.py", line 73, in __closedb
    assert self.Locked()
AssertionError: 





Python information:

     Variable
                                               Value
 sys.version
                 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- 
 sys.executable
                 /usr/bin/python 
 sys.prefix
                 /usr 
 sys.exec_prefix
                 /usr 
 sys.path
                 /usr 
 sys.platform
                 linux-i386 




Environment variables:

        Variable
                                                                                        Value
 DOCUMENT_ROOT 
                       /www/local-ireland/db/dbwww 
 SERVER_ADDR 
                       159.134.244.165 
 HTTP_ACCEPT_ENCODING 
                       gzip 
 REMOTE_HOST 
                       server01.merrion.nua.net 
 CONTENT_TYPE 
                       application/x-www-form-urlencoded 
 PATH_TRANSLATED 
                       /www/local-ireland/db/dbwww/local-ancestors 
 REMOTE_ADDR 
                       195.7.46.71 
 SERVER_SOFTWARE 
                       Apache/1.3.9 (Unix) (Red Hat/Linux) 
 GATEWAY_INTERFACE 
                       CGI/1.1 
 HTTP_COOKIE 
                       local-ancestors:admin="(lp1\012F960892961.80800498\012aI960903761\012aS'\\317bjG\\352\\010qA\\014`\\024\\3360\\374\\325\\211'\012p2\012a.";
                       RMID=c3072e4738e8aa90; Apache=server01.merrion.nua.net.21641958579664595 
 HTTP_ACCEPT_LANGUAGE 
                       en 
 REMOTE_PORT 
                       1240 
 SERVER_PORT 
                       80 
 HTTP_CONNECTION 
                       Keep-Alive 
 HTTP_USER_AGENT 
                       Mozilla/4.7 [en] (X11; I; Linux 2.2.12-20 i686) 
 HTTP_ACCEPT_CHARSET 
                       iso-8859-1,*,utf-8 
 HTTP_ACCEPT 
                       image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* 
 REQUEST_URI 
                       /mailman/admindb/local-ancestors 
 PATH 
                       /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin 
 QUERY_STRING 
 SERVER_PROTOCOL 
                       HTTP/1.0 
 CONTENT_LENGTH 
                       5447 
 HTTP_HOST 
                       www.local.ie 
 REQUEST_METHOD 
                       POST 
 SERVER_SIGNATURE 
 SCRIPT_NAME 
                       /mailman/admindb 
 SERVER_ADMIN 
                       webmaster@local.ie 
 SCRIPT_FILENAME 
                       /home/mailman/cgi-bin/admindb 
 PYTHONPATH 
                       /home/mailman 
 PATH_INFO 
                       /local-ancestors 
 HTTP_REFERER 
                       http://www.local.ie/mailman/admindb/local-ancestors 
 SERVER_NAME 
                       www.local.ie 


From jmackenzie@local.ie  Tue Jun 13 12:17:13 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Tue, 13 Jun 2000 12:17:13 +0100
Subject: [Mailman-Developers] Issue with one List, Upgraded To 2.0 last friday
In-Reply-To: <00061312070500.01462@samsara.local.ie>
References: <00061312070500.01462@samsara.local.ie>
Message-ID: <00061312161401.01462@samsara.local.ie>

I stupidly forgot to mention that this occured while i was attempting to
approve a Mail to the list. If I discard it It works as it normally would. 

Regards
- john


On Tue, 13 Jun 2000, you wrote:
> Hey guys, 
> 
> I've got an issue with A Mailman list I'm running, it worked fine until the
> upgrade. 
<snip>


From bwarsaw@python.org  Wed Jun 14 05:57:48 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 00:57:48 -0400 (EDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
 <d6d4s79du5t.fsf@octarine.uio.no>
Message-ID: <14663.4300.188254.867225@anthem.concentric.net>

    HM> I still don't see why there's a need for the "intermediate"
    HM> state (neither fully locked nor fully unlocked) with the
    HM> shared lockfile having a link count of 1.  I think it just
    HM> makes the locking logic more complicated to understand.

You've convinced me.  I'm about to check in a bunch of changes,
including some to LockFile.py in which I've basically installed your
patch.  The one thing I'm not sure about is removing the try/except
around the unlink of winner -- I think there's still a race condition
where winner could be non-empty but the unlink could fail.  The
try/except shouldn't hurt so I'm leaving that one thing in.

    HM> The other method that currently unlinks the shared lockfile is
    HM> __break().  The purpose of that method is to remove lockfiles
    HM> that some other process has failed to release within the
    HM> lock's lifetime.  Thus, this method breaks the invariant you
    HM> mention *by design*.

I think __break() is fundamentally broken.  Actually, I think breaking
locks gets us into all kinds of problems.  But there's the trade-off
of deadlocking the whole system for something we haven't thought
about.

One approach might be to never break locks implicitly, but have
qrunner (which now runs every minute) check for long-dead locks and
send warning emails to the site admin.  A simple rm should clear up
the problem.

As an interim approach, I'm just cranking up the qrunner and list lock
lifetimes to really big numbers (like 10 hours and 5 hours
respectively).  Hopefully, in conjunction with some other soon to be
checked in changes, this will help many of the problems that I think
are premature-lock-breaking related.

All this is just whacked anyway.  What we really need is a
transactional database underneath so we wouldn't need all these stupid
list locks.  I still believe that's too much work for 2.0, but as this
beta3 drags on, I'm starting to have doubts.

-Barry


From dgc@uchicago.edu  Wed Jun 14 06:31:14 2000
From: dgc@uchicago.edu (David Champion)
Date: Wed, 14 Jun 2000 00:31:14 -0500
Subject: [Mailman-Developers] rmlist bug?
Message-ID: <20000614003114.A7685@smack.uchicago.edu>

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Sorry if this has come up before; I didn't see it.

rmlist has what would appear to be a bug: it doesn't care where you
keep your lists, but the Mailman configuration allows you to keep them
outside the tree that Mailman itself lives in.  This patch against
current CVS repairs.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rmlist.patch"

Index: bin/rmlist
===================================================================
RCS file: /cvsroot/mailman/mailman/bin/rmlist,v
retrieving revision 1.12
diff -u -r1.12 rmlist
--- bin/rmlist	2000/03/21 06:26:18	1.12
+++ bin/rmlist	2000/06/14 05:27:28
@@ -40,6 +40,8 @@
 import getopt
 import paths
 
+from Mailman import Defaults
+
 def usage(status, msg=''):
     print __doc__ % globals()
     if msg:
@@ -93,7 +95,7 @@
     REMOVABLES.append(('locks/%s.lock', 'lock file'))
 
     for dirtmpl, msg in REMOVABLES:
-        dir = os.path.join(paths.prefix, dirtmpl % listname)
+        dir = os.path.join(Defaults.DATA_PREFIX, dirtmpl % listname)
         remove_it(listname, dir, msg)
 
 

--7JfCtLOvnd9MIVvH--


From hniksic@iskon.hr  Wed Jun 14 09:28:22 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 10:28:22 +0200
Subject: [Mailman-Developers] Mailman version
Message-ID: <dpaegowtsp.fsf@mraz.iskon.hr>

Hi!

After a long period of pondering, my company is scheduling the move
from majordomo to mailman for mailing list management.

A quick question: I notice that mailman is currently in 2.0-beta, and
that beta2 was released in April.  How stable is that beta?  I
wouldn't like the majordomo->mailman migration pain to be followed by
a 1.x->2.0 upgrade pain.

What do the developers recommend?


From Nigel.Metheringham@VData.co.uk  Wed Jun 14 09:45:28 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Wed, 14 Jun 2000 09:45:28 +0100
Subject: [Mailman-Developers] Mailman version
In-Reply-To: Message from Hrvoje Niksic <hniksic@iskon.hr>
 of "14 Jun 2000 10:28:22 +0200." <dpaegowtsp.fsf@mraz.iskon.hr>
Message-ID: <E1328ng-0000ft-00@rioja.localnet>

hniksic@iskon.hr said:
> A quick question: I notice that mailman is currently in 2.0-beta, and
> that beta2 was released in April.  How stable is that beta?  I
> wouldn't like the majordomo->mailman migration pain to be followed by
> a 1.x->2.0 upgrade pain. 

The beta is *very* stable - as far as I can see, although there are a 
few minor bugs that I can think of, specifically:-

  - messages that go through the approval pipeline do not
    get correctly archived.
    Patches are at http://sourceforge.net/patch/download.php?id=100416
    and http://sourceforge.net/patch/download.php?id=100417
    [looks like both are needed]

  - archiving timezone date oddities (only affects weekly archived lists
    in particular timezones).  Theres a one line patch of mine for that
    somewhere on the dev list and also in the www.list.org bug db

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From Harald.Meland@usit.uio.no  Wed Jun 14 13:10:18 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 14 Jun 2000 14:10:18 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: bwarsaw@python.org's message of "Wed, 14 Jun 2000 00:57:48 -0400 (EDT)"
References: <Pine.LNX.4.21.0005181447140.6340-100000@dogpound.vnet.net>
 <d6dk8grfudv.fsf@octarine.uio.no>
 <14646.55931.299948.492757@anthem.python.org>
 <d6d4s79du5t.fsf@octarine.uio.no>
 <14663.4300.188254.867225@anthem.concentric.net>
Message-ID: <d6dhfawpiol.fsf@octarine.uio.no>

[Barry A. Warsaw]

> I think __break() is fundamentally broken.  Actually, I think
> breaking locks gets us into all kinds of problems.

I completely agree.  However:

> But there's the trade-off of deadlocking the whole system for
> something we haven't thought about.

That is one rather humongously-sized "but".  [ Do not read the
previous sentence out loud to your wife/girlfriend ;) ]

> One approach might be to never break locks implicitly, but have
> qrunner (which now runs every minute) check for long-dead locks and
> send warning emails to the site admin.  A simple rm should clear up
> the problem.

My gut feeling says that this would be too cumbersome.  The problem
with breaking a lock is that it introduces race conditions; and by
having human admins break the lock "by hand", all you really gain is a
reduced probability that two or more admins will (try to) break the
same lock (nearly) simultaneously -- meaning that all but the first
admin really break non-stale locks.

As long as we do locking by use of the file system, I think there
_has_ to be some way to break stale locks.  Furthermore, I don't think
it's possible to make the method for breaking these locks *completely*
free of race conditions.

I think that our focus should therefore be on reducing the
probabilities of

  a) the occurance of stale locks and
  b) multiple lock breakages in quick succession, as this could
     possibly lead to fresh, non-stale locks being broken.

I would vastly prefer reducing the probability of breaking non-stale
lock by automated means, e.g. by introducing (relatively) large
sleep()s in appropriate places.



Oh, hang on: I just realized that I might have misunderstood what
you're suggesting.  If you meant that there should only be *one*
process which is allowed to break locks, then I agree.  

Of course, there is a catch-22 inside that: The way of ensuring that
there is only *one* instance of that process running, is to do obtain
some lock...

> As an interim approach, I'm just cranking up the qrunner and list
> lock lifetimes to really big numbers (like 10 hours and 5 hours
> respectively).

Ouch.  I do agree with you, though.

> All this is just whacked anyway.  What we really need is a
> transactional database underneath so we wouldn't need all these
> stupid list locks.  I still believe that's too much work for 2.0,
> but as this beta3 drags on, I'm starting to have doubts.

Ummm, by saying "transactional" you're ruling out mysql, right?  I
think I read somewhere that the lack of "transactions" was the main
thing separating mysql from other DBMSes.

As Mailman is GNU software, I'm wondering which free transactional
DBMS(es) Mailman could (or should :) live on top of.
-- 
Harald


From hniksic@iskon.hr  Wed Jun 14 14:12:12 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 15:12:12 +0200
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
Message-ID: <dpk8fstnir.fsf@mraz.iskon.hr>

How is one supposed to create a mailing list on a different virtual
domain?

For instance, say my company `foo' normally runs mailman on `foo.net'.
Now our `bar' clients need a mailing list on `bar.net', which we also
host (and relay mail for.)

Of course, we could set things up so that mail that arrives to
<LIST@bar.net> be delivered to the right place, but Mailman responses
will still appear coming from foo.net.

Mailman README says that Mailman supports virtual domains.  So how is
one supposed to set them up?

Any help, or pointers to help, will be much appreciated.


From stu@ekins.net  Wed Jun 14 14:56:34 2000
From: stu@ekins.net (Stu Ekins)
Date: Wed, 14 Jun 2000 14:56:34 +0100
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
In-Reply-To: <dpk8fstnir.fsf@mraz.iskon.hr>
Message-ID: <BJEKLFPEBALNOFGGKCJACECDCAAA.stu@ekins.net>

Mailman has an option in the list admin pages, which says something like
"domain name this list prefers". Specify "bar.net" in here, and bob should
be your mother's brother...

-----Original Message-----
From: mailman-developers-admin@python.org
[mailto:mailman-developers-admin@python.org]On Behalf Of Hrvoje Niksic
Sent: 14 June 2000 14:12
To: Mailman Developers
Subject: [Mailman-Developers] Virtual hosts/domains in mailman


How is one supposed to create a mailing list on a different virtual
domain?

<rest snipped>



From bwarsaw@python.org  Wed Jun 14 15:46:09 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 10:46:09 -0400 (EDT)
Subject: [Mailman-Developers] Mailman version
References: <dpaegowtsp.fsf@mraz.iskon.hr>
Message-ID: <14663.39601.308077.84506@anthem.concentric.net>

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

    Hrvoje> After a long period of pondering, my company is scheduling
    Hrvoje> the move from majordomo to mailman for mailing list
    Hrvoje> management.

    Hrvoje> A quick question: I notice that mailman is currently in
    Hrvoje> 2.0-beta, and that beta2 was released in April.  How
    Hrvoje> stable is that beta?  I wouldn't like the
    Hrvoje> majordomo->mailman migration pain to be followed by a
    Hrvoje> 1.x->2.0 upgrade pain.

    Hrvoje> What do the developers recommend?

I don't recommend upgrading to 2.0beta2.  Beta3 should be out RSN.

-Barry


From hniksic@iskon.hr  Wed Jun 14 15:49:02 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 16:49:02 +0200
Subject: [Mailman-Developers] Mailman version
In-Reply-To: bwarsaw@python.org's message of "Wed, 14 Jun 2000 10:46:09 -0400 (EDT)"
References: <dpaegowtsp.fsf@mraz.iskon.hr>
 <14663.39601.308077.84506@anthem.concentric.net>
Message-ID: <dpd7lktj1d.fsf@mraz.iskon.hr>

bwarsaw@python.org (Barry A. Warsaw) writes:

> I don't recommend upgrading to 2.0beta2.

I'm not running Mailman at all right now: the question is not whether
to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
2.0beta3 is out.  Or to install the latest stable 1.x version.


From lm@bitmover.com  Wed Jun 14 15:51:29 2000
From: lm@bitmover.com (Larry McVoy)
Date: Wed, 14 Jun 2000 07:51:29 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: <dpd7lktj1d.fsf@mraz.iskon.hr>
References: <dpaegowtsp.fsf@mraz.iskon.hr> <14663.39601.308077.84506@anthem.concentric.net> <dpd7lktj1d.fsf@mraz.iskon.hr>
Message-ID: <20000614075129.E3397@work.bitmover.com>

1.x is pretty cool; I'm not a developer, JC just dragged me into mailman
and I must say I am very impressed (I believe that I sent JC mail saying
"this is better than BitKeeper" so that should give you some idea of
how much I like it).  

I don't think you can go wrong with using 1.x for now, it's very functional.

On Wed, Jun 14, 2000 at 04:49:02PM +0200, Hrvoje Niksic wrote:
> bwarsaw@python.org (Barry A. Warsaw) writes:
> 
> > I don't recommend upgrading to 2.0beta2.
> 
> I'm not running Mailman at all right now: the question is not whether
> to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
> 2.0beta3 is out.  Or to install the latest stable 1.x version.
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers

-- 
---
Larry McVoy            	   lm@bitmover.com           http://www.bitmover.com/lm 


From chuqui@plaidworks.com  Wed Jun 14 16:30:43 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 08:30:43 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: <dpd7lktj1d.fsf@mraz.iskon.hr>
References: <dpaegowtsp.fsf@mraz.iskon.hr>
 <14663.39601.308077.84506@anthem.concentric.net>
 <dpd7lktj1d.fsf@mraz.iskon.hr>
Message-ID: <p04310103b56d5585f11b@[209.239.169.197]>

At 4:49 PM +0200 6/14/2000, Hrvoje Niksic wrote:

>I'm not running Mailman at all right now: the question is not whether
>to upgrade to 2.0beta2, but whether to install 2.0beta2 or wait until
>2.0beta3 is out.  Or to install the latest stable 1.x version.

Install to the latest CVS versions of not-quite-2.0b3

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From ajohnson@mail.xperts.com  Wed Jun 14 18:06:51 2000
From: ajohnson@mail.xperts.com (Johnson, April)
Date: Wed, 14 Jun 2000 13:06:51 -0400
Subject: [Mailman-Developers] HTML-formatted email
Message-ID: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>

We've done a test implementation of Mailman, but we're really looking for
the list manager to be "happy" with HTML-formatted email. Are there any
patches or add-ons that address this issue? If so, where can we find them?

April Johnson
Xperts, Inc.
(804) 967-0700 x174
http://www.xperts.com
http://www.xperts.org




From chuqui@plaidworks.com  Wed Jun 14 18:10:47 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 10:10:47 -0700
Subject: [Mailman-Developers] HTML-formatted email
In-Reply-To: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>
References: <5B7C00CB140FD4119B4E00508BA54CD5018C2C@mail.xperts.com>
Message-ID: <p04310102b56d6cf0f837@[17.216.27.193]>

At 1:06 PM -0400 6/14/2000, Johnson, April wrote:
>We've done a test implementation of Mailman, but we're really looking for
>the list manager to be "happy" with HTML-formatted email. Are there any
>patches or add-ons that address this issue? If so, where can we find them?

which version of mailman?

Version 2.0b2-3 works fine with MIME, we've been experimenting with 
it heavily. or are you expecting mailman to process email commands 
embedded in HTML?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From claw@kanga.nu  Wed Jun 14 18:38:00 2000
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 14 Jun 2000 10:38:00 -0700
Subject: [Mailman-Developers] Mailman version
In-Reply-To: Message from Larry McVoy <lm@bitmover.com>
 of "Wed, 14 Jun 2000 07:51:29 PDT." <20000614075129.E3397@work.bitmover.com>
References: <dpaegowtsp.fsf@mraz.iskon.hr> <14663.39601.308077.84506@anthem.concentric.net> <dpd7lktj1d.fsf@mraz.iskon.hr>  <20000614075129.E3397@work.bitmover.com>
Message-ID: <12917.961004280@kanga.nu>

On Wed, 14 Jun 2000 07:51:29 -0700 
Larry McVoy <lm@bitmover.com> wrote:

> 1.x is pretty cool; I'm not a developer, JC just dragged me into
> mailman and I must say I am very impressed (I believe that I sent
> JC mail saying "this is better than BitKeeper" so that should give
> you some idea of how much I like it).

Nice to see you here again Larry.

> I don't think you can go wrong with using 1.x for now, it's very
> functional.

I've been playing, very softly, with 2.0*.  My take: 1.1 works, I
like it, I use it.  2.0* works better (eg far better bounce message
parsing) but has a number of fragile corners.  If you never hit
those corners, of course, you'll never care.  OTOH we don't know
where all the corners are yet.  I don't feel that 2.0* has been hit
hard enough to be relied on for a production system as shown by the
rate of reported bugs.

Given that a concern for production systems is that rolling to
versions of installed software is painful, I don't see that going to
2.0* right now is worth it.  In a few weeks/months you are going to
have to upgrade to the full 2.x release anyway, just as you would
from 1.1.  Yes, the delta will be a little smaller, but that's
hardly a big concern when most of the pain centers on rolling the
version in the first place.

For production systems, go with 1.1.  Its not as wonderful as 2.0*,
but it does work, and quite well to boot.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From rob_mm@hotmail.com  Wed Jun 14 20:02:02 2000
From: rob_mm@hotmail.com (Robert mm)
Date: Wed, 14 Jun 2000 15:02:02 EDT
Subject: [Mailman-Developers] integration with other databases?
Message-ID: <20000614190202.16597.qmail@hotmail.com>

Hi,
I originally sent this to the users list, but I think it might be better 
sent to the developers

Please respond to ether rob_mm@hotmail.com or the mailman-users list, as I 
am not part of the developers list.
----
I have just installed mailman on our test intranet.
I was wondering if anyone has tried integrating mailman with other 
information systems?

We use the LDAP standard (kind of a database) to keep track of people and 
groups in our organization.

We have a need for a mail list manager for the purposes of archiving, 
digests, exploding lists, etc... but would like to have the actual lists 
managed from the LDAP side (or at least kept concurrent with).

My Original plan was to simply have a daemon running to periodically extract 
members of groups from the LDAP database and rebuild the lists that mailman 
uses (I thought they would be text files).

However, now that I have installed Mailman I see the lists are kept in the 
binary file format (.db). This makes things much more difficult.

Does anyone have any experience/suggestions in this matter?
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From hniksic@iskon.hr  Wed Jun 14 20:21:05 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 21:21:05 +0200
Subject: [Mailman-Developers] Web interface for creating new mailing lists
Message-ID: <dpem60nk66.fsf@mraz.iskon.hr>

As far as I can see, it seems that there is no interface for creating
on-site mailing lists?  Is that omission intentional, or is it the
case that noone has gotten around to doing it?

What I have in mind is a user/maintainer-friendly web interface that
allows you to open new mailing lists, delete the existing ones, stuff
like that.  It would store its state information somewhere in the
mailman directories, and write out sendmail-(or whatever)-style
aliases to a system file instructed to be read by the MTA -- say
/etc/mail/mailman-aliases.

Do you think such a thing would be worthwhile to add to Mailman if it
does not already exist?  I need to write something like that here at
work, and I wonder if it's possible to leverage the existing Mailman
architectures for things like state files, locks, etc.


From bigdog@dogpound.vnet.net  Wed Jun 14 20:31:10 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Wed, 14 Jun 2000 15:31:10 -0400 (EDT)
Subject: [Mailman-Developers] Web interface for creating new mailing
 lists
In-Reply-To: <dpem60nk66.fsf@mraz.iskon.hr>
Message-ID: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>

On 14 Jun 2000, Hrvoje Niksic wrote:

> What I have in mind is a user/maintainer-friendly web interface that
> allows you to open new mailing lists, delete the existing ones, stuff
> like that.  It would store its state information somewhere in the
> mailman directories, and write out sendmail-(or whatever)-style
> aliases to a system file instructed to be read by the MTA -- say
> /etc/mail/mailman-aliases.

The newlist program could be hacked up to pipe thoes sendmail aliases to a
mailman writeable alias file like you mentioned above..  But the problem I
ran into was getting sendmail to reread thoes aliases.  As far as I could
see, only root could run 'newaliases'.

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Falls don't kill people. It's the deceleration trauma.
----------------------------------------------------------------
Wednesday, June 14, 2000 / 12:58PM



From hniksic@iskon.hr  Wed Jun 14 20:35:24 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 14 Jun 2000 21:35:24 +0200
Subject: [Mailman-Developers] Web interface for creating new mailing lists
In-Reply-To: Matt Davis's message of "Wed, 14 Jun 2000 15:31:10 -0400 (EDT)"
References: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
Message-ID: <dpem60m4xv.fsf@mraz.iskon.hr>

Matt Davis <bigdog@dogpound.vnet.net> writes:

> On 14 Jun 2000, Hrvoje Niksic wrote:
> 
> > What I have in mind is a user/maintainer-friendly web interface that
> > allows you to open new mailing lists, delete the existing ones, stuff
> > like that.  It would store its state information somewhere in the
> > mailman directories, and write out sendmail-(or whatever)-style
> > aliases to a system file instructed to be read by the MTA -- say
> > /etc/mail/mailman-aliases.
> 
> The newlist program could be hacked up to pipe thoes sendmail
> aliases to a mailman writeable alias file like you mentioned above..
> But the problem I ran into was getting sendmail to reread thoes
> aliases.  As far as I could see, only root could run 'newaliases'.

On my system we never run `newaliases' because sendmail rebuilds the
aliases database on demand, automatically.

(The support for that will soon be removed from sendmail, but I assume
the same task could be performed by a simple cron job.)


From bwarsaw@python.org  Wed Jun 14 20:46:06 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 14 Jun 2000 15:46:06 -0400 (EDT)
Subject: [Mailman-Developers] Web interface for creating new mailing lists
References: <dpem60nk66.fsf@mraz.iskon.hr>
Message-ID: <14663.57598.1538.417700@anthem.concentric.net>

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

    Hrvoje> As far as I can see, it seems that there is no interface
    Hrvoje> for creating on-site mailing lists?  Is that omission
    Hrvoje> intentional, or is it the case that noone has gotten
    Hrvoje> around to doing it?

The latter.  Mailman, in its deep dark history, had some provision for
that but it was broken at one point in the pre-1.0 era and was never
put back in.  I would definitely like at some point to add stuff like
that back.

-Barry


From smead@amplepower.com  Wed Jun 14 21:35:30 2000
From: smead@amplepower.com (David Smead)
Date: Wed, 14 Jun 2000 13:35:30 -0700 (PDT)
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: <d6dhfawpiol.fsf@octarine.uio.no>
Message-ID: <Pine.LNX.4.10.10006141331310.5254-100000@henry.amplepower.com>

Greetings,

I believe that the mv command is atomic.  Instead of unlinking a lock
file, why not move it? Hope this is helpful.

Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On 14 Jun 2000, Harald Meland wrote:

> [Barry A. Warsaw]
> 
> > I think __break() is fundamentally broken.  Actually, I think
> > breaking locks gets us into all kinds of problems.
> 
> I completely agree.  However:
> 
> > But there's the trade-off of deadlocking the whole system for
> > something we haven't thought about.
> 
> That is one rather humongously-sized "but".  [ Do not read the
> previous sentence out loud to your wife/girlfriend ;) ]
> 
> > One approach might be to never break locks implicitly, but have
> > qrunner (which now runs every minute) check for long-dead locks and
> > send warning emails to the site admin.  A simple rm should clear up
> > the problem.
> 
> My gut feeling says that this would be too cumbersome.  The problem
> with breaking a lock is that it introduces race conditions; and by
> having human admins break the lock "by hand", all you really gain is a
> reduced probability that two or more admins will (try to) break the
> same lock (nearly) simultaneously -- meaning that all but the first
> admin really break non-stale locks.
> 
> As long as we do locking by use of the file system, I think there
> _has_ to be some way to break stale locks.  Furthermore, I don't think
> it's possible to make the method for breaking these locks *completely*
> free of race conditions.
> 
> I think that our focus should therefore be on reducing the
> probabilities of
> 
>   a) the occurance of stale locks and
>   b) multiple lock breakages in quick succession, as this could
>      possibly lead to fresh, non-stale locks being broken.
> 
> I would vastly prefer reducing the probability of breaking non-stale
> lock by automated means, e.g. by introducing (relatively) large
> sleep()s in appropriate places.
> 
> 
> 
> Oh, hang on: I just realized that I might have misunderstood what
> you're suggesting.  If you meant that there should only be *one*
> process which is allowed to break locks, then I agree.  
> 
> Of course, there is a catch-22 inside that: The way of ensuring that
> there is only *one* instance of that process running, is to do obtain
> some lock...
> 
> > As an interim approach, I'm just cranking up the qrunner and list
> > lock lifetimes to really big numbers (like 10 hours and 5 hours
> > respectively).
> 
> Ouch.  I do agree with you, though.
> 
> > All this is just whacked anyway.  What we really need is a
> > transactional database underneath so we wouldn't need all these
> > stupid list locks.  I still believe that's too much work for 2.0,
> > but as this beta3 drags on, I'm starting to have doubts.
> 
> Ummm, by saying "transactional" you're ruling out mysql, right?  I
> think I read somewhere that the lack of "transactions" was the main
> thing separating mysql from other DBMSes.
> 
> As Mailman is GNU software, I'm wondering which free transactional
> DBMS(es) Mailman could (or should :) live on top of.
> -- 
> Harald
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From claw@kanga.nu  Thu Jun 15 01:22:42 2000
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 14 Jun 2000 17:22:42 -0700
Subject: [Mailman-Developers] Web interface for creating new mailing lists
In-Reply-To: Message from Matt Davis <bigdog@dogpound.vnet.net>
 of "Wed, 14 Jun 2000 15:31:10 EDT." <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
References: <Pine.LNX.4.21.0006141526380.1227-100000@dogpound.vnet.net>
Message-ID: <20581.961028562@kanga.nu>

On Wed, 14 Jun 2000 15:31:10 -0400 (EDT) 
Matt Davis <bigdog@dogpound.vnet.net> wrote:

> The newlist program could be hacked up to pipe thoes sendmail
> aliases to a mailman writeable alias file like you mentioned
> above..  But the problem I ran into was getting sendmail to reread
> thoes aliases.  As far as I could see, only root could run
> 'newaliases'.

Much as I think the best route is to take sendmail out back and
shoot it like the mangy rabid cur it is, a simple cronjob that
watched the timestamp of the alias file and ran newaliases as
appropriate would do the job.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 15 01:30:11 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Wed, 14 Jun 2000 17:30:11 -0700 (PDT)
Subject: [Mailman-Developers] Web interface for creating new mailing lists
Message-ID: <200006150029.RAA00807@utopia.west.sun.com>

> Much as I think the best route is to take sendmail out back and
> shoot it like the mangy rabid cur it is, a simple cronjob that
> watched the timestamp of the alias file and ran newaliases as
> appropriate would do the job.

s/cronjob/daemon (or background shell process with sleep, whatever)/



From Harald.Meland@usit.uio.no  Thu Jun 15 01:56:41 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 15 Jun 2000 02:56:41 +0200
Subject: [Mailman-Developers] problem with view other subscriptions..
In-Reply-To: David Smead's message of "Wed, 14 Jun 2000 13:35:30 -0700 (PDT)"
References: <Pine.LNX.4.10.10006141331310.5254-100000@henry.amplepower.com>
Message-ID: <d6dzoonoj7a.fsf@octarine.uio.no>

[David Smead]

> Greetings,
> 
> I believe that the mv command is atomic.  Instead of unlinking a
> lock file, why not move it?

Both unlink(2) and rename(2) are (supposed to be) atomic system calls,
AFAIK.  The problem occurs whenever there is a stale lock, and the
need to break that lock is raised.

An example of how the race condition can manifest itself might help
explain:


Say that two processes, A and B, want lock L.  They both discover that
the lock is so old that it is stale.

First, process A breaks the lock.  Whether this is done by means of
unlink(2) or rename(2) is not relevant, the point is that after the
breaking there is no longer any file occupying the lockfile's position
in the file system.

Next, process A tries to get the lock, and succeeds.

Now the problem arises: Process B still thinks the lock is stale, and
breaks it.  Process A has lock attempt has already returned
successfully, so process A still thinks it is the lock owner.

Finally, process B tries to get the lock -- and succeeds.

Now, both processes believes they own the lock.  We should aim at
reducing the probability of such situations.


One thing which would (slightly) reduce the risk of race condition is
to put a long(ish) delay right after a process has broken a lock, so
that the process doing the lock breaking is less likely to obtain the
lock.  The idea is that such a delay would cause B's breaking attempt
to occur before A retries lock retrieval.

However, this would only help with race conditions involving only two
processes -- with e.g. three processes, process A could break, process
B get the lock, and then process C could break B's fresh lock.


Thanks for trying, though -- I would love it if we were able to come
up with a failsafe filsystem-based locking scheme (with support for
breaking stale locks).
-- 
Harald


From mentor@alb-net.com  Thu Jun 15 05:07:25 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:07:25 -0400 (EDT)
Subject: [Mailman-Developers] password a MUST?!
Message-ID: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>

Hello,

Isn't it more user friendly and a nice feature to have the password as
optional when users try to subscribe to a list? 

If they supply the password, ok, use it. Otherwise, let the mailman 
generate a password for them as it does when e-mail addresses are
subscribed by the list owner through the web page.

The optional password feature will be nice when embedding the subscription
box on a different page that the default one. 

Just a thought......

later,
mentor



From chuqui@plaidworks.com  Thu Jun 15 05:16:43 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 21:16:43 -0700
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>
References: <Pine.GSO.4.21.0006142349090.779-100000@alb-net.com>
Message-ID: <p04320400b56e089cf021@[209.239.169.197]>

At 12:07 AM -0400 6/15/2000, Mentor Cana wrote:
>Hello,
>
>Isn't it more user friendly and a nice feature to have the password as
>optional when users try to subscribe to a list?

You need some way to authenticate users on the web site. Otherwise, 
anyone with your emailaddress can raise havoc on you.

But that doesn't mean the password needs to be set immediately, 
Simple leave it undefined until a user needs it, and then 
auto-generate it and mail it to them on request. That way, until the 
user needs it, they aren't confused by it....

But if you're going to do your admin via web, you need some sort of 
server-generated dongle to validate the user has access to the email 
address.

Unfortunately, you can't trust the universe.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mentor@alb-net.com  Thu Jun 15 05:24:44 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:24:44 -0400 (EDT)
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <p04320400b56e089cf021@[209.239.169.197]>
Message-ID: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>

On Wed, 14 Jun 2000, at 21:16, Chuq Von Rospach wrote:
> At 12:07 AM -0400 6/15/2000, Mentor Cana wrote:
> >Hello,
> >
> >Isn't it more user friendly and a nice feature to have the password as
> >optional when users try to subscribe to a list?
> 
> You need some way to authenticate users on the web site. Otherwise, 
> anyone with your emailaddress can raise havoc on you.

Isn't this independent of the fact if password is required on subscription
or not? What I'm saying is not to eliminate the password option all
together, just suggestion that password should not be required if not
supplied and mailman generates the password instead. 

The havoc is control by the list setting that should require confirmation
on subscription which is not dependent on he passwords.
 
later,
Mentor



From chuqui@plaidworks.com  Thu Jun 15 05:28:30 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 14 Jun 2000 21:28:30 -0700
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>
References: <Pine.GSO.4.21.0006150021380.19525-100000@alb-net.com>
Message-ID: <p04320401b56e0b9da4f0@[209.239.169.197]>

At 12:24 AM -0400 6/15/2000, Mentor Cana wrote:

>Isn't this independent of the fact if password is required on subscription
>or not?

Yes.

>  What I'm saying is not to eliminate the password option all
>together, just suggestion that password should not be required if not
>supplied and mailman generates the password instead.

Could be done. At this point, I don't think I'd consider it a high 
priority for 2.0. But it'd be nice to have down the road.

>The havoc is control by the list setting that should require confirmation
>on subscription which is not dependent on he passwords.

No, actually, both are independent but control different aspects of attack.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mentor@alb-net.com  Thu Jun 15 05:33:30 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Thu, 15 Jun 2000 00:33:30 -0400 (EDT)
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: <p04320401b56e0b9da4f0@[209.239.169.197]>
Message-ID: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>

On Wed, 14 Jun 2000, at 21:28, Chuq Von Rospach wrote:
> >  What I'm saying is not to eliminate the password option all
> >together, just suggestion that password should not be required if not
> >supplied and mailman generates the password instead.
> 
> Could be done. At this point, I don't think I'd consider it a high 
> priority for 2.0. But it'd be nice to have down the road.

The following patch was posted on this list few days ago. Isn't this doing
the trick?

later,
mentor
--
Mailman/Cgi/subscribe.py
diff -r1.25 subscribe.py
139,141c139,140
<         error = 1
<         results = (results +
<                    "You must supply a valid password, and confirm  it.<br>")
---
>         pw  = Utils.MakeRandomPassword()
>         pwc = pw



From fil@bok.net  Thu Jun 15 09:04:04 2000
From: fil@bok.net (Fil)
Date: Thu, 15 Jun 2000 10:04:04 +0200
Subject: [Mailman-Developers] password a MUST?!
In-Reply-To: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>; from mentor@alb-net.com on Thu, Jun 15, 2000 at 12:33:30AM -0400
References: <p04320401b56e0b9da4f0@[209.239.169.197]> <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>
Message-ID: <20000615100404.A21990@orwell.bok.net>

* Mentor Cana (mentor@alb-net.com) écrivait :
> Mailman/Cgi/subscribe.py
> diff -r1.25 subscribe.py
> 139,141c139,140
> <         error = 1
> <         results = (results +
> <                    "You must supply a valid password, and confirm  it.<br>")
                                                                     **

** not so sure about the two spaces here, but yes this patch does the trick,
has been working for me for quite a long time, and I don't see a downside in
letting mm choose the password for the user.



From Harald.Meland@usit.uio.no  Thu Jun 15 10:14:22 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 15 Jun 2000 11:14:22 +0200
Subject: [Mailman-Users] Re: [Mailman-Developers] password a MUST?!
In-Reply-To: Mentor Cana's message of "Thu, 15 Jun 2000 00:33:30 -0400 (EDT)"
References: <Pine.GSO.4.21.0006150032010.19525-100000@alb-net.com>
Message-ID: <d6dr99zz4pd.fsf@octarine.uio.no>

[Mentor Cana]

> On Wed, 14 Jun 2000, at 21:28, Chuq Von Rospach wrote:
> > >  What I'm saying is not to eliminate the password option all
> > >together, just suggestion that password should not be required if not
> > >supplied and mailman generates the password instead.
> > 
> > Could be done. At this point, I don't think I'd consider it a high 
> > priority for 2.0. But it'd be nice to have down the road.
> 
> The following patch was posted on this list few days ago. Isn't this doing
> the trick?

Not quite, I think.  I, for one, don't want to allow my users to
subscribe with random passwords -- explaining the Mailman
password-and-user stuff we have in place here is confusing enough as
it is.

Here's a revised version of the patch (please use "diff -u" or "diff
-c" when posting patches -- I believe Barry prefers the latter, while
I myself prefer the former):

Index: Mailman/Defaults.py.in
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Defaults.py.in,v
retrieving revision 1.101
diff -u -r1.101 Defaults.py.in
--- Mailman/Defaults.py.in      2000/05/04 22:44:28     1.101
+++ Mailman/Defaults.py.in      2000/06/15 08:32:49
@@ -222,6 +222,10 @@
 DEFAULT_SUBSCRIBE_POLICY = 1
 # does this site allow completely unchecked subscriptions?
 ALLOW_OPEN_SUBSCRIBE = 0
+# does this site allow user to subscribe without specifying what their
+# member password should be?  If set to true, Mailman will generate
+# random passwords for such users.
+ALLOW_RANDOMPWD_SUBSCRIBE = 0
 
 # Private_roster == 0: anyone can see, 1: members only, 2: admin only.
 DEFAULT_PRIVATE_ROSTER = 0
Index: Mailman/Cgi/subscribe.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v
retrieving revision 1.24
diff -u -r1.24 subscribe.py
--- Mailman/Cgi/subscribe.py    2000/04/04 23:38:25     1.24
+++ Mailman/Cgi/subscribe.py    2000/06/15 09:13:14
@@ -135,9 +135,20 @@
         results = results + "You must not subscribe a list to itself!<br>"
 
     if not form.has_key("pw") or not form.has_key("pw-conf"):
-        error = 1
-        results = (results +
-                   "You must supply a valid password, and confirm it.<br>")
+        if mm_cfg.ALLOW_RANDOMPWD_SUBSCRIBE:
+            # If the user has supplied a password, but not confirmed it,
+            # we use the supplied password anyway.
+            if form.has_key("pw"):
+                pw = form["pw"].value
+            # Otherwise generate a random password.
+            else:
+                pw = Utils.MakeRandomPassword()
+            # Auto-confirm this password
+            pwc = pw
+        else:
+            error = 1
+            results = (results +
+                       "You must supply a valid password, and confirm it.<br>")
     else:
         pw  = form["pw"].value
         pwc = form["pw-conf"].value


The patch has not (yet) been tested, please report back any failures
or successes.

If it works out OK, and no-one objects strongly, I'll consider
committing this before 2.0 (I'll be away next week (attending USENIX
2000), which should leave ample time to voice any objections :).
-- 
Harald


From Nigel.Metheringham@VData.co.uk  Fri Jun 16 16:24:01 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 16 Jun 2000 16:24:01 +0100
Subject: [Mailman-Developers] Mailman home location nowadays...
Message-ID: <E132xyT-0000hL-00@rioja.localnet>

Mailman seems to be spreading somewhat...  currently there seems to be:-

  http://www.list.org/
	- general info, FAQs, link to jitterbug database, current source

  http://www.gnu.org/software/mailman/mailman.html
	- quoted as the canonical source, older source (currently offline)

  http://sourceforge.net/project/?group_id=103
	- developer stuff, patches, bug db, release sources set, cvs

  http://mailman.sourceforge.net/
	[potential.... sourceforge is currently suffering "issues"]


Barry, where is the best place for developer type activity now - 
patches/issues to list, into sourceforge, into jitterbug, or something 
else?
[obviously to all rules there will be exceptions - security related 
stuff might be best straight to you so it can be fixed before 
publicised, patches that are concepts for comments are prolly best to 
the list]

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From bwarsaw@python.org  Fri Jun 16 17:19:22 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 16 Jun 2000 12:19:22 -0400 (EDT)
Subject: [Mailman-Developers] Mailman home location nowadays...
References: <E132xyT-0000hL-00@rioja.localnet>
Message-ID: <14666.21386.675707.199924@anthem.concentric.net>

>>>>> "NM" == Nigel Metheringham <Nigel.Metheringham@VData.co.uk> writes:

    NM> Mailman seems to be spreading somewhat...  currently there
    NM> seems to be:-

    NM>   http://www.list.org/ - general info, FAQs, link to jitterbug
    NM> database, current source

    NM>   http://www.gnu.org/software/mailman/mailman.html - quoted as
    NM> the canonical source, older source (currently offline)

Seems to work for me, and the ftp site has 2.0b2.

I was thinking about using list.org to house a lot more information
about Mailman, including eventually manuals, API's, and perhaps a more
elaborate site.  I don't know if that would work on gnu.org so I was
thinking that that would just be a very brief intro.  RMS may want
gnu.org to be the primary site though, but I'll only do that if I can
have the creative control I want.

    |   http://sourceforge.net/project/?group_id=103
    | 	- developer stuff, patches, bug db, release sources set, cvs

I'd like to migrate everything off of python.org except the mailing
lists (and maybe one day those too).  Jitterbug blows, and SF's
project management stuff has other problems, but I think it's the
right long term solution.  At some point I plan on turning of the
Jitterbug stuff and just pointing everyone to SF.

    |   http://mailman.sourceforge.net/
    | 	[potential.... sourceforge is currently suffering "issues"]

Yeah, I just tried that, wassup with it?

Ideally, mailman.sourceforge.net, gnu.org/..., and list.org would be
identical copies of the same web pages and ftp.  Think of them as
mirrors.

    NM> Barry, where is the best place for developer type activity now
    NM> - patches/issues to list, into sourceforge, into jitterbug, or
    NM> something else?  [obviously to all rules there will be
    NM> exceptions - security related stuff might be best straight to
    NM> you so it can be fixed before publicised, patches that are
    NM> concepts for comments are prolly best to the list]

Yup.  Let's try to start using SF to track stuff, because while it has
problems, it's better than Jitterbug.  For really important stuff, use
mailman-developers or mailman-cabal (this reaches just the core
developers).  I haven't had time to read mailman-users in a long time,
so I really appreciate when people forward the important stuff to the
dev list.

-Barry


From claw@kanga.nu  Fri Jun 16 18:57:35 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 16 Jun 2000 10:57:35 -0700
Subject: [Mailman-Developers] Migration to sourceforge?
In-Reply-To: Message from "Bradley M. Kuhn" <bkuhn@gnu.org>
 of "Fri, 16 Jun 2000 13:26:03 EDT." <20000616132603.T22088@ebb.org>
References: <20000616132603.T22088@ebb.org>
Message-ID: <25908.961178255@kanga.nu>

On Fri, 16 Jun 2000 13:26:03 -0400 
Bradley M Kuhn <bkuhn@gnu.org> wrote:

> SourceForge is currently (I am trying to change their minds, but
> it's an uphill battle) somewhat unfriendly to free software
> developers, as they consistently favor the term "open source" over
> "free software".

I know the people at SourceForge (I used to work at VA).  This is
not going to happen, and not only because ESR is on VA's board.  VA
falls solidly on ESR's side of the Open/Free debate.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Fri Jun 16 19:21:34 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 16 Jun 2000 11:21:34 -0700
Subject: [Mailman-Developers] Migration to sourceforge?
In-Reply-To: Message from "Bradley M. Kuhn" <bkuhn@gnu.org>
 of "Fri, 16 Jun 2000 14:06:40 EDT." <20000616140640.Y22088@ebb.org>
References: <20000616132603.T22088@ebb.org> <bkuhn@gnu.org> <25908.961178255@kanga.nu>  <20000616140640.Y22088@ebb.org>
Message-ID: <26474.961179694@kanga.nu>

On Fri, 16 Jun 2000 14:06:40 -0400 
Bradley M Kuhn <bkuhn@gnu.org> wrote:

> I have been told that VA Linux doesn't dictate policy to
> SourceForge---they own it, but they don't seem to exert full
> control over it, giving the SourceForge developers some freedom to
> make these sorts of decisions.

SF is paid for out of VA's Marketting dept.  This explains many
things.

>      "We could really get a lot of use out of sourceforge for GNU
> mailman.  However, since GNU mailman is a free software project
> but not an open source project, it doesn't make sense to host it
> there the way the site stands, because it only reflects an
> affiliation with open source, and free software seems to be
> inadvertantly omitted.  Would you mention Free Software and Open
> Source equally on SourceForge, so we can host GNU mailman there?"

Ahh, this is different than I first understood.  Drop an email to
this effect to Tony (heads the SF project, forget email address) at
VA and CC it to Brian Biles (bbiles@valinux.com) and you should get
a good response.  

> Don Marti has been particularly sympathetic, but seems to need to
> be convinced a little bit more to make the change.

While Don works at VA, he really isn't involved in SF and so has
little direct say.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From mentor@alb-net.com  Fri Jun 16 22:24:42 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Fri, 16 Jun 2000 17:24:42 -0400 (EDT)
Subject: [Mailman-Developers] editing messages on hold donesn't work
Message-ID: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>

I don't remember if modifying the messages for approval was supposed to be
a feature yet or not.

Anyways, I just tried modifying the message body and then approved the
message and the changes were lost. The messages was distributed as it
came...

later,
Mentor



From bwarsaw@python.org  Fri Jun 16 22:39:10 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 16 Jun 2000 17:39:10 -0400 (EDT)
Subject: [Mailman-Developers] editing messages on hold donesn't work
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>
Message-ID: <14666.40574.479937.533421@anthem.concentric.net>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> I don't remember if modifying the messages for approval was
    MC> supposed to be a feature yet or not.

Not.


From dgc@uchicago.edu  Fri Jun 16 22:43:04 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 16 Jun 2000 16:43:04 -0500
Subject: [Mailman-Developers] Re: editing messages on hold donesn't work
In-Reply-To: <14666.40574.479937.533421@anthem.concentric.net>; from bwarsaw@python.org on Fri, Jun 16, 2000 at 05:39:10PM -0400
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com> <14666.40574.479937.533421@anthem.concentric.net>
Message-ID: <20000616164304.Q13782@smack.uchicago.edu>

On 2000.06.16, in <14666.40574.479937.533421@anthem.concentric.net>,
	"Barry A. Warsaw" <bwarsaw@python.org> wrote:
> 
> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:
> 
>     MC> I don't remember if modifying the messages for approval was
>     MC> supposed to be a feature yet or not.
> 
> Not.

Now or ever?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@python.org  Sat Jun 17 06:40:52 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Sat, 17 Jun 2000 01:40:52 -0400 (EDT)
Subject: [Mailman-Developers] Re: editing messages on hold donesn't work
References: <Pine.GSO.4.21.0006161722140.22345-100000@alb-net.com>
 <14666.40574.479937.533421@anthem.concentric.net>
 <20000616164304.Q13782@smack.uchicago.edu>
Message-ID: <14667.3940.630979.158550@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

> >>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:
> 
>     MC> I don't remember if modifying the messages for approval was
>     MC> supposed to be a feature yet or not.
> 
> Not.

    DC> Now or ever?

Never say never. :)  It would be a useful feature to have.


From mentor@alb-net.com  Sun Jun 18 03:40:57 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Sat, 17 Jun 2000 22:40:57 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
Message-ID: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>

TypeError: not enough arguments; expected 7, got 4

---
Jun 17 21:44:25 2000 admin(20600): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(20600): [----- Mailman Version: 2.0beta3 -----]
admin(20600): [----- Traceback ------]
admin(20600): Traceback (innermost last):
admin(20600):   File "/opt/home/mailman/scripts/driver", line 95, in run_main
admin(20600):     main()
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 122, in main
admin(20600):     PrintRequests(mlist, doc, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
admin(20600):     PrintPostRequest(mlist, id, info, total, count, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
admin(20600):     mlist.HandleRequest(id, 2, None)
admin(20600): TypeError: not enough arguments; expected 7, got 4
admin(20600): [----- Python Information -----]
admin(20600): sys.version    = 1.5.2 (#6, Jan  5 2000, 13:41:49)  [GCC 2.95.2 19991024 (release)]
admin(20600): sys.executable = /usr/local/bin/python
admin(20600): sys.prefix     = /usr/local
admin(20600): sys.exec_prefix= /usr/local
admin(20600): sys.path       = /usr/local
admin(20600): sys.platform   = sunos5
admin(20600): [----- Environment Variables -----]
admin(20600): 	DOCUMENT_ROOT: /opt/i386/html
admin(20600): 	SERVER_ADDR: 205.216.244.65
admin(20600): 	HTTP_ACCEPT_ENCODING: gzip, deflate
admin(20600): 	REMOTE_HOST: spider-tm011.proxy.aol.com
admin(20600): 	CONTENT_TYPE: application/x-www-form-urlencoded
admin(20600): 	PATH_TRANSLATED: /opt/i386/html/alb-club
admin(20600): 	SERVER_SOFTWARE: Apache/1.3.12 (Unix) mod_ssl/2.6.0 OpenSSL/0.9.4
admin(20600): 	GATEWAY_INTERFACE: CGI/1.1
admin(20600): 	HTTP_ACCEPT_LANGUAGE: en-us
admin(20600): 	REMOTE_ADDR: 152.163.197.46
admin(20600): 	SERVER_PORT: 80
admin(20600): 	TZ: US/Eastern
admin(20600): 	HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 4.01; AOL 5.0; Windows 98)
admin(20600): 	HTTP_ACCEPT: application/msword, application/x-comet, */*
admin(20600): 	REQUEST_URI: /mailman/admindb/alb-club
admin(20600): 	LD_LIBRARY_PATH: /opt/i386/lib
admin(20600): 	PATH: /usr/sbin:/usr/bin:/bin:/usr/bin:/usr/ucb:/usr/ccs/bin/:/opt/i386/bin:/usr/sbin:/opt/i386/bin/include:/etc:/usr/local/bin:/opt/i386/Perl/bin:/opt/i386/lib:/etc/lib
admin(20600): 	QUERY_STRING: 
admin(20600): 	SERVER_PROTOCOL: HTTP/1.0
admin(20600): 	CONTENT_LENGTH: 15
admin(20600): 	HTTP_HOST: www.alb-net.com
admin(20600): 	REQUEST_METHOD: POST
admin(20600): 	SERVER_SIGNATURE: <ADDRESS>Apache/1.3.12 Server at www.alb-net.com Port 80</ADDRESS>

admin(20600): 	SCRIPT_NAME: /mailman/admindb
admin(20600): 	SERVER_ADMIN: staff@alb-net.com
admin(20600): 	SCRIPT_FILENAME: /opt/home/mailman/cgi-bin/admindb
admin(20600): 	PYTHONPATH: /opt/home/mailman
admin(20600): 	PATH_INFO: /alb-club
admin(20600): 	HTTP_REFERER: http://www.alb-net.com/mailman/admindb/alb-club
admin(20600): 	HTTP_PRAGMA: No-Cache
admin(20600): 	SERVER_NAME: www.alb-net.com
admin(20600): 	REMOTE_PORT: 43440



From bigdog@dogpound.vnet.net  Sun Jun 18 04:03:24 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Sat, 17 Jun 2000 23:03:24 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
In-Reply-To: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
Message-ID: <Pine.LNX.4.21.0006172301570.27164-100000@dogpound.vnet.net>

On Sat, 17 Jun 2000, Mentor Cana wrote:

> TypeError: not enough arguments; expected 7, got 4

It might help if you tell us a bit more about what you were doing at hte
time you got this problem.  What did you click?  What page was it
from? What were you doing at the time?  What color were your socks when
this happened?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Drive C: Error, (A)bort (R)etry (I)gnore (K)ick (S)cream
----------------------------------------------------------------
Saturday, June 17, 2000 / 11:01PM





From mentor@alb-net.com  Sun Jun 18 04:14:47 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Sat, 17 Jun 2000 23:14:47 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS (fwd)
Message-ID: <Pine.GSO.4.21.0006172311240.20851-100000@alb-net.com>

Sorry for not adding the additional line of explanation.

It happened after hitting "Tend to pending administrative requests."
The page shows the error below.

The list in question has more then 10 pending approval (looking at data/
directory). 

thanks,
mentor

---------- Forwarded message ----------
Date: Sat, 17 Jun 2000 22:40:57 -0400 (EDT)
From: Mentor Cana <mentor@alb-net.com>
To: mailman-developers@python.org
Cc: mailman-users@python.org
Subject: [Mailman-Developers] a bug with the most recent CVS


TypeError: not enough arguments; expected 7, got 4

---
Jun 17 21:44:25 2000 admin(20600): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(20600): [----- Mailman Version: 2.0beta3 -----]
admin(20600): [----- Traceback ------]
admin(20600): Traceback (innermost last):
admin(20600):   File "/opt/home/mailman/scripts/driver", line 95, in run_main
admin(20600):     main()
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 122, in main
admin(20600):     PrintRequests(mlist, doc, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
admin(20600):     PrintPostRequest(mlist, id, info, total, count, form)
admin(20600):   File "/opt/home/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
admin(20600):     mlist.HandleRequest(id, 2, None)
admin(20600): TypeError: not enough arguments; expected 7, got 4
admin(20600): [----- Python Information -----]
admin(20600): sys.version    = 1.5.2 (#6, Jan  5 2000, 13:41:49)  [GCC 2.95.2 19991024 (release)]
admin(20600): sys.executable = /usr/local/bin/python
admin(20600): sys.prefix     = /usr/local
admin(20600): sys.exec_prefix= /usr/local
admin(20600): sys.path       = /usr/local
admin(20600): sys.platform   = sunos5
admin(20600): [----- Environment Variables -----]
admin(20600): 	DOCUMENT_ROOT: /opt/i386/html
admin(20600): 	SERVER_ADDR: 205.216.244.65
admin(20600): 	HTTP_ACCEPT_ENCODING: gzip, deflate
admin(20600): 	REMOTE_HOST: spider-tm011.proxy.aol.com
admin(20600): 	CONTENT_TYPE: application/x-www-form-urlencoded
admin(20600): 	PATH_TRANSLATED: /opt/i386/html/alb-club
admin(20600): 	SERVER_SOFTWARE: Apache/1.3.12 (Unix) mod_ssl/2.6.0 OpenSSL/0.9.4
admin(20600): 	GATEWAY_INTERFACE: CGI/1.1
admin(20600): 	HTTP_ACCEPT_LANGUAGE: en-us
admin(20600): 	REMOTE_ADDR: 152.163.197.46
admin(20600): 	SERVER_PORT: 80
admin(20600): 	TZ: US/Eastern
admin(20600): 	HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 4.01; AOL 5.0; Windows 98)
admin(20600): 	HTTP_ACCEPT: application/msword, application/x-comet, */*
admin(20600): 	REQUEST_URI: /mailman/admindb/alb-club
admin(20600): 	LD_LIBRARY_PATH: /opt/i386/lib
admin(20600): 	PATH: /usr/sbin:/usr/bin:/bin:/usr/bin:/usr/ucb:/usr/ccs/bin/:/opt/i386/bin:/usr/sbin:/opt/i386/bin/include:/etc:/usr/local/bin:/opt/i386/Perl/bin:/opt/i386/lib:/etc/lib
admin(20600): 	QUERY_STRING: 
admin(20600): 	SERVER_PROTOCOL: HTTP/1.0
admin(20600): 	CONTENT_LENGTH: 15
admin(20600): 	HTTP_HOST: www.alb-net.com
admin(20600): 	REQUEST_METHOD: POST
admin(20600): 	SERVER_SIGNATURE: <ADDRESS>Apache/1.3.12 Server at www.alb-net.com Port 80</ADDRESS>

admin(20600): 	SCRIPT_NAME: /mailman/admindb
admin(20600): 	SERVER_ADMIN: staff@alb-net.com
admin(20600): 	SCRIPT_FILENAME: /opt/home/mailman/cgi-bin/admindb
admin(20600): 	PYTHONPATH: /opt/home/mailman
admin(20600): 	PATH_INFO: /alb-club
admin(20600): 	HTTP_REFERER: http://www.alb-net.com/mailman/admindb/alb-club
admin(20600): 	HTTP_PRAGMA: No-Cache
admin(20600): 	SERVER_NAME: www.alb-net.com
admin(20600): 	REMOTE_PORT: 43440


_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://www.python.org/mailman/listinfo/mailman-developers




From paul@cr355112-a.slnt1.on.wave.home.com  Sun Jun 18 04:43:43 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Sat, 17 Jun 2000 23:43:43 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <20000618033202.1565D1CE28@dinsdale.python.org>
Message-ID: <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>

I get this message daily:
Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs

Traceback (innermost last):
  File "/usr/local/mailman/cron/checkdbs", line 87, in ?
    main()
  File "/usr/local/mailman/cron/checkdbs", line 52, in main
    text = text + '\n' + pending_requests(mlist)
  File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
    pending.append('    %s %s' % addr, time.ctime(when))
TypeError: not enough arguments for format string

Any idea how to fix it ?
I checked out this file but have no idea how /usr/bin/env python works.

Thanks
___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca



From smead@amplepower.com  Sun Jun 18 06:05:06 2000
From: smead@amplepower.com (David Smead)
Date: Sat, 17 Jun 2000 22:05:06 -0700 (PDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <Pine.LNX.4.10.10006172203440.24223-100000@henry.amplepower.com>

Paul,

I'd suggest parens around the part that supplies the arguments.  That is:
     pending.append('    %s %s' % (addr, time.ctime(when)))


Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Sat, 17 Jun 2000, paul wrote:

> I get this message daily:
> Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs
> 
> Traceback (innermost last):
>   File "/usr/local/mailman/cron/checkdbs", line 87, in ?
>     main()
>   File "/usr/local/mailman/cron/checkdbs", line 52, in main
>     text = text + '\n' + pending_requests(mlist)
>   File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
>     pending.append('    %s %s' % addr, time.ctime(when))
> TypeError: not enough arguments for format string
> 
> Any idea how to fix it ?
> I checked out this file but have no idea how /usr/bin/env python works.
> 
> Thanks
> ___________________________________________________________
> Paul Faure			    paul@engsoc.carleton.ca
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From paul@cr355112-a.slnt1.on.wave.home.com  Sun Jun 18 08:16:17 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Sun, 18 Jun 2000 03:16:17 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
In-Reply-To: <Pine.LNX.4.10.10006172203440.24223-100000@henry.amplepower.com>
Message-ID: <Pine.LNX.4.10.10006180313350.12633-100000@cr355112-a.slnt1.on.wave.home.com>

Thanks, looks like it works.

___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca

On Sat, 17 Jun 2000, David Smead wrote:

> Paul,
> 
> I'd suggest parens around the part that supplies the arguments.  That is:
>      pending.append('    %s %s' % (addr, time.ctime(when)))
> 
> 
> Sincerely,
> 
> David Smead
> http://www.amplepower.com.
> http://www.ampletech.com.
> 
> On Sat, 17 Jun 2000, paul wrote:
> 
> > I get this message daily:
> > Subject: Cron <mailman@stout> /usr/bin/python /usr/local/mailman/cron/checkdbs
> > 
> > Traceback (innermost last):
> >   File "/usr/local/mailman/cron/checkdbs", line 87, in ?
> >     main()
> >   File "/usr/local/mailman/cron/checkdbs", line 52, in main
> >     text = text + '\n' + pending_requests(mlist)
> >   File "/usr/local/mailman/cron/checkdbs", line 72, in pending_requests
> >     pending.append('    %s %s' % addr, time.ctime(when))
> > TypeError: not enough arguments for format string
> > 
> > Any idea how to fix it ?
> > I checked out this file but have no idea how /usr/bin/env python works.
> > 
> > Thanks
> > ___________________________________________________________
> > Paul Faure			    paul@engsoc.carleton.ca
> > 
> > 
> > _______________________________________________
> > Mailman-Developers mailing list
> > Mailman-Developers@python.org
> > http://www.python.org/mailman/listinfo/mailman-developers
> > 
> 



From marc_news@valinux.com  Sun Jun 18 18:02:17 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 18 Jun 2000 10:02:17 -0700
Subject: [Mailman-Developers] mailing list digest broken with mailman CVS
Message-ID: <20000618100217.A7174@moremagic.merlins.org>

Hi,

I had a mm1.1 installation, and upgraded it to mm cvs about 10 days ago.
Apparently, after the  upgrade, the digests were being sent,  but some users
complained of not receiving them.
I subscribed an Email of mine, and indeed, it never got any digests.

Jun 09 08:12:16 2000 (11394) svlug v 97 - 16 msgs, 243 recips (234 mime, 2 text,
7 disabled)
Jun 09 08:12:16 2000 (11394) next svlug digest: #98, post#1
Jun 09 21:47:25 2000 (10756) Officers v 92 - 16 msgs, 0 recips (0 mime, 0 text, 0
 disabled)
Jun 09 21:47:25 2000 (10756) next officers digest: #93, post#1
Jun 10 11:36:02 2000 (26804) svlug v 98 - 21 msgs, 244 recips (235 mime, 2 text,
7 disabled)
Jun 10 11:36:02 2000 (26804) next svlug digest: #99, post#1
Jun 11 08:00:02 2000 (25942) web-team v 21 - 20 msgs, 0 recips (0 mime, 0 text, 0
 disabled)
(...)
Jun 15 00:33:51 2000 (6181) svlug v 106 - 14 msgs, 246 recips (237 mime, 2 text,
7 disabled)
Jun 15 00:33:51 2000 (6181) next svlug digest: #107, post#1
Jun 15 10:56:06 2000 (25111) svlug v 107 - 17 msgs, 246 recips (237 mime, 2 text,
 7 disabled)
Jun 15 10:56:06 2000 (25111) next svlug digest: #108, post#1
Jun 15 19:32:40 2000 (12301) svlug v 108 - 21 msgs, 246 recips (237 mime, 2 text,
 7 disabled)
Jun 15 19:32:40 2000 (12301) next svlug digest: #109, post#1

Then, I upgraded to the CVS code of  the day on June 16th, and digests don't
even  show up  in  mailman/logs/digest  (there are  already  two days  worth
missing)

Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From foner@media.mit.edu  Sun Jun 18 20:01:38 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 15:01:38 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20)
Message-ID: <200006181901.PAA04187@out-of-band.media.mit.edu>

[Please keep me CC'ed on any responses.  Thanks!]

I've just started using Mailman, and, while it's quite a nice little
package, I've already tripped over a number of bugs.  I've listed them
approximately in order from most severe to least severe below; I've
fixed 3 & 7-11 myself, but 1 & 2 require someone with at least a
passing familiarity with Python and Mailman's internals, and of course
they should all wind up in the current source tree.

I also spent a while poking at the Jitterbug interface, and concluded
that it wasn't likely that I'd be able to figure out which category
each individual bug should go into, or that it would save anybody any
time for me to try to stick them in the interface in the first place.
It's also incredibly painful to submit bugs by filling in web forms,
because the editing environment available is so poor.  Having the
forms used by Jitterbug also allow file uploading (when supported by
the browser, which most do) would help, but aren't a complete solution.

(1) Mailman doesn't send error reports to the right place.  Our setup
here has individual workstations, such as foo.media.mit.edu,
masquerade such that their mail headers are rewritten to appear to
come from media.mit.edu (which forwards mail to our main mail-handling
machine, and also has an MX pointing there).  This is usually how
large sets of machines are set up everywhere.  But when I was trying
to configure Mailman (with the wrong compiled-in GID [it wasn't clear
to me whether it was the webserver's GID or sendmail's GID that was
the right one], hence any request caused the wrapper to err), Mailman
evidently went out of its way to attempt to send the error mail to the
individual workstation, e.g., foo.media.mit.edu, and -not- to
media.mit.edu, which is what the From: address in the incoming mail to
Mailman specified and which should be respected in any event---From:
should -always- take precedence over some attempt to divine a better
address.  After all, Mailman cannot possibly have a better idea of
which machine is handling mail for the sender than the sender itself
does.  (This meant, btw, that the error mail simply got wedged in the
sendmail queue of the machine I'm running Mailman on, since individual
workstations here don't listen to SMTP requests.)

(2) Sending a message with no subject and no body to listname-request
causes the blank message to simply arrive at the admin address.  I
contend that it would be far nicer to the users -and- the administrator
if a blank message acted like one with "help" in it.  Otherwise, users
see a black hole (until the admin responds), and admins need to deal
with responding in a way that gets users to ask "help" anyway, most
likely.  It's just a pain all around.

(3) mailman-2.0beta2/Mailman/Archiver/HyperArch.py puts the URL
http://starship.skyport.net/crew/amk/maintained/pipermail.html
into the footer of its page describing the message archives,
but this is a dead link.  (I just commented out the footer entirely.)

(4) Feature request:  Mailman should support a --with-default-url as a
build argument so it can use cnames and/or virtual hosts.  Ditto for
the FQDN of the host.  I had to go in and screw around with various
options files to get this set up correctly after Mailman guessed; why
make the user edit this instead of taking it as an arg?  (Yes, I know
you can change it one list at a time in the admin web interface, but
the default should be right, too.)

(5) The doc says to run "make install" in at least 2 places, but never
says to actually run "make" anywhere.  But you -do- have to do a make :)

(6) Should I be creating mailman-owner or owner-mailman as aliases?
The doc is inconsistent, so I did both.  Is this specific to the MTA?
If so, you should figure it out and document it for common ones.  (I'm
using sendmail 8.9.3.)

(7) Even if the list administrator has disabled monthly password
mailings, templates/convert.txt and templates/subscribeack.txt both
claim that users' passwords will be mailed to them monthly (in fact,
the latter seems to say the same thing twice, in both the last and
penultimate paragraphs).  There should be some way for these templates
to check the current setting for the list, and to fail to include this
text if monthly reminders are turned off.  Mailman/HTMLFormatter.py
appears to make this check correctly, though I'm not positive that it's
generating the page I think it is.  [I find monthly password reminders
absolutely pernicious---after all, if I forget the password, I can
-ask- for it and get an instant response from the server anyway.  And
this way, I don't have the extra traffic, my password doesn't get
sent more than it has to over insecure channels, and very low-volume
lists don't send me mostly password-reminder traffic instead of
blessed silence.]

(8) Three's some bad formatting in the help page returned by sending a
"help" request to listname-request, apparently caused by linewrapping
performed by Utils.wrap (in Mailman/Utils.py)---Utils.wrap defaults to
70 columns wide, but the template text in template/help.txt has lines
longer than this (as do a couple of other calls from elsewhere in the
source code which call Utils.wrap on a fixed string; these are less
objectionable, in general, because the constant text isn't also
indented).  The end result looks pretty awful:

	end or --
	   Stop processing commands (good to do if your mailer
    automatically
	   adds a signature file - it'll save you from a lot of cruft).

should be

	end or --
	   Stop processing commands (good to do if your mailer automatically
	   adds a signature file - it'll save you from a lot of cruft).

and

	    unsubscribe from a different address than the one you
    subscribed
	    from, you may specify it in the 'address' field.

should be

	    unsubscribe from a different address than the one you subscribed
	    from, you may specify it in the 'address' field.

I've fixed this by changing the default in Utils.wrap to 78
characters, which is half-baked but works.

(9) Mailman/Handlers/Hold.py spells administrivia as adbministrivia instead
(there shouldn't be a "b" in that word...)

(10) Mailman/Cgi/admindb.py's default textbox message that says
"Please do *not* post administrative requests to the list!" has a
repeated "the" in the next sentence, so it talks about "the the
request address".  (The two "the"'s are separated by a newline in the
source, which makes this harder to see.)  I removed the repeat and
also changed the first sentence to "Please do not post administrative
requests to the list." (no *, no !) so it seems less like the admin is
yelling at the poor user.

(11) templates/subscribeack.txt puts an extra newline before "You" in
the normal (non-umbrella) case in:

      %(optionsurl)s
    %(umbrella)s
    You can also make such adjustments via email by sending a message to:

which I've fixed simply by doing

      %(optionsurl)s %(umbrella)s
    You can also make such adjustments via email by sending a message to:

but this also requires putting the right number of newlines into the
string in Deliverer.py which generates the string in umbrella.  Since
I can't easily test it, I didn't bother fixing that.

(12) It would be less confusing if the "details" page for various
configuration stuff didn't say "don't change it here---change it on
the previous page" or whatever.  Either make the form active on the
details page, or don't make it a form at all.  This wasn't a problem
for me, but I imagine it will be for others.  (Yes, I understand it's
easier to be able to reuse the code that generates the form this way,
but surely it can't be that hard to modularize.)


From marc_news@valinux.com  Sun Jun 18 20:14:46 2000
From: marc_news@valinux.com (Marc MERLIN)
Date: Sun, 18 Jun 2000 12:14:46 -0700
Subject: [Mailman-Developers] mailing list digest broken with mailman CVS ?
In-Reply-To: <20000618100217.A7174@moremagic.merlins.org>; from marc_news@valinux.com on Sun, Jun 18, 2000 at 10:02:17AM -0700
References: <20000618100217.A7174@moremagic.merlins.org>
Message-ID: <20000618121445.B17676@marc.merlins.org>

On Sun, Jun 18, 2000 at 10:02:17AM -0700, Marc MERLIN wrote:
> Then, I upgraded to the CVS code of  the day on June 16th, and digests don't
> even  show up  in  mailman/logs/digest  (there are  already  two days  worth
> missing)

I do apologize for the wording of my previous mail, I wasn't sufficiently
awake when I wrote it.
I added the question  mark after "broken" in the subject  line and wanted to
add the following:
---
Of course if digests didn't work at all, there would be other mentions of it
on the  mailing list,  and I didn't  see any, so  where should  I look? What
could be wrong?
---

Thanks,
Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information


From ricardo@rixhq.nu  Sun Jun 18 21:56:15 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sun, 18 Jun 2000 22:56:15 +0200
Subject: [Mailman-Developers] latest cvs trouble
In-Reply-To: <14665.1291.385427.914555@anthem.concentric.net>; from bwarsaw@python.org on Thu, Jun 15, 2000 at 12:32:11PM -0400
References: <20000324235727.K12922@xs4all.nl> <20000325125159.A20826@miss-janet.com> <14663.9674.246238.29225@anthem.concentric.net> <20000614085245.C855@miss-janet.com> <14665.1291.385427.914555@anthem.concentric.net>
Message-ID: <20000618225615.A706@miss-janet.com>

Hi,

I was just grabbing the latest CVS version and then I noticed the changes
in admindb.py (thanks Barry! :) ) and I couldn't wait to try it out on my list... 
so I wanted to test the feature to send a copy of an email held for approval to a certain
email address... I tried this by clicking the forward option and supplying my
email address for one of the 16 messages held for approval and hitted the
submit button... then I get this error :

Traceback (innermost last):
  File "/usr/local/mailman/scripts/driver", line 95, in run_main
    main()
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 122, in main
    PrintRequests(mlist, doc, form)
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 177, in PrintRequests
    PrintPostRequest(mlist, id, info, total, count, form)
  File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 216, in PrintPostRequest
    mlist.HandleRequest(id, 2, None)
TypeError: not enough arguments; expected 7, got 4

this error kinda puzzles me and I'm not enough of an python expert to see what's
going wrong...
I also noticed getting about 16 copies of the approved post send to my email address... yikes...

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From ricardo@rixhq.nu  Sun Jun 18 22:08:44 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sun, 18 Jun 2000 23:08:44 +0200
Subject: [Mailman-Developers] found the error... (admindb.py)
Message-ID: <20000618230844.B706@miss-janet.com>

admindb.py line #216 gets called when a post is lost (which happened in my case
i guess)... but this is still and old call to mlist.HandleRequest() which doesn't
include the rest of the necessary function parameters...
maybe the extra parameters should default to empty ("") ?
i was confused because it looks like it calls with 3 parameters instead of 4...
but then i realized to first parameter is probably 'self'... right?
and then I wonder why the post got lost too... (well maybe the id just didnt get
removed from the db?)

ps: i'm cc-ing this to you Barry, because I know my posts tend to arrive a bit late
on the list for some reason ;)

Ricardo.

--



From foner@media.mit.edu  Sun Jun 18 22:44:14 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 17:44:14 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [one more...]
Message-ID: <200006182144.RAA04624@out-of-band.media.mit.edu>

(13) Things that get bounced to the admin address because they look
like administrivia (e.g., sending "help" to the main list address)
have -two- X-BeenThere: message headers.  Since this header is
presumably there to stop loops, it strikes me as odd that two of them
could be in a message under any circumstances.  (Maybe they're only
checked for messages intended to go all the way out through the main
list---the two of them -do- seem harmless so far---but it's still odd.)


From foner@media.mit.edu  Mon Jun 19 00:53:33 2000
From: foner@media.mit.edu (Lenny Foner)
Date: Sun, 18 Jun 2000 19:53:33 -0400 (EDT)
Subject: [Mailman-Developers] Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [and another]
Message-ID: <200006182353.TAA05006@out-of-band.media.mit.edu>

(14) When setting archival options, the form specifies the time period as
yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
order?


From dgc@uchicago.edu  Mon Jun 19 00:57:50 2000
From: dgc@uchicago.edu (David Champion)
Date: Sun, 18 Jun 2000 18:57:50 -0500
Subject: [Mailman-Developers] Re: Various mailman bugs (all in 2.0beta2 under HPUX 10.20) [and another]
In-Reply-To: <200006182353.TAA05006@out-of-band.media.mit.edu>; from foner@media.mit.edu on Sun, Jun 18, 2000 at 07:53:33PM -0400
References: <200006182353.TAA05006@out-of-band.media.mit.edu>
Message-ID: <20000618185750.H7911@smack.uchicago.edu>

On 2000.06.18, in <200006182353.TAA05006@out-of-band.media.mit.edu>,
	"Lenny Foner" <foner@media.mit.edu> wrote:
> (14) When setting archival options, the form specifies the time period as
> yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
> yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
> order?

This made me think of something else.  Mailman text is full of
references to the "monthly" password reminders.  Any ideas about
allowing that period to be configurable?  What about turning off those
messages when the site or list policy is not to mail them?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bigdog@dogpound.vnet.net  Mon Jun 19 02:02:04 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Sun, 18 Jun 2000 21:02:04 -0400 (EDT)
Subject: [Mailman-Developers] Re: Various mailman bugs (all in 2.0beta2
 under HPUX 10.20) [and another]
In-Reply-To: <20000618185750.H7911@smack.uchicago.edu>
Message-ID: <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>

Not to step on anyones toes..  But all these look like great bugs or
features you would like (except 13 which I believe is configuratable on
the admin page for the list..).  But I'm quite certain Berry & the other
Mailman developers are swamped down with other things.

If you could fix and/or send a patch for these fixes to the list (or post
them to sourceforge) i'm sure the developers would be greatly
appreciatiave or however you spell that.  And if your in the process of
this already..  tell me to shutup :)

On Sun, 18 Jun 2000, David Champion wrote:

> On 2000.06.18, in <200006182353.TAA05006@out-of-band.media.mit.edu>,
> 	"Lenny Foner" <foner@media.mit.edu> wrote:
> > (14) When setting archival options, the form specifies the time period as
> > yearly/monthly/quarterly/weekly/daily.  This is an odd order.  How about
> > yearly/quarterly/monthly/weekly/daily, which at least leaves them in size
> > order?
> 
> This made me think of something else.  Mailman text is full of
> references to the "monthly" password reminders.  Any ideas about
> allowing that period to be configurable?  What about turning off those
> messages when the site or list policy is not to mail them?

-- 
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/

----------------------------------------------------------------
Oxymoron: Sit up.
----------------------------------------------------------------
Sunday, June 18, 2000 / 08:51PM





From dgc@uchicago.edu  Mon Jun 19 02:12:36 2000
From: dgc@uchicago.edu (David Champion)
Date: Sun, 18 Jun 2000 20:12:36 -0500
Subject: [Mailman-Developers] Re: Re: Various mailman bugs (all in 2.0beta2
In-Reply-To: <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>; from bigdog@dogpound.vnet.net on Sun, Jun 18, 2000 at 09:02:04PM -0400
References: <20000618185750.H7911@smack.uchicago.edu> <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>
Message-ID: <20000618201236.L7911@smack.uchicago.edu>

On 2000.06.18, in <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>,
	"Matt Davis" <bigdog@dogpound.vnet.net> wrote:
> If you could fix and/or send a patch for these fixes to the list (or post
> them to sourceforge) i'm sure the developers would be greatly
> appreciatiave or however you spell that.  And if your in the process of
> this already..  tell me to shutup :)

I'm sure they would, too, but I don't know Python, and Lenny said he
doesn't, either.  I don't have time to learn Python just to make
patches to Mailman, but it's not doing anyone any good for us to sit on
the bugs we aren't able to fix ourselves.

Bugs should be reported.  All the better if you can submit patches, too.

Now, on that topic: Any responses to the last bug I reported (with a
patch) regarding rmlist?

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@python.org  Mon Jun 19 07:12:30 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:12:30 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
References: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
Message-ID: <14669.47566.224850.953941@anthem.concentric.net>

>>>>> "MC" == Mentor Cana <mentor@alb-net.com> writes:

    MC> TypeError: not enough arguments; expected 7, got 4

Patch appended.

-Barry

Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- admindb.py	2000/06/15 21:01:51	1.25
+++ admindb.py	2000/06/19 06:11:18	1.26
@@ -213,7 +213,7 @@
             # TBD: kludge to remove id from requests.db.  value==2 means
             # discard the message.
             try:
-                mlist.HandleRequest(id, 2, None)
+                mlist.HandleRequest(id, 3, None, None, None, None)
             except Errors.LostHeldMessage:
                 pass
             return


From bwarsaw@python.org  Mon Jun 19 07:17:41 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:17:41 -0400 (EDT)
Subject: [Mailman-Developers] a bug with the most recent CVS
References: <Pine.GSO.4.21.0006172236020.20851-100000@alb-net.com>
 <Pine.LNX.4.21.0006172301570.27164-100000@dogpound.vnet.net>
Message-ID: <14669.47877.911786.626295@anthem.concentric.net>

>>>>> "MD" == Matt Davis <bigdog@dogpound.vnet.net> writes:

    MD> It might help if you tell us a bit more about what you were
    MD> doing at hte time you got this problem.  What did you click?
    MD> What page was it from? What were you doing at the time?  What
    MD> color were your socks when this happened?

Who wears socks?

:)


From bwarsaw@python.org  Mon Jun 19 07:19:46 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:19:46 -0400 (EDT)
Subject: [Mailman-Developers] Error in /usr/local/mailman/cron/checkdbs
References: <20000618033202.1565D1CE28@dinsdale.python.org>
 <Pine.LNX.4.10.10006172337030.12449-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <14669.48002.355282.202511@anthem.concentric.net>

>>>>> "paul" ==   <paul@cr355112-a.slnt1.on.wave.home.com> writes:

    paul> I get this message daily: Subject: Cron <mailman@stout>
    paul> /usr/bin/python /usr/local/mailman/cron/checkdbs

This will be fixed in 2.0b3, which I had hoped to release this
weekend.  I found a last minute bug so the release will probably
happen sometime Monday.

-Barry


From bwarsaw@python.org  Mon Jun 19 07:52:22 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 19 Jun 2000 02:52:22 -0400 (EDT)
Subject: [Mailman-Developers] Re: Re: Various mailman bugs (all in 2.0beta2
References: <20000618185750.H7911@smack.uchicago.edu>
 <Pine.LNX.4.21.0006182052260.27716-100000@dogpound.vnet.net>
 <20000618201236.L7911@smack.uchicago.edu>
Message-ID: <14669.49958.574736.903273@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> Bugs should be reported.  All the better if you can submit
    DC> patches, too.

Please start using the SourceForge bug manager for reporting bugs.  I
don't have enough experience to know yet, but I hope it's better than
Jitterbug.

-Barry


From mentor@alb-net.com  Mon Jun 19 11:24:15 2000
From: mentor@alb-net.com (Mentor Cana)
Date: Mon, 19 Jun 2000 06:24:15 -0400 (EDT)
Subject: [Mailman-Developers] latest CVS "reject" option gives
Message-ID: <Pine.GSO.4.21.0006190620120.20851-100000@alb-net.com>

latest CVS...

If you try to reject a message in "Tend to pending administrative
requests", you get an error 
"TypeError: object does not support item deletion"
Then, if you go back to "Tend to pending administrative requests" shows the
rejected messages as lost.....

later,
mentor



From mss@transas.com  Mon Jun 19 13:11:11 2000
From: mss@transas.com (Michael Sobolev)
Date: Mon, 19 Jun 2000 16:11:11 +0400
Subject: [Mailman-Developers] mailman seems to ignore Content-Transfer-Encoding
Message-ID: <20000619153411.A19742@transas.com>

I have a problem here.  It's pretty simple (I believe).. :)

The messages sent to the mailling list have Content-Transfer-Encoding equal to
base64 or quoted-printable.  Mailing list software just adds its usual
blah-blah-blah (mailing-list, url, etc).  When such a message arrives to the
recipient, MUA processes the body according to the header's value, and the
users sees garbage.  What can I do (beside modifying the source :)?

Thanks,

--
Misha



From jmackenzie@local.ie  Mon Jun 19 17:48:21 2000
From: jmackenzie@local.ie (John MacKenzie)
Date: Mon, 19 Jun 2000 17:48:21 +0100
Subject: [Mailman-Developers] Issues With Mailman 2.0 upgrade
Message-ID: <00061917523002.05445@samsara.local.ie>

Hey guys, 

Since upgrading to the beta I've had issues sending some of my lists. 
On certain lists when I go to approve It waits a little while and then returns
with a "document contained no data" box. 

Other lists Work fine but it just happens with these certain ones (it would
appear that its just the ones with high volume subscribers. 

Anyone Know the cause of this and how to sort it ?

Cheers

- John


 -- 

John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html 
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie
t: +353 1 676 8996  f: +353 1 283 9988


From dgc@uchicago.edu  Mon Jun 19 20:00:46 2000
From: dgc@uchicago.edu (David Champion)
Date: Mon, 19 Jun 2000 14:00:46 -0500
Subject: [Mailman-Developers] explicit bulk approval
Message-ID: <20000619140046.J27585@smack.uchicago.edu>

Three alternate proposals:
1. Implicit-approval addresses supercede "too many recipients" blocking
   -- i.e., if sender matches "posters", then "max_num_recipients" is
   irrelevant.
2. Same as #1, but only if some new boolean is true.
3. Same as #1, but using a different address list than "posters".

(Slap me, please, if this is already in a newer version of Mailman.)

Do these seem good?  I have no idea whether I can do them, so if
someone else wants to, be my guest.  It would be a while before I get
to it since I need to learn more Python first.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From ajohnson@mail.xperts.com  Mon Jun 19 21:28:04 2000
From: ajohnson@mail.xperts.com (Johnson, April)
Date: Mon, 19 Jun 2000 16:28:04 -0400
Subject: [Mailman-Developers] Possible MIME bug
Message-ID: <5B7C00CB140FD4119B4E00508BA54CD5018C52@mail.xperts.com>

We've encountered a problem that may be a bug.  It is caused when HTML-style
email
is posted to the mailing list from MS Outlook Express
for Macintosh (version 4.5 and 5 tested, possibly also Eudora).  The MIME
data from the
Outlook email cannot be correctly interpreted, so
the MIME headers show up in the email contents. 

Is this a known bug? Is there a fix available?  

April Johnson
Xperts, Inc.
(804) 967-0700 x174
http://www.xperts.com
http://www.xperts.org




From gorgo@sztaki.hu  Tue Jun 20 16:01:55 2000
From: gorgo@sztaki.hu (Gergely Madarasz)
Date: Tue, 20 Jun 2000 17:01:55 +0200 (MET DST)
Subject: [Mailman-Developers] Bug#65955: Resent-To and Resent-Cc should be considered explicit
 destinations. (fwd)
Message-ID: <Pine.GSO.4.10.10006201701000.22817-100000@lutra.sztaki.hu>

A small bug, with a patch included... 

-- 
Madarasz Gergely           gorgo@sztaki.hu           gorgo@linux.rulez.org
     It's practically impossible to look at a penguin and feel angry.
         Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                   HuLUG: http://mlf.linux.rulez.org/

---------- Forwarded message ----------
Date: Tue, 20 Jun 2000 15:09:05 +0200
From: Thomas Quinot <quinot@ada.eu.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#65955: Resent-To and Resent-Cc should be considered explicit
    destinations.
Resent-Date: Tue, 20 Jun 2000 14:59:53 +0000 (GMT)
Resent-From: Thomas Quinot <quinot@ada.eu.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-cc: Gergely Madarasz <gorgo@sztaki.hu>

Package: mailman
Version: 1.1-6
Severity: normal

Currently, mailman only takes To: and Cc: headers into account to
determine whether a message was explicitly sent to a mailing list.
The Resent-To: and Resent-Cc: headers should be used as well. The following
patch is a proposed solution to this problem:

--- MailList.py.dist	Thu Jun  1 00:26:48 2000
+++ MailList.py	Tue Jun 20 15:04:06 2000
@@ -1118,7 +1118,8 @@
 	lowname = string.lower(self.real_name)
         recips = []
         # First check all dests against simple name:
-        for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'):
+        for recip in msg.getaddrlist('to') + msg.getaddrlist('cc') \
+            + msg.getaddrlist('resent-to') + msg.getaddrlist('resent-cc'):
             curr = string.lower(string.split(recip[1], '@')[0])
 	    if lowname == curr:
 		return 1

-- System Information
Debian Release: 2.2
Architecture: sparc
Kernel: Linux marvin 2.2.14 #2 Mon Feb 21 16:52:43 CET 2000 sparc64

Versions of packages mailman depends on:
ii  apache                1.3.9-13.1         Versatile, high-performance HTTP s
ii  apache [httpd]        1.3.9-13.1         Versatile, high-performance HTTP s
ii  cron                  3.0pl1-57          management of regular background p
ii  libc6                 2.1.3-10.0.1       GNU C Library: Shared libraries an
ii  logrotate             3.2-11             Log rotation utility              
hi  postfix [mail-transpo 0.0.19991231pl05-2 A mail transport agent            
ii  python-base           1.5.2-10           An interactive object-oriented scr




From klm@digicool.com  Tue Jun 20 22:55:13 2000
From: klm@digicool.com (Ken Manheimer)
Date: Tue, 20 Jun 2000 17:55:13 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
Message-ID: <14671.59457.568158.148145@korak.digicool.com>

When i left CNRI for Digital Creations, i thought i might continue
with mailman development, but that didn't wind up happening.  However,
i'm still pretty darn enthusiastic about the benefits of using Zope
stuff for mailman, and seeing Andrew Kuchling's recent ZODB/ZEO
introduction:

  http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

brings home the point pretty well - i think many of mailman's burning
issues would best be solved using ZODB and ZEO.

ZODB is the Zope Object DataBase, and ZEO is the Zope Enterprise
Option - multiple concurrent access to a single database.

Where would this help?  Lots and lots of places.  Mailman wants a
persistent object store, badly.  Anytime mailman does something with a
maillist, an instance of the Maillist class is instantiated, which
then fetches its instance information from a marshalled dictionary in
the filesystem.  Unless the activity is sure to *not* involve any
state changes, the maillist in question is locked - since multiple
instances of the maillist are separate copies.  !

Lots of stuff is jammed into the current, feeble persistence
mechanism, beyond the basic maillist state - stuff like subscriber
information, messages caught for administrative approval (though that
may be changing), maybe other stuff.  This means that not only are
multiple concurrent instances of a maillist distinct, disassociated
copies, but also that there's no way to share these other components
between them, without going to other storage.  (Other storage, eg the
filesystem, for things like the message delivery queues.)

Imagine, instead, that maillist instances and the other components
were implemented as persistent objects in the ZODB, which is reached
from the web, email, news, and command line interfaces with
lightweight scripts that plug into ZEO.  ZODB, being transactional,
would handle conflict resolution - no more locking performance or
misbehavior hassles - and the Connection class cache would take care
of rolling stuff in and out based on activation, for good
responsiveness and memory performance.

Messages going through the system could be implemented as persistent
objects in their own right.  This is useful for mediated transmission
through the message pipline, and also for retention for archival
purposes.  (Maybe the message store would be a separately mounted
ZODB, tuned for use as a smart archive, with provisions for good
cataloguing, message annotations, etc.)  Multiple threads in the
delivery pipeline could be processing the messages at once - for
parallel news gatewaying and mail transmission.  Messages held for
approval would already be in a kind of archive - currently, they're
held as message objects in the respective maillists, and are
marshalled and unmarshalled with the maillist state.  Bogus!

How are subscribers currently represented?  Urgh.  Last i knew, they
were manifest in scattered places in the maillist structure - entries
in the members or digest_members attributes, for membership info, with
parallel entries in the passwords (or somename like that) dictionary,
and probably elsewhere.  Unless this has since changed, they weren't
instance objects, but scattered data, and most importantly, they're
specific to each list.  Bogus!

This last may be the most telling failing of the current maillist-
marshal based persistence mechanism - it's neither unified nor
transparent, so there's no easy way to share state between lists.
Judicious use of ZODB plus ZEO could solve all that, making it easy to
represent the components of the system - mailling lists, members,
messages, etc - as real objects, with transparent, transactional
persistence and concurrent access built in.

My cries of "bogus", above, should not be taken as condemnation.  I
still think mailman is great - i'm pretty pleased to see the way it
has taken off.  I do think that the current architecture has severe
limitations, in particular, it will continue to involve great pain
with filesystem locking, obstruction to unified membership, etc.  And
i think that a concurrent persistent object system is the right way to
deal with this - and ZODB plus ZEO are just about ideal prospects for
providing that...

Take a look at the andrews description - 

  http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

Ken Manheimer
klm@digicool.com


From jim@cosource.com  Wed Jun 21 00:32:36 2000
From: jim@cosource.com (Jim Hebert)
Date: Tue, 20 Jun 2000 19:32:36 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <14671.59457.568158.148145@korak.digicool.com>
Message-ID: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, Ken Manheimer wrote:

[awesome stuff snipped]

Ken, thanks for brining this up! I too have been sitting here thinking
about how Zope stuff could really be beneficial to Mailman (I was esp.
thinking this during the recent discussion of the need for a pipermail
successor). But I figured I was too green to be so impetuous. =)

To some, making mailman depend on peices of zope might be ornerous, but to
me it's a better call than hooking it directly up to something like
postgres (which I've heard batted around) and gets you a whole lot more,
too. I run zope and mailman one several machines for work and play and
would love to see them working even better together. Getting list data
into the Zope db puts mailman within striking distance of resting other
things on zope's shoulders, such as the web interface (one which can then
look like the rest of the web site), a pipermail successor, etc.

While your suggestions obviously aren't something that can be talked about
for 2.0 (ever notice how many great ideas come out right before you issue
a release candidate for something? :->), I'd love to know what the take is
on this for some future major release from the current Mailman gods? And,
more importantly, how can we help make it happen?

jim

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From claw@kanga.nu  Wed Jun 21 01:17:43 2000
From: claw@kanga.nu (J C Lawrence)
Date: Tue, 20 Jun 2000 17:17:43 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: Message from Jim Hebert <jim@cosource.com>
 of "Tue, 20 Jun 2000 19:32:36 EDT." <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
Message-ID: <21635.961546663@kanga.nu>

On Tue, 20 Jun 2000 19:32:36 -0400 (EDT) 
Jim Hebert <jim@cosource.com> wrote:

> To some, making mailman depend on peices of zope might be
> ornerous, but to me it's a better call than hooking it directly up
> to something like postgres (which I've heard batted around) and
> gets you a whole lot more, too...

The problem with this is that there are a large number (majority?)
of Mailman users who specifically don't want to run Zope but do want
to run Mailman.  Bolting the ZODB underneath Mailman is not a Bad
Idea, but at the same time, for sites that already have all their
data in an SQL database, it doesn't solve their problems of
integrating Mailman with their other infrastructure (web acocunts,
LDAP, customer catabases, third part databases, etc).  As such,
Mailman moving to ZODB for them is a losing situation.

Should Mailman gain a database abstraction which allows ZODB or a
variety of SQL databases to be plugged in underneath, everybody wins
_and_ you provide an easy migration path for those people who later
want to move over to Zope proper.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From chuqui@plaidworks.com  Wed Jun 21 01:19:02 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 17:19:02 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006201915140.14000-100000@ray.compu-aid.com>
Message-ID: <p04320407b575b874c134@[209.239.169.197]>

At 7:32 PM -0400 6/20/2000, Jim Hebert wrote:

>Ken, thanks for brining this up! I too have been sitting here thinking
>about how Zope stuff could really be beneficial to Mailman

very, very intriguing. Looks like almost a gut job rewrite, though -- 
it seems to me we're talking about an "Apache 2.0" class job, so not 
only isn't this Mailman 2.0, it's unclear if it's Mailman 2.x -- 
perhaps mailman 3.0? But -- it looks really interesting. It sure 
ought to be investigated.

>too. I run zope and mailman one several machines for work and play and
>would love to see them working even better together. Getting list data
>into the Zope db puts mailman within striking distance of resting other
>things on zope's shoulders, such as the web interface (one which can then
>look like the rest of the web site), a pipermail successor, etc.

Me, I've been mulling over a couple of things -- one being a hotmail 
clone type of system, another being an egroups clone type of system. 
I'm thinking, at first glance, that if you do a Zope integration, 
when you come out the other side, you don't have Mailman any more, 
but instead you have an egroups clone instead. And it may well be 
that you need (or want) both, although not at the same time. not all 
Mailman users are going to want, need, or be able to use the whole 
zope world -- let's not forget that Mailman lives in a lot of places 
where you don't have a dedicated machine. Not everyone can get a Zope 
environment installed on them. So perhaps something this significant 
is its own universe, not Mailman -- and Mailman continues forward in 
parallel, serving different needs?

In fact, with a little thinking, you can build a system that is a 
hotmail clone, an egroups clone, and handles mailman's functionality, 
all together. A little thinking (hah!) and a lot of work...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Wed Jun 21 02:27:01 2000
From: jim@cosource.com (Jim Hebert)
Date: Tue, 20 Jun 2000 21:27:01 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <p04320407b575b874c134@[209.239.169.197]>
Message-ID: <Pine.LNX.4.10.10006202049590.14118-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, Chuq Von Rospach wrote:

> I'm thinking, at first glance, that if you do a Zope integration, 
> when you come out the other side, you don't have Mailman any more, 

Ah, here's where I kick myself for throwing out the post I was going to
write the other day during the pipermail thread. =)

I agree with that, but at the same time I think (as you do, I think, see
what I've quoted below) that with the right OO strategies you can come up
with a large number of classes, the ones that do a lot of the low-level
work, that are common to both. I (embarrasingly) haven't taken the time to
try to draw up what such a interface would look like, for all I know the
existing class structure for Mailman is perfect and what I'm describing is
just additional code rather than changes to existing stuff. =)

> In fact, with a little thinking, you can build a system that is a 
> hotmail clone, an egroups clone, and handles mailman's functionality, 
> all together. A little thinking (hah!) and a lot of work...

Indeed, though whereas you're thinking "all together" I may be thinking of
a separation of packages like, say,

mailman-libs: the common set, as above
mailman-db-adapter(s): the db abstraction, like J C mentioned
mailman-zope: the stuff to implement lots-o-stuff in zope (see my prev msg)
mailman-?: the stuff to implement the traditional stuff as cgi's, etc

That's a mighty tall suggestion relative to the amount of code I've
written, I know. =) I'm sure Barry is reading all of this and slapping his
forehead like "Oy! More work? Easy for them to say!" =)

If I should just leave mailman out of this and go subscribe to a zope list
and talk about a from-scratch effort there, a tap with a LART is all it'll
take. =)

jim
who had thought about trying to go off and write a mlm in zope all by
himself for all of about 10 seconds. =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox





From jim@cosource.com  Wed Jun 21 05:18:28 2000
From: jim@cosource.com (Jim Hebert)
Date: Wed, 21 Jun 2000 00:18:28 -0400 (EDT)
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <21635.961546663@kanga.nu>
Message-ID: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>

On Tue, 20 Jun 2000, J C Lawrence wrote:

> Should Mailman gain a database abstraction which allows ZODB or a
> variety of SQL databases to be plugged in underneath, everybody wins

Just for the same of completeness and/or if you missed it in my reply to
Chuq, I totally agree with this. Given such an abstraction, they who
wanted Zope integration can go about getting it done, which may just be me
'n' Ken for all I know. ;-)

ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
leaving zope enthusiasts to start a side project, namely "get a DB-API
interface to the ZODB" ? There's some pretty big "up" sides to that
approach. =)

jim




From chuqui@plaidworks.com  Wed Jun 21 05:22:27 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 21:22:27 -0700
Subject: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
Message-ID: <p04320401b575f3368e58@[209.239.169.197]>

At 12:18 AM -0400 6/21/2000, Jim Hebert wrote:

>ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
>leaving zope enthusiasts to start a side project, namely "get a DB-API
>interface to the ZODB" ? There's some pretty big "up" sides to that
>approach. =)

Seems to me that if you add a DBI interface, you can make a clean 
break from the current DB stuff while keeping compatibility with it. 
And then Zope does a DBI interface, and it's a generic addition to 
Zope that comes in handy for more than mailman.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From mailman-developers@python.org  Wed Jun 21 05:35:39 2000
From: mailman-developers@python.org (John Morton)
Date: Wed, 21 Jun 2000 16:35:39 +1200 (NZST)
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
Message-ID: <200006210435.QAA02259@vesta.plain.co.nz>

On Wed, 21 Jun 2000 00:18:28 -0400 (EDT) you wrote:

 > On Tue, 20 Jun 2000, J C Lawrence wrote:
 >=20
 > > Should Mailman gain a database abstraction which allows ZODB or a
 > > variety of SQL databases to be plugged in underneath, everybody wins
 >=20
 > Just for the same of completeness and/or if you missed it in my reply to
 > Chuq, I totally agree with this. Given such an abstraction, they who
 > wanted Zope integration can go about getting it done, which may just be =
me
 > 'n' Ken for all I know. ;-)
=20
Sounds great to me. In fact I think that, with a bit of negotiation with
DC, the ZODB part of Zope could be distributed as a separate library with
appropriate license terms so that Mailman can use it as Just Another
Python Module, without depending on Zope being installed.=20

At the other end of the program, a similar API for the web interface stuff
would be enormously useful. I'd like to implement a Mailman interface with
Zope, and I'm sure other people would like to use PHP/mod_perl/Cold
Fusion/ASP and so forth.

 > ObMakeOrBuy: Should this hypothetical DB abstraction just be the DB-API,
 > leaving zope enthusiasts to start a side project, namely "get a DB-API
 > interface to the ZODB" ? There's some pretty big "up" sides to that
 > approach. =3D)

As Mailman will still have to have a 'native' data store, setting up the
API to be a collection of functions that fetch data from storage and place
them into python structures of one form or another seams to be the best
bet.=20

John
(Long time lurker, first time poster).




From petrilli@amber.org  Wed Jun 21 06:07:04 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Wed, 21 Jun 2000 01:07:04 -0400
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <200006210435.QAA02259@vesta.plain.co.nz>; from jwm@plain.co.nz on Wed, Jun 21, 2000 at 04:35:39PM +1200
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com> <200006210435.QAA02259@vesta.plain.co.nz>
Message-ID: <20000621010704.B22544@trump.amber.org>

John Morton [jwm@plain.co.nz] wrote:
> On Wed, 21 Jun 2000 00:18:28 -0400 (EDT) you wrote:
> 
>  > On Tue, 20 Jun 2000, J C Lawrence wrote:
>  > 
>  > > Should Mailman gain a database abstraction which allows ZODB or a
>  > > variety of SQL databases to be plugged in underneath, everybody wins
>  > 
>  > Just for the same of completeness and/or if you missed it in my reply to
>  > Chuq, I totally agree with this. Given such an abstraction, they who
>  > wanted Zope integration can go about getting it done, which may just be me
>  > 'n' Ken for all I know. ;-)
>  
> Sounds great to me. In fact I think that, with a bit of negotiation with
> DC, the ZODB part of Zope could be distributed as a separate library with
> appropriate license terms so that Mailman can use it as Just Another
> Python Module, without depending on Zope being installed. 


As someone else at DC, I can speak for two issues.  I don't think we'd 
be opposed to separate distributions of ZODB/ZEO, this has always been 
kept as clean as possible, but there are some dependencies (like
ZServer for doing the Client/Server piece).  As for license,
well... it's our license, which is Open Source, but I don't know how
that will fly with the GPL-nazis.  My time at the FSF (many many years 
ago) leads me to believe it'd not go over well, and would make this
all a non-starter.

As for a DB-API interface, that would pretty well negate using ZODB,
since DB-API is aimed at ractangular data, not rich objects.  You
would need to create an abstraction layer much higher than that. More
like an O-R mapping (a'la EOF, or whatever).

Chris
--
| Christopher Petrilli
| petrilli@amber.org


From chuqui@plaidworks.com  Wed Jun 21 06:43:37 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Tue, 20 Jun 2000 22:43:37 -0700
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <20000621010704.B22544@trump.amber.org>
References: <Pine.LNX.4.10.10006202350290.14258-100000@ray.compu-aid.com>
 <200006210435.QAA02259@vesta.plain.co.nz>
 <20000621010704.B22544@trump.amber.org>
Message-ID: <p04320404b57605d0eccf@[209.239.169.197]>

At 1:07 AM -0400 6/21/2000, Christopher Petrilli wrote:

>As for a DB-API interface, that would pretty well negate using ZODB,
>since DB-API is aimed at ractangular data, not rich objects.  You
>would need to create an abstraction layer much higher than that. More
>like an O-R mapping (a'la EOF, or whatever).

So if I get this correctly, there needs to be an API involved that 
could interact with DB, DBI or ZODB, much as the DBI layer abstracts 
MySQL, PostGres, ODBC, et al.

That actually isn't a bad idea at all, since the first thing that can 
be done is defining the abstraction layer for the API, then building 
the DB interface to it so that existing systems can migrate and keep 
existing systems. And then that can be extended to support the other 
data stores as time and need meet with resources and volunteers. 
That's probably the cleanest answer anyway, since the first thing 
that happens is you build the API into an existing system, so you 
isolate the complexity of defining the API and building in the new 
datastores.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jim@cosource.com  Wed Jun 21 06:57:23 2000
From: jim@cosource.com (Jim Hebert)
Date: Wed, 21 Jun 2000 01:57:23 -0400 (EDT)
Subject: Re[2]: [Mailman-Developers] ZODB and ZEO for mailman
In-Reply-To: <200006210435.QAA02259@vesta.plain.co.nz>
Message-ID: <Pine.LNX.4.10.10006210152140.14319-100000@ray.compu-aid.com>

On Wed, 21 Jun 2000, John Morton wrote:

> As Mailman will still have to have a 'native' data store, setting up the
> API to be a collection of functions that fetch data from storage and place
> them into python structures of one form or another seams to be the best
> bet. 

Well, as for 'native' data store in a world where DB-API was the only
abstraction we'd have, I was thinking Gadfly or something in that spirit.

<abandoning ship>

But, that said, Chuq's latest post made me realize the need to accomodate
existing installations and migrating existing data. So, rather than go for
the slam-dunk pure-db-api with nothing on top of it, I am coming back
around in my own mind to J C's original proposal that there'd need to be
some sort of custom abstraction layer. =)

jim
who used to think he was indecisive, but now he's not so sure...

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From bernhard@intevation.de  Wed Jun 21 11:28:16 2000
From: bernhard@intevation.de (Bernhard Reiter)
Date: Wed, 21 Jun 2000 12:28:16 +0200
Subject: [Mailman-Developers] New beta release needed (+ little patch)
Message-ID: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>

--6b3yLyRKT1M6kiA0
Content-Type: multipart/mixed; boundary="wj9ZLJVQDRFjGSdK"


--wj9ZLJVQDRFjGSdK
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

It looks like a new mailman beta or even pre beta release is badly=20
needed. I had to make to many little adjustments to 2.0b2.
(Also see my mail to mailman-users in April.)

So please release a bug-fix version. I see people going for the CVS
version. This creates a lot of work for people who just want to run
mailman in a stable way.

Here is another little patch so that error messages for external
archivers do not get lost. (You have to other chance to get that
information.)

Regards,
	Bernhard

--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project				            (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)

--wj9ZLJVQDRFjGSdK
Content-Type: text/plain; charset=us-ascii
Content-Description: Patch to log error messages from external archivers
Content-Disposition: attachment; filename="2.0beta2.local4.diff"
Content-Transfer-Encoding: quoted-printable

--- Mailman/Archiver/Archiver.py.org	Tue Jun 20 21:30:00 2000
+++ Mailman/Archiver/Archiver.py	Tue Jun 20 21:38:45 2000
@@ -180,8 +180,10 @@
         status =3D extarch.close()
         if status:
             self.LogMsg('error',
-                        'external archiver non-zero exit status: %d\n' %
-                        (status & 0xff00) >> 8)
+                        'external archiver non-zero exit status: %d\n'=20
+			'\t while piping mail into:\n'
+			'\t\"%s\"' %
+                        ((status & 0xff00) >> 8,cmd) )
=20
     #
     # archiving in real time  this is called from list.post(msg)

--wj9ZLJVQDRFjGSdK--

--6b3yLyRKT1M6kiA0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (SunOS)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjlQmL0ACgkQh9ag3dpKERb7pQCfd+KEvtcnTLwSCfgH8Ddp+2Wd
qrAAoNfWpsES3z6WbbrOl834+Ki9ihfo
=iwGE
-----END PGP SIGNATURE-----

--6b3yLyRKT1M6kiA0--


From paul@cr355112-a.slnt1.on.wave.home.com  Wed Jun 21 15:29:22 2000
From: paul@cr355112-a.slnt1.on.wave.home.com (paul)
Date: Wed, 21 Jun 2000 10:29:22 -0400 (EDT)
Subject: [Mailman-Developers] Wildcards in E-mail list...
In-Reply-To: <Pine.LNX.4.10.10006180313350.12633-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <Pine.LNX.4.10.10006211026450.18820-100000@cr355112-a.slnt1.on.wave.home.com>

Is there a way to use wildcards in the "Addresses of members accepted for
posting"(privacy options) box ?

Thanks
___________________________________________________________
Paul Faure			    paul@engsoc.carleton.ca



From edelrio@icm.csic.es  Thu Jun 22 09:18:32 2000
From: edelrio@icm.csic.es (Evilio del Rio)
Date: Thu, 22 Jun 2000 10:18:32 +0200 (CEST)
Subject: [Mailman-Developers] Re: [Mailman-Users] Domain allowed to post to a list.
In-Reply-To: <394F9967.B4E77C6D@dcu.ie>
Message-ID: <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Jun 2000, Fergus Donohue wrote:

> 
> Hi,
> 
> Could someone give me some info on the following? I want to allow all
> users in a particular mail domain to post to a list - I've searched the
> archives and found the answer "add @domain.tld to the field Addresses of
> members accepted for posting to this list without implicit approval
> requirement."  I've tried this and also some regular expression
> variations on it and can't get it to work. I also tried the same in
> "Addresses always held for Approval" (making the list open and add a
> regex to hold anything not in domain @domain.tld). Again no luck! Can
> someone give me an example of how they're doing this?
> 
> Thanks,
> 
> Fergus Donohue.
>
[Note: I have already sent a message similar to this one 
	but I had no reply.]

Hi Fergus,

Some days ago I was searching for the same feature. AFAIK, this is not
possible with the current stable distribution (I haven't tried with
the developement one).

Now the good news: it is easy to patch Mailman to accept a regular
expression as the "posters" settings (addresses allowed to post to a
restricted list even if they are not members). I have patched the
following file:

/home/mailman/Mailman/Handlers/Hold.py

(/home/mailman is where I installed it)

The result of the "diff" between the patched file vs. the
original one are (you can use patch if you want to try):

32a33
> import re
120c121,123
<         posters = Utils.List2Dict(map(string.lower, mlist.posters))
- ---
>       isposter = 0
>       for poster in mlist.posters:
>               isposter = isposter or re.compile(poster,
re.I).match(sender)
122c125
<            not Utils.FindMatchingAddresses(sender, posters):
- ---
>            not isposter:

Then, you must set the "posters" settings to something like that:

	.+@my.domain.com

If you do it via Web it's on the "Privacy Options", under the label
"Addresses of members accepted for posting (...) in addition to allowing
posting by list members"

or if you use /home/mailman/bin/config_list, you must set the following in
the input config file:

	posters = ['.+@my.doma.in']

I would like to know if this is works for you.

I would also like to hear some comments about this patch because I am a
begginer in python and I do not know quite well if this is the correct
place to implement this feature. I propose that this or a similar feature 
must be included in the standard Mailman distribution (that's why I send
this message to the developers list)

HTH,

________________________________________________________________
Evilio Jose del Rio Silvan          Institut de Ciencies del Mar
edelrio@icm.csic.es          http://members.es.tripod.de/Evilio/
"He tingut una idea" - Joan Gamper, 27 de novembre de 1899
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5UcviBYZlGm2iEEIRAme1AJ47QhAOgebJe+sEItgyYoF4zRDz/wCfZOUt
EzKh2jX5gWMcSzNlCzlOqxY=
=JUaF
-----END PGP SIGNATURE-----




From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From Dan.Mick@west.sun.com  Wed Jun 21 21:22:22 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 13:22:22 -0700
Subject: [Mailman-Developers] Wildcards in E-mail list...
References: <Pine.LNX.4.10.10006211026450.18820-100000@cr355112-a.slnt1.on.wave.home.com>
Message-ID: <395123FE.86485F07@west.sun.com>


paul wrote:
> 
> Is there a way to use wildcards in the "Addresses of members accepted for
> posting"(privacy options) box ?

It looks to me like the answer is "no" for 1.1, and I don't see anything
different for 2.0.


From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From bwarsaw@python.org  Wed Jun 21 16:45:59 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Wed, 21 Jun 2000 11:45:59 -0400 (EDT)
Subject: [Mailman-Developers] New beta release needed (+ little patch)
References: <20000621122816.F2702@cheops.usf.Uni-Osnabrueck.DE>
Message-ID: <14672.58167.653957.234326@anthem.concentric.net>

>>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:

    BR> It looks like a new mailman beta or even pre beta release is
    BR> badly needed. I had to make to many little adjustments to
    BR> 2.0b2.  (Also see my mail to mailman-users in April.)

There will be one very soon now (within hours or at most a day).  I
was all set to push the button and we saw errors in the logs on
python.org, and duplicates in the digests.  I want to see if I can fix
that problem first.

-Barry


From Dan.Mick@west.sun.com  Wed Jun 21 22:42:50 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:42:50 -0700
Subject: [Mailman-Developers] SMTPDirect doesn't log to 'posts'
Message-ID: <395136DA.26363FB7@west.sun.com>

Just decided to be brave and install the current 2.0 CVS on top of my 1.1
list.  So far so good....but I see no posts in "logs/post".  Is this 
intentional with SMTPDirect (the default Handler), and if so, why?
post is a useful little log to make sure things are getting through.


From Dan.Mick@west.sun.com  Wed Jun 21 22:48:33 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:48:33 -0700
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <39513831.A47AB59F@west.sun.com>

I had to fix this bug, which was reported in May, before I could use the current
CVS:

dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
182c182
<             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
---
>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)

Could someone with putback access clean this up, please?


From Dan.Mick@west.sun.com  Wed Jun 21 22:48:33 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 14:48:33 -0700
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <39513831.A47AB59F@west.sun.com>

I had to fix this bug, which was reported in May, before I could use the current
CVS:

dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
182c182
<             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
---
>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)

Could someone with putback access clean this up, please?


From Dan.Mick@west.sun.com  Wed Jun 21 23:06:47 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 15:06:47 -0700
Subject: [Mailman-Developers] Errors with current CVS
Message-ID: <39513C77.C2B79C04@west.sun.com>

Also getting errors like this:

Jun 21 14:49:09 2000 post(10558): Traceback (innermost last):
post(10558):   File "/export/home/mailman/scripts/mailowner", line 89, in ?
post(10558):      main()
post(10558):   File "/export/home/mailman/scripts/mailowner", line 79, in main
post(10558):      enqueue = HandlerAPI.DeliverToUser(mlist, msg, msgdata)
post(10558):   File "/export/home/mailman/Mailman/Handlers/HandlerAPI.py", line
146, in DeliverToUser
post(10558):      msgdata = {'pipeline' : pipeline,
post(10558): AttributeError :  recips

still trying to track down.


From Dan.Mick@west.sun.com  Wed Jun 21 23:20:16 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 15:20:16 -0700
Subject: [Mailman-Developers] Another bug in current CVS
Message-ID: <39513FA0.212BB633@west.sun.com>

scripts/mailowner calls HandlerAPI.DeliverToUser; in doing so, it must set msg.recips,
but doesn't.  

Here's a patch.

*** mailowner.orig      Wed Jun 21 15:13:54 2000
--- mailowner   Wed Jun 21 15:14:19 2000
***************
*** 76,81 ****
--- 76,82 ----
          msgdata = {'recips' : recips,
                     'toadmin': 1,
                     }
+       msg.recips = recips
          enqueue = HandlerAPI.DeliverToUser(mlist, msg, msgdata)
          if enqueue:
              msg.Enqueue(mlist, newdata=msgdata)


What's going on?  How am I running into all this stuff?  I thought others were
running the current CVS?


From Dan.Mick@west.sun.com  Thu Jun 22 01:20:52 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Wed, 21 Jun 2000 17:20:52 -0700
Subject: [Mailman-Developers] test
Message-ID: <39515BE4.DFA16FA4@west.sun.com>

 


From Nigel.Metheringham@VData.co.uk  Thu Jun 22 13:51:20 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Thu, 22 Jun 2000 13:51:20 +0100
Subject: [Mailman-Developers] Indexing pipermail archives
Message-ID: <E1356S0-00036L-00@rioja.localnet>

I've just been looking at the problem of indexing/searching a large 
Mailman/pipermail archive.

htdig will do the job, but the (htdig) indexes get bloated by the 
pipermail index pages (which are *very* rarely what you want when 
searching for something).

Indexing can be controlled by meta tags.  [See http://info.webcrawler.co
m/mak/projects/robots/meta-user.html ].  The pipermail HTML generation 
is hard coded into the archiver code.

As a short term fix, would people be happy with me adding the following 
meta tags to the pipermail HTML generation:-

  On top level (ie list of weeks/months etc) and by-date index pages:-
     <meta name="robots" content="noindex,follow">
	[ie do not index the page, follow links down to the articles]

  On thread/subject/author indexes
     <meta name="robots" content="noindex,nofollow">
        [skip page and linked pages - nofollow is superluous since the
	indexing robot should realise that the pages are already included
	but it doesn't hurt much]

  On article pages
     <meta name="robots" content="index,nofollow">
	[you may disagree with the nofollow, but I think there is no general
	requirement for the indexer to follow links off the list]

Its a hack for now, but will make htdig and other indexing robots 
behave better.

Comments?

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From ckolar@admin.aurora.edu  Thu Jun 22 15:37:46 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Thu, 22 Jun 2000 09:37:46 -0500
Subject: [Mailman-Developers] Fwd: Mailman error messages.
Message-ID: <4.3.2.7.2.20000622093659.00d10e00@admin.aurora.edu>

--=====================_64945825==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

This was sent to me by someone.  No need to reply directly to me, and the 
person is not on the list.

--chris



>From: "czh" <tonytsai@ec.dayi.com>
>To: <ckolar@admin.aurora.edu>
>Subject: Mailman error messages.
>Date: Thu, 22 Jun 2000 14:30:43 +0800
>X-Mailer: Microsoft Outlook Express 5.00.2615.200
>
>Hi Ckolar,
>I just want to install Mailman into my Slackware, but got the error messages,
>   ---------------- Begin of error messages  -------------
>
>
>Bug in Mailman version 2.0beta2
>
>
>
>
>
>We're sorry, we hit a bug!
>
>
>
>If you would like to help us identify the problem, please email a copy of 
>this page to the webmaster for this site with a description of what 
>happened. Thanks!
>
>Traceback:
>
>
>
>
>Traceback (innermost last):
>   File "/home/mailman/scripts/driver", line 64, in run_main
>     immediate=1)
>   File "/home/mailman/Mailman/Logging/StampedLogger.py", line 49, in __init__
>     Logger.__init__(self, category, nofail, immediate)
>   File "/home/mailman/Mailman/Logging/Logger.py", line 40, in __init__
>     self.__get_f()
>   File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f
>     f = self.__fp = open(self.__filename, 'a+', 1)
>IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'
>
>
>
>----------
>
>
>Python information:
>
>
>
>Variable Value
>sys.version 1.5.2 (#1, Jul 17 1999, 22:10:16) [GCC egcs-2.91.66 
>19990314/Linux (egcs-
>sys.executable /usr/bin/python
>sys.prefix /usr
>sys.exec_prefix /usr
>sys.path /usr
>sys.platform linux2
>
>
>----------
>
>
>Environment variables:
>
>
>
>Variable Value
>DOCUMENT_ROOT /usr/local/etc/httpd/htdocs
>SERVER_ADDR 203.74.9.7
>HTTP_ACCEPT_ENCODING gzip, deflate, gzip, deflate
>SERVER_PORT 443
>PATH_TRANSLATED /usr/local/etc/httpd/htdocs/abcde
>ssl_unclean_shutdown 1
>SERVER_PROTOCOL HTTP/1.1
>HTTP_ACCEPT_LANGUAGE zh-tw, zh-tw
>GATEWAY_INTERFACE CGI/1.1
>nokeepalive 1
>HTTP_CONNECTION Keep-Alive
>HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
>HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
>application/vnd.ms-powerpoint, application/vnd.ms-excel, 
>application/msword, */*
>REQUEST_URI /mailman/admin/abcde
>SERVER_NAME czh.dayi.com
>PATH 
>/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:/opt/kde/bin:/usr/share/texmf/bin 
>
>QUERY_STRING
>SCRIPT_FILENAME /home/mailman/cgi-bin/admin
>HTTPS on
>PATH_INFO /abcde
>HTTP_HOST czh.dayi.com
>REQUEST_METHOD GET
>SERVER_SIGNATURE Apache/1.3.12 Server at czh.dayi.com Port 443
>SCRIPT_NAME /mailman/admin
>SERVER_ADMIN root@czh.dayi.com
>SERVER_SOFTWARE Apache/1.3.12 (Unix) PHP/4.0.0 mod_ssl/2.6.4 OpenSSL/0.9.5a
>PYTHONPATH /home/mailman
>REMOTE_ADDR 203.74.9.62
>REMOTE_PORT 64731

--=====================_64945825==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
This was sent to me by someone.&nbsp; No need to reply directly to me,
and the person is not on the list.<br>
<br>
--chris<br>
<br>
<br>
<br>
<blockquote type=cite cite>From: &quot;czh&quot;
&lt;tonytsai@ec.dayi.com&gt;<br>
To: &lt;ckolar@admin.aurora.edu&gt;<br>
Subject: Mailman error messages.<br>
Date: Thu, 22 Jun 2000 14:30:43 +0800<br>
X-Mailer: Microsoft Outlook Express 5.00.2615.200<br>
<br>
<font size=2>Hi Ckolar,</font><br>
<font size=2>I just want to install Mailman into my Slackware, but got
the error messages,</font><br>
<font size=2>&nbsp; ---------------- Begin of error messages&nbsp;
-------------</font><br>
<font size=2><br>
</font><h2><b>Bug in Mailman version 2.0beta2</b></h2><font size=2><br>
<br>
<br>
</font><h3><b>We're sorry, we hit a bug!</b></h3><font size=2><br>
<br>
If you would like to help us identify the problem, please email a copy of
this page to the webmaster for this site with a description of what
happened. Thanks! <br>
</font><h4><b>Traceback:</b></h4><font size=2><br>
<br>
<br>
</font><pre>Traceback (innermost last):
&nbsp; File &quot;/home/mailman/scripts/driver&quot;, line 64, in
run_main
&nbsp;&nbsp;&nbsp; immediate=1)
&nbsp; File &quot;/home/mailman/Mailman/Logging/StampedLogger.py&quot;,
line 49, in __init__
&nbsp;&nbsp;&nbsp; Logger.__init__(self, category, nofail, immediate)
&nbsp; File &quot;/home/mailman/Mailman/Logging/Logger.py&quot;, line 40,
in __init__
&nbsp;&nbsp;&nbsp; self.__get_f()
&nbsp; File &quot;/home/mailman/Mailman/Logging/Logger.py&quot;, line 55,
in __get_f
&nbsp;&nbsp;&nbsp; f = self.__fp = open(self.__filename, 'a+', 1)
IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'


</pre><font face="Courier New, Courier"><hr>
</font><br>
<h4><b>Python information:</b></h4><br>
<br>
Variable Value<br>
<tt>sys.version</tt> 1.5.2 (#1, Jul 17 1999, 22:10:16) [GCC egcs-2.91.66
19990314/Linux (egcs- <br>
<tt>sys.executable</tt> /usr/bin/python <br>
<tt>sys.prefix</tt> /usr <br>
<tt>sys.exec_prefix</tt> /usr <br>
<tt>sys.path</tt> /usr <br>
<tt>sys.platform</tt> linux2 <br>
<br>
<hr>
<br>
<h4><b>Environment variables:</b></h4><br>
<br>
Variable Value<br>
<tt>DOCUMENT_ROOT </tt>/usr/local/etc/httpd/htdocs <br>
<tt>SERVER_ADDR </tt>203.74.9.7 <br>
<tt>HTTP_ACCEPT_ENCODING </tt>gzip, deflate, gzip, deflate <br>
<tt>SERVER_PORT </tt>443 <br>
<tt>PATH_TRANSLATED </tt>/usr/local/etc/httpd/htdocs/abcde <br>
<tt>ssl_unclean_shutdown </tt>1 <br>
<tt>SERVER_PROTOCOL </tt>HTTP/1.1 <br>
<tt>HTTP_ACCEPT_LANGUAGE </tt>zh-tw, zh-tw <br>
<tt>GATEWAY_INTERFACE </tt>CGI/1.1 <br>
<tt>nokeepalive </tt>1 <br>
<tt>HTTP_CONNECTION </tt>Keep-Alive <br>
<tt>HTTP_USER_AGENT </tt>Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;
DigExt) <br>
<tt>HTTP_ACCEPT </tt>image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */* <br>
<tt>REQUEST_URI </tt>/mailman/admin/abcde <br>
<tt>SERVER_NAME </tt>czh.dayi.com <br>
<tt>PATH
</tt>/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/games:/opt/kde/bin:/usr/share/texmf/bin
<br>
<tt>QUERY_STRING </tt><br>
<tt>SCRIPT_FILENAME </tt>/home/mailman/cgi-bin/admin <br>
<tt>HTTPS </tt>on <br>
<tt>PATH_INFO </tt>/abcde <br>
<tt>HTTP_HOST </tt>czh.dayi.com <br>
<tt>REQUEST_METHOD </tt>GET <br>
<tt>SERVER_SIGNATURE </tt>Apache/1.3.12 Server at czh.dayi.com Port
443<br>
<tt>SCRIPT_NAME </tt>/mailman/admin <br>
<tt>SERVER_ADMIN </tt>root@czh.dayi.com <br>
<tt>SERVER_SOFTWARE </tt>Apache/1.3.12 (Unix) PHP/4.0.0 mod_ssl/2.6.4
OpenSSL/0.9.5a <br>
<tt>PYTHONPATH </tt>/home/mailman <br>
<tt>REMOTE_ADDR </tt>203.74.9.62 <br>
<tt>REMOTE_PORT </tt>64731 </blockquote></html>

--=====================_64945825==_.ALT--



From dereks@kd-dev.com  Thu Jun 22 15:59:13 2000
From: dereks@kd-dev.com (Derek Simkowiak)
Date: Thu, 22 Jun 2000 07:59:13 -0700 (PDT)
Subject: [Mailman-Users] Re: [Mailman-Developers] New beta release needed
 (+ little patch)
In-Reply-To: <14672.58167.653957.234326@anthem.concentric.net>
Message-ID: <Pine.LNX.4.04.10006220758020.13822-100000@archer.kd-dev.com>

	Will the new release fix the broken-archiving-if-using-resend-date
bug?  (I'm not sure that ever got entered into the bug tracking database;
I never entered it)

--Derek


On Wed, 21 Jun 2000, Barry A. Warsaw wrote:

-> 
-> >>>>> "BR" == Bernhard Reiter <bernhard@intevation.de> writes:
-> 
->     BR> It looks like a new mailman beta or even pre beta release is
->     BR> badly needed. I had to make to many little adjustments to
->     BR> 2.0b2.  (Also see my mail to mailman-users in April.)
-> 
-> There will be one very soon now (within hours or at most a day).  I
-> was all set to push the button and we saw errors in the logs on
-> python.org, and duplicates in the digests.  I want to see if I can fix
-> that problem first.
-> 
-> -Barry
-> 
-> ------------------------------------------------------
-> Mailman-Users maillist  -  Mailman-Users@python.org
-> http://www.python.org/mailman/listinfo/mailman-users
-> 



From fife@AnywhereYouGo.com  Thu Jun 22 18:17:51 2000
From: fife@AnywhereYouGo.com (Ryan Fife)
Date: Thu, 22 Jun 2000 12:17:51 -0500
Subject: [Mailman-Developers] including subscribe address in message
Message-ID: <20000622121751.E8010@AnywhereYouGo.com>

Before I start looking into this I thought I'd check to see if it's already
been done/investigated.

I would like to include a line that says:

You are subscribed as: fife@AnwyhereYouGo.com

in the body of the message on the way out.  I know it will increase the
needed processing of messages tremendously, but it would be good for our
subscribers as well as the list admin (me!).  Our mail server doesn't have
anything better to do anyway...

-- 
Ryan Fife
fife@AnywhereYouGo.com
 Creators of the world's first online WAP testing tool:
 http://www.AnywhereYouGo.com/Content.po?name=lab/About


From chuqui@plaidworks.com  Thu Jun 22 18:20:03 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 22 Jun 2000 10:20:03 -0700
Subject: [Mailman-Developers] including subscribe address in
 message
In-Reply-To: <20000622121751.E8010@AnywhereYouGo.com>
References: <20000622121751.E8010@AnywhereYouGo.com>
Message-ID: <p04320401b577fb1b27ee@[17.216.27.193]>

At 12:17 PM -0500 6/22/2000, Ryan Fife wrote:
>Before I start looking into this I thought I'd check to see if it's already
>been done/investigated.
>
>I would like to include a line that says:
>
>You are subscribed as: fife@AnwyhereYouGo.com
>
>in the body of the message on the way out.

That requires extensions to the delivery stuff for what's known as 
VERPing. mailman doesn't do this yet.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From claw@kanga.nu  Thu Jun 22 20:23:12 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 22 Jun 2000 12:23:12 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Domain allowed to post to a list.
In-Reply-To: Message from Evilio del Rio <edelrio@icm.csic.es>
 of "Thu, 22 Jun 2000 10:18:32 EST." <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>
References: <Pine.LNX.4.10.10006220950120.13899-100000@haddock.icm.csic.es>
Message-ID: <660.961701792@kanga.nu>

On Thu, 22 Jun 2000 10:18:32 +0200 (CEST) 
Evilio del Rio <edelrio@icm.csic.es> wrote:

> Now the good news: it is easy to patch Mailman to accept a regular
> expression as the "posters" settings (addresses allowed to post to
> a restricted list even if they are not members). I have patched
> the following file:

Oooo.  This one should get into the next beta.  A whole bunch of
people would be very happy to see that.  Barry?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jarrell@vt.edu  Thu Jun 22 20:31:40 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Thu, 22 Jun 2000 15:31:40 -0400
Subject: [Mailman-Developers] Bug still in current CVS
In-Reply-To: <39513831.A47AB59F@west.sun.com>
Message-ID: <4.3.2.7.2.20000622152601.00dfbab0@vtserf.cc.vt.edu>

--=====================_27531745==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 02:48 PM 6/21/00 -0700, Dan Mick wrote:
>I had to fix this bug, which was reported in May, before I could use the current
>CVS:
>
>dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
>182c182
><             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
>---
>>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)
>
>Could someone with putback access clean this up, please?


Um, Dan, you sure you have the current CVS files?  I remember putting a very similar
fix in a couple of weeks ago that Barry committed.  And, in fact, that entire section
of code that used DeliverToList isn't in the current ListAdmin any more...

I show the current version of ListAdmin.py as being 1.41.  Looks like, from the log
messages that Barry put my patch in back in 1.33 on 5/30, then removed the entire
block of code when he switched to queueing admin requests, rather than delivering them
realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...

--=====================_27531745==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:48 PM 6/21/00 -0700, Dan Mick wrote:<br>
<blockquote type=cite cite>I had to fix this bug, which was reported in
May, before I could use the current<br>
CVS:<br>
<br>
dmick@we-24-30-117-227&gt; diff ListAdmin.py.orig ListAdmin.py<br>
182c182<br>
&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)<br>
---<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)<br>
<br>
Could someone with putback access clean this up,
please?</blockquote><br>
<br>
Um, Dan, you sure you have the current CVS files?&nbsp; I remember
putting a very similar<br>
fix in a couple of weeks ago that Barry committed.&nbsp; And, in fact,
that entire section<br>
of code that used DeliverToList isn't in the current ListAdmin any
more...<br>
<br>
I show the current version of ListAdmin.py as being 1.41.&nbsp; Looks
like, from the log<br>
messages that Barry put my patch in back in 1.33 on 5/30, then removed
the entire<br>
block of code when he switched to queueing admin requests, rather than
delivering them<br>
realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...<br>
</font></html>

--=====================_27531745==_.ALT--



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 22 22:07:17 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 14:07:17 -0700 (PDT)
Subject: [Mailman-Developers] Fwd: Mailman error messages.
Message-ID: <200006222106.OAA21493@utopia.west.sun.com>

> >IOError: [Errno 13] Permission denied: '/home/mailman/logs/error'

So this makes the problem pretty clear; the permissions on the error
log are incorrect.  Yes?



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 22 22:09:19 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 14:09:19 -0700 (PDT)
Subject: [Mailman-Developers] including subscribe address in message
Message-ID: <200006222108.OAA21601@utopia.west.sun.com>

There's been a *lot* of discussion about similar things wrt MLMs in
general (qmail/ezmlm call this "VERP").

What it means is you must send N different messages, where N is
the number of subscribers on your list, whereas now you send
1 message with M connections, where M is usually significantly
less than M.  So you drastically increase both filesystem and
network load to do something like this.

Mailman doesn't currently support anything like this, although
a custom Handlers/ module in 2.x will make it a lot easier to 
drop such a thing in, from what I can tell.

> Before I start looking into this I thought I'd check to see if it's already
> been done/investigated.
> 
> I would like to include a line that says:
> 
> You are subscribed as: fife@AnwyhereYouGo.com
> 
> in the body of the message on the way out.  I know it will increase the
> needed processing of messages tremendously, but it would be good for our
> subscribers as well as the list admin (me!).  Our mail server doesn't have
> anything better to do anyway...



From Dan Mick <Dan.Mick@west.sun.com>  Thu Jun 22 22:14:17 2000
From: Dan Mick <Dan.Mick@west.sun.com> (Dan Mick)
Date: Thu, 22 Jun 2000 14:14:17 -0700 (PDT)
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <200006222113.OAA21753@utopia.west.sun.com>

> At 02:48 PM 6/21/00 -0700, Dan Mick wrote:
> >I had to fix this bug, which was reported in May, before I could use the 
current
> >CVS:
> >
> >dmick@we-24-30-117-227> diff ListAdmin.py.orig ListAdmin.py
> >182c182
> ><             enqueue = HandlerAPI.DeliverToList(self, msg, newdata=msgdata)
> >---
> >>             enqueue = HandlerAPI.DeliverToList(self, msg, msgdata)
> >
> >Could someone with putback access clean this up, please?
> 
> 
> Um, Dan, you sure you have the current CVS files?  I remember putting a very 
similar
> fix in a couple of weeks ago that Barry committed.  And, in fact, that entire 
section
> of code that used DeliverToList isn't in the current ListAdmin any more...
> 
> I show the current version of ListAdmin.py as being 1.41.  Looks like, from 
the log
> messages that Barry put my patch in back in 1.33 on 5/30, then removed the 
entire
> block of code when he switched to queueing admin requests, rather than 
delivering them
> realtime, in 1.34 on 5/31... So you're at *least* 7 revs back...

I have version 1.31 from 5/8/2000.  This is after I've run
a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...

Cripes, I'm surprised the thing is running at all...



From jarrell@vt.edu  Thu Jun 22 22:41:34 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Thu, 22 Jun 2000 17:41:34 -0400
Subject: [Mailman-Developers] Bug still in current CVS
In-Reply-To: <200006222113.OAA21753@utopia.west.sun.com>
Message-ID: <4.3.2.7.2.20000622173845.00d6ac90@vtserf.cc.vt.edu>

--=====================_35321565==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 02:14 PM 6/22/00 -0700, Dan Mick wrote:
>I have version 1.31 from 5/8/2000.  This is after I've run
>a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...
>
>Cripes, I'm surprised the thing is running at all...


Look in $mailmansrc/CVS/Root

Are you pointed at ":pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman" ?

Barry moved the cvs repository a while back.  Even if you knew that, it's possible you
didn't get the change in; I tried to switch without blowing away, and it didn't take on
one server.  I ended up rm -rf'ing the entire source tree, and checking it out again from
sourceforge, after which I was fine.





--=====================_35321565==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:14 PM 6/22/00 -0700, Dan Mick wrote:<br>
<blockquote type=cite cite>I have version 1.31 from 5/8/2000.&nbsp; This
is after I've run<br>
a &quot;cvs update&quot;.&nbsp; Hmm.&nbsp; Maybe I don't understand CVS
well enough...<br>
<br>
Cripes, I'm surprised the thing is running at
all...</font></blockquote><br>
<br>
Look in $mailmansrc/CVS/Root<br>
<br>
Are you pointed at
&quot;:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman&quot;
?<br>
<br>
Barry moved the cvs repository a while back.&nbsp; Even if you knew that,
it's possible you<br>
didn't get the change in; I tried to switch without blowing away, and it
didn't take on<br>
one server.&nbsp; I ended up rm -rf'ing the entire source tree, and
checking it out again from<br>
sourceforge, after which I was fine.<br>
<br>
<br>
<br>
<br>
</html>

--=====================_35321565==_.ALT--



From Dan Mick <Dan.Mick@West.Sun.COM>  Fri Jun 23 02:54:45 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 18:54:45 -0700 (PDT)
Subject: [Mailman-Developers] Bug still in current CVS
Message-ID: <200006230154.SAA04041@utopia.west.sun.com>

> X-Sender: jarrell@vtserf.cc.vt.edu
> Date: Thu, 22 Jun 2000 17:41:34 -0400
> To: Dan Mick <Dan.Mick@west.sun.com>, Dan.Mick@west.sun.com, 
mailman-developers@python.org, jarrell@vt.edu
> From: Ron Jarrell <jarrell@vt.edu>
> Subject: Re: [Mailman-Developers] Bug still in current CVS
> 
> At 02:14 PM 6/22/00 -0700, Dan Mick wrote:
> >I have version 1.31 from 5/8/2000.  This is after I've run
> >a "cvs update".  Hmm.  Maybe I don't understand CVS well enough...
> >
> >Cripes, I'm surprised the thing is running at all...
> 
> 
> Look in $mailmansrc/CVS/Root
> 
> Are you pointed at 
":pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman" ?

Too smart for my own good.  I tried to re-root by changing
$mailmansrc/CVS/Root, but it turns out there's a CVS directory
in every subdirectory, so while things in the top level were coming
from Sourceforge, things in the lower levels were still coming
from python.org.

Eeek, now I've got a mongrel Mailman running.  Wish me luck as I
try to dig out of this one!...

Ignore my bug reports from yesterday; they're probably all 
bogus.



From Dan Mick <Dan.Mick@west.sun.com>  Fri Jun 23 03:13:02 2000
From: Dan Mick <Dan.Mick@west.sun.com> (Dan Mick)
Date: Thu, 22 Jun 2000 19:13:02 -0700 (PDT)
Subject: [Mailman-Developers] SMTPDirect doesn't log to 'posts'
Message-ID: <200006230212.TAA04377@utopia.west.sun.com>

> Just decided to be brave and install the current 2.0 CVS on top of my 1.1
> list.  So far so good....but I see no posts in "logs/post".  Is this 
> intentional with SMTPDirect (the default Handler), and if so, why?
> post is a useful little log to make sure things are getting through.

So, with the *real* CVS, this seems to really be true; Barry,
is this an oversight, or should SMTPDirect.py be logging something
to 'post'?



From Dan Mick <Dan.Mick@West.Sun.COM>  Fri Jun 23 04:05:34 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 22 Jun 2000 20:05:34 -0700 (PDT)
Subject: [Mailman-Developers] Locking (oh no!)
Message-ID: <200006230304.UAA05357@utopia.west.sun.com>

So, with the latest CVS (really, I swear this time), it seems
trivial for me to create a locking deadlock.  This has happened
four times in the last five minutes.  

Scenario:

1) go to admin/ link
2) while admin page is downloading, go to admindb/ link (on same
page)

The admin process dies, but still holds the lock; the admindb process
spins waiting for the lock.

Granted, it's easier for me than some to get to admindb while admin
is still downloading, but...

Is something about the browser/webserver combination killing admin
in such a way so that its lock cleanup stuff isn't working?
Who's supposed to clean up the lock if the process dies an early
death for some reason?  (Or is this where the lock has to be 
broken?)




From smead@amplepower.com  Fri Jun 23 06:00:53 2000
From: smead@amplepower.com (David Smead)
Date: Thu, 22 Jun 2000 22:00:53 -0700 (PDT)
Subject: [Mailman-Developers] Locking (oh no!)
In-Reply-To: <200006230304.UAA05357@utopia.west.sun.com>
Message-ID: <Pine.LNX.4.10.10006222144220.10454-100000@henry.amplepower.com>

Dan,

I exchanged a few emails with Harald Meland on the lock problem.  I've
used the fntl package under python with success, however, I understand
that mailman is using the link file system as an atomic command.  BTW I
read recently that the Linux kernel is going to change its behavior for
link in the next release, so that may be a problem waiting to arrive.

I've meant to take a look at the locking code, but after losing my disk
drive on my prime workbox I've been wrapped around the axle instead.
My first suggestion, which may already be the case, is to have one place
where locks and unlocks occur in the code.

But, since a process can always be killed, or die from who knows what, a
final solution has to be a `lock server', where a process that connects to
the server can request a lock or unlock, and a granted lock has an
expiration time after which it is released and a subsequent call to unlock
from the owner is ignored.  As long as stale locks are cleaned when the
system is rebooted, (when the lock server is started or restarted), then
things should be about as robust as possible.

Performance will take a hit with the server approach, but doesn't it
always when robust behavior is demanded?

If I get my workbox here back up to speed tomorrow, I'll try to look into
the lock problem some more.


Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Thu, 22 Jun 2000, Dan Mick wrote:

> So, with the latest CVS (really, I swear this time), it seems
> trivial for me to create a locking deadlock.  This has happened
> four times in the last five minutes.  
> 
> Scenario:
> 
> 1) go to admin/ link
> 2) while admin page is downloading, go to admindb/ link (on same
> page)
> 
> The admin process dies, but still holds the lock; the admindb process
> spins waiting for the lock.
> 
> Granted, it's easier for me than some to get to admindb while admin
> is still downloading, but...
> 
> Is something about the browser/webserver combination killing admin
> in such a way so that its lock cleanup stuff isn't working?
> Who's supposed to clean up the lock if the process dies an early
> death for some reason?  (Or is this where the lock has to be 
> broken?)
> 
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
> 



From Nigel.Metheringham@VData.co.uk  Fri Jun 23 09:23:42 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 23 Jun 2000 09:23:42 +0100
Subject: [Mailman-Developers] including subscribe address in
 message
In-Reply-To: Message from Ryan Fife <fife@AnywhereYouGo.com>
 of "Thu, 22 Jun 2000 12:17:51 CDT." <20000622121751.E8010@AnywhereYouGo.com>
Message-ID: <E135OkY-00054x-00@rioja.localnet>

fife@AnywhereYouGo.com said:
> I would like to include a line that says:
> You are subscribed as: fife@AnwyhereYouGo.com

Ugh.

If you use exim (and what sane person wouldn't [*]), then you could 
modify your list handling so that a dedicated transport is used for 
outgoing list SMTP.  This transport could have the maximum recipients 
set to one, and add a header to each message - say seomthing like
	X-List-Subscription-Address: fife@AnwyhereYouGo.com

	Nigel.

[*] OK, a little too much flame bait for no good reason, but hey its a 
nice
    morning here :-)

-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From ckolar@admin.aurora.edu  Fri Jun 23 16:07:15 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Fri, 23 Jun 2000 10:07:15 -0500
Subject: [Mailman-Developers] implicit destination message?
Message-ID: <4.3.2.7.2.20000623100529.00b5cc20@admin.aurora.edu>

Hi everyone.  I recently received a note from a person strongly suggesting 
that error messages be put into the documentation.  Is there a place where 
the error messages are all laid out so that I could whack together 
descriptions?  He was particularly disturbed by the "implicit destination" 
error.  Cheers,

--chris



From fife@AnywhereYouGo.com  Fri Jun 23 17:36:51 2000
From: fife@AnywhereYouGo.com (Ryan Fife)
Date: Fri, 23 Jun 2000 11:36:51 -0500
Subject: [Mailman-Developers] including subscribe address in message
In-Reply-To: <E135OkY-00054x-00@rioja.localnet>; from Nigel.Metheringham@vdata.co.uk on Fri, Jun 23, 2000 at 09:23:42AM +0100
References: <fife@AnywhereYouGo.com> <E135OkY-00054x-00@rioja.localnet>
Message-ID: <20000623113651.B21268@AnywhereYouGo.com>

This sounds like a good interim solution.  The only problem I see is that
you are still dealing with people that don't understand headers and such
so you'll have to either:

a) explain how to find their subscription address out using headers
b) have them forward you the message

The latter one is *definitely* the least time consuming for a list admin!

Thanks to everyone for the good responses...I guess my last question/comment
is:

Anyone planning on working on VERPing capabilities (woohoo - using a term
I just learned!)?  I would love to do this, but realize that my time
limitations over the next month or so are quite tight so I probably won't
get to it - I could definitely help out if someone else was leading the
effort, however.

If not, I'll still look into it - just don't expect to see anything soon!

Thanks again,

On Fri, Jun 23, 2000 at 09:23:42AM +0100, Nigel Metheringham wrote:
> 
> fife@AnywhereYouGo.com said:
> > I would like to include a line that says:
> > You are subscribed as: fife@AnwyhereYouGo.com
> 
> Ugh.
> 
> If you use exim (and what sane person wouldn't [*]), then you could 
> modify your list handling so that a dedicated transport is used for 
> outgoing list SMTP.  This transport could have the maximum recipients 
> set to one, and add a header to each message - say seomthing like
> 	X-List-Subscription-Address: fife@AnwyhereYouGo.com
> 
> 	Nigel.
> 
> [*] OK, a little too much flame bait for no good reason, but hey its a 
> nice
>     morning here :-)
> 
> -- 
> [ - Opinions expressed are personal and may not be shared by VData - ]
> [ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
> [ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
> 

-- 
Ryan Fife
fife@AnywhereYouGo.com
 Creators of the world's first online WAP testing tool:
 http://www.AnywhereYouGo.com/Content.po?name=lab/About


From hniksic@iskon.hr  Fri Jun 23 17:40:27 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 23 Jun 2000 18:40:27 +0200
Subject: [Mailman-Developers] Virtual hosts/domains in mailman
In-Reply-To: "Stu Ekins"'s message of "Wed, 14 Jun 2000 14:56:34 +0100"
References: <BJEKLFPEBALNOFGGKCJACECDCAAA.stu@ekins.net>
Message-ID: <dp3dm473lw.fsf@mraz.iskon.hr>

"Stu Ekins" <stu@ekins.net> writes:

> Mailman has an option in the list admin pages, which says something
> like "domain name this list prefers". Specify "bar.net" in here, and
> bob should be your mother's brother...

This works.  Thanks!


From jeremy@beopen.com  Fri Jun 23 17:43:20 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 23 Jun 2000 12:43:20 -0400 (EDT)
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: <183765175@toto.iv>
Message-ID: <14675.37800.89133.686560@localhost.localdomain>

Speaking as a non-expert, these changes sound good reasonable.  Do
robots other than htdig understand these meta tags?

Jeremy


From Nigel.Metheringham@VData.co.uk  Fri Jun 23 18:15:07 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Fri, 23 Jun 2000 18:15:07 +0100
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: Message from Jeremy Hylton <jeremy@beopen.com>
 of "Fri, 23 Jun 2000 12:43:20 EDT." <14675.37800.89133.686560@localhost.localdomain>
Message-ID: <E135X2p-0006Qp-00@rioja.localnet>

jeremy@beopen.com said:
> Speaking as a non-expert, these changes sound good reasonable.  Do
> robots other than htdig understand these meta tags? 

I only mentioned them at all because they are supposed to be a generic 
standard... what uses them is a different question.

The URL I quoted was for webcrawler, so that does use those metas.. 
unless there is good reason to do otherwise I'd like to throw my weight 
behind making a reason for other engines to take up those metas.

I have a test implementation in use - will submit patches soon.

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]




From claw@kanga.nu  Fri Jun 23 18:58:42 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 23 Jun 2000 10:58:42 -0700
Subject: [Mailman-Developers] including subscribe address in message
In-Reply-To: Message from Nigel Metheringham <Nigel.Metheringham@VData.co.uk>
 of "Fri, 23 Jun 2000 09:23:42 +0100." <E135OkY-00054x-00@rioja.localnet>
References: <E135OkY-00054x-00@rioja.localnet>
Message-ID: <16632.961783122@kanga.nu>

On Fri, 23 Jun 2000 09:23:42 +0100 
Nigel Metheringham <Nigel.Metheringham@VData.co.uk> wrote:

> fife@AnywhereYouGo.com said:
>> I would like to include a line that says: You are subscribed as:
>> fife@AnwyhereYouGo.com

> If you use exim (and what sane person wouldn't [*]), then you
> could modify your list handling so that a dedicated transport is
> used for outgoing list SMTP.  This transport could have the
> maximum recipients set to one, and add a header to each message -
> say seomthing like X-List-Subscription-Address:
> fife@AnwyhereYouGo.com

Ooo!  Oooo!  Who is going to be the first to write the stanza for
this (or has it been done already)?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From claw@kanga.nu  Fri Jun 23 19:01:08 2000
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 23 Jun 2000 11:01:08 -0700
Subject: [Mailman-Developers] Indexing pipermail archives
In-Reply-To: Message from Jeremy Hylton <jeremy@beopen.com>
 of "Fri, 23 Jun 2000 12:43:20 EDT." <14675.37800.89133.686560@localhost.localdomain>
References: <14675.37800.89133.686560@localhost.localdomain>
Message-ID: <16696.961783268@kanga.nu>

On Fri, 23 Jun 2000 12:43:20 -0400 (EDT) 
Jeremy Hylton <jeremy@beopen.com> wrote:

> Speaking as a non-expert, these changes sound good reasonable.  Do
> robots other than htdig understand these meta tags?

My experience, from watching my Apache logs (I'm very well indexed),
is that ALL of the commercial search engine spiders and robots
honour both robots.txt and the robots meta tag.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jim@cosource.com  Fri Jun 23 23:41:30 2000
From: jim@cosource.com (Jim Hebert)
Date: Fri, 23 Jun 2000 18:41:30 -0400 (EDT)
Subject: [Mailman-Developers] bug in changing subscription options
Message-ID: <Pine.LNX.4.10.10006231835470.18082-100000@ray.compu-aid.com>

While trying to make a change (trying to set 'nomail' basically) via the
web interface, for my subscription to mailman-users, I got

We're sorry, we hit a bug!

Mailman experienced a very low level failure and could not even generate a
useful traceback for you. Please report this to the Mailman
administrator at this site. 

Got it after submitting my password, which has a requisite amount of wierd
characters in it. =) Linux 2.2, Netscape 4.73, no proxies, accepting
cookies, etc., ie pretty normal setup on my end.

(I haven't been following closely, so sorry if this is a known problem in
the snapshot that is running that list.)

jim

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox



From chuqui@plaidworks.com  Mon Jun 26 06:54:44 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 25 Jun 2000 22:54:44 -0700
Subject: [Mailman-Developers] beta 3?
Message-ID: <p04320403b57ca081a9eb@[209.239.169.197]>

How close are we to b3?

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From jarrell@vt.edu  Mon Jun 26 21:17:30 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Mon, 26 Jun 2000 16:17:30 -0400 (EDT)
Subject: [Mailman-Developers] Bug in admindb.py (with patch)
Message-ID: <200006262017.QAA17608@babylon5.cc.vt.edu>

(Ok, actually, a typo; Barry forgot an argument)


Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.28
diff -r1.28 admindb.py
69c69
<         syslog('No such list "%s": %s\n' % (listname, e))
---
>         syslog('error','No such list "%s": %s\n' % (listname, e))




From jarrell@vtserf.cc.vt.edu  Mon Jun 26 22:36:33 2000
From: jarrell@vtserf.cc.vt.edu (Ron Jarrell)
Date: Mon, 26 Jun 2000 17:36:33 -0400
Subject: [Mailman-Developers] admindb.py bug and patch again...
Message-ID: <200006262136.RAA13425@vtserf.cc.vt.edu>

I sent this in earlier today, from my main account, but never saw
it on the list... Nor, interestingly, is the list willing to send
me my password (although it claims to); at least I haven't
gotten it after waiting a while.  I'm getting other people's messages
from the list, so I'm sending this again from an alternate account,
as a test to see if python.org is unhappy with my main one..

Anyway, there's a bug in admindb.py that crops up when you try to
feed it an illegal address.  syslog is missing an arg.  Here's
the simple patch:

Index: admindb.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v
retrieving revision 1.28
diff -r1.28 admindb.py
69c69
<         syslog('No such list "%s": %s\n' % (listname, e))
---
>         syslog('error','No such list "%s": %s\n' % (listname, e))




From bwarsaw@python.org  Tue Jun 27 06:34:14 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 01:34:14 -0400 (EDT)
Subject: [Mailman-Developers] Bug in admindb.py (with patch)
References: <200006262017.QAA17608@babylon5.cc.vt.edu>
Message-ID: <14680.15574.891360.487372@anthem.concentric.net>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> (Ok, actually, a typo; Barry forgot an argument)

Yep, and thanks!
-Barry


From bwarsaw@python.org  Tue Jun 27 14:25:01 2000
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Tue, 27 Jun 2000 09:25:01 -0400 (EDT)
Subject: [Mailman-Developers] admindb.py bug and patch again...
References: <200006262136.RAA13425@vtserf.cc.vt.edu>
Message-ID: <14680.43821.664101.476397@anthem.concentric.net>

>>>>> "RJ" == Ron Jarrell <jarrell@vtserf.cc.vt.edu> writes:

    RJ> I sent this in earlier today, from my main account, but never
    RJ> saw it on the list... Nor, interestingly, is the list willing
    RJ> to send me my password (although it claims to); at least I
    RJ> haven't gotten it after waiting a while.  I'm getting other
    RJ> people's messages from the list, so I'm sending this again
    RJ> from an alternate account, as a test to see if python.org is
    RJ> unhappy with my main one..

What appears to have happened is that some upstream newsfeed was
re-injecting comp.lang.python, which the Mailman gateway dutifully
forwarded to python-list.  This ended up swamping the python.org mail
system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there are
still 50k+ messages in Postfix's outgoing queue.

Things are starting to clear up though.
-Barry


From jarrell@vt.edu  Tue Jun 27 18:24:54 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 27 Jun 2000 13:24:54 -0400
Subject: [Mailman-Developers] admindb.py bug and patch again...
In-Reply-To: <14680.43821.664101.476397@anthem.concentric.net>
References: <200006262136.RAA13425@vtserf.cc.vt.edu>
Message-ID: <4.3.2.7.2.20000627132420.05b24540@vtserf.cc.vt.edu>

--=====================_72977361==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 09:25 AM 6/27/00 -0400, Barry A. Warsaw wrote:

>What appears to have happened is that some upstream newsfeed was
>re-injecting comp.lang.python, which the Mailman gateway dutifully
>forwarded to python-list.  This ended up swamping the python.org mail
>system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there are
>still 50k+ messages in Postfix's outgoing queue.

Yea, I started seeing my messages several hours later...  Ah, the joys of
running a server...
--=====================_72977361==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 09:25 AM 6/27/00 -0400, Barry A. Warsaw wrote:<br>
<br>
<blockquote type=cite cite>What appears to have happened is that some
upstream newsfeed was<br>
re-injecting comp.lang.python, which the Mailman gateway dutifully<br>
forwarded to python-list.&nbsp; This ended up swamping the python.org
mail<br>
system pretty badly; as of just now 09:24 EDT 27-Jun-2000, there 
are<br>
still 50k+ messages in Postfix's outgoing queue.</blockquote><br>
Yea, I started seeing my messages several hours later...&nbsp; Ah, the
joys of<br>
running a server...</font></html>

--=====================_72977361==_.ALT--



From brian@gweep.bc.ca  Tue Jun 27 18:09:38 2000
From: brian@gweep.bc.ca (Brian Edmonds)
Date: 27 Jun 2000 10:09:38 -0700
Subject: [Mailman-Developers] announcement list option
In-Reply-To: Chuq Von Rospach's message of "Sun, 25 Jun 2000 22:54:44 -0700"
Message-ID: <m3og4n82zx.fsf@yuri.gweep.bc.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've mentioned this before, but having used Mailman for longer I'd like
to bring it up again, as I think I have a better grasp on how it might
be integrated with the existing software.  Unfortunately I still haven't
learned Python, so my ability to hack the code myself is somewhat
limited.

Anyhow, in some of my current lists, which I'd like to migrate to
mailman, I have them set up with the usual regular and digest options,
but also have an announce option.  Mail sent to the announce list goes
to all regular subscribers, as well as immediately to all digest
subscribers (rather than being digested), and also to a third list of
announcement only subscribers.  In order to migrate these lists to
Mailman I simply have to have this functionality.

I would thus envision the following changes:
 1) An announce list option added to the subscription and member
    management HTML interfaces (and subscription database, obviously).
    Operation when both digest and announce are selected would be as if
    just digest were selected, since announce is already a subset of
    digest.
 2) An option on the regular list config interface (or an additional
    interface perhaps, like the digest one) to enable or disable the
    announce option, much like digest can be.  Also options to enable or
    disable posting priviledges to the announce list (some are
    controlled, at least one I run is on the honour system), as well as
    specifying a list of accepted posters.  Non-priviledged posters
    would be held for approval using the usual mechanism.
 3) A flag to the posting software that indicates a post is an
    announcement, which would then be sent immediately to all non-nomail
    subscribers.  An update to newlist to prompt for inclusion of an
    -announce alias (which would pass this new flag) would also be a
    good idea.

Brian.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE5WN/OcCEFQUX5+OwRAgdnAJ0aN0GWnEQa4LFMS9DesAPh80N+QACfYJie
mK3m0Kdka+wvxIacUFso2J8=
=wuyG
-----END PGP SIGNATURE-----



From goisman@physics.Arizona.EDU  Wed Jun 28 16:30:09 2000
From: goisman@physics.Arizona.EDU (Philip Goisman)
Date: Wed, 28 Jun 2000 08:30:09 -0700 (MST)
Subject: [Mailman-Developers] umbrella lists - restricted
Message-ID: <200006281530.IAA21902@electron.physics.arizona.edu>

Dear Developers,

	I'd like to request that mailman umbrella lists include
the restricted (closed) feature available to standalone mailman
lists.  Currently, moderation is required if a member of a 
sublist trys to post to its umbrella list.  To administer an
all inclusive restricted umbrella list with selected posters, I
presently have to maintain a separate all inclusive (umbrella list)
mailing list that duplicates the names of everyone in my lists I
would like to keep under an umbrella list.

Thank you for your consideration of this request.

Regards,

	Philip


From bwarsaw@beopen.com  Wed Jun 28 19:47:47 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 28 Jun 2000 14:47:47 -0400 (EDT)
Subject: [Mailman-Developers] beta 3?
References: <p04320403b57ca081a9eb@[209.239.169.197]>
Message-ID: <14682.18515.929813.463810@anthem.concentric.net>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> How close are we to b3?

Wonderful question, for which I now have an answer. :)

I've actually spun the tarball 3 times in the last two weeks, but have
delayed releasing it because I'd been seeing some perplexing problems
on python.org.  There was a data consistency bug which had me quite
stumped.  It dawned on me last night what the problem was, and I just
checked in a patch for it.  Very nasty bug, but easy to fix.

So once again I am going to spin the tarballs for beta 3.  I plan on
watching the logs very closely over the next 18 hours or so and if
everything looks good, I'll push the button tomorrow morning.  I'm
confident (but crossing my fingers anyway) that I have fixed this
problem.  See the checkin messages for details.

-Barry


From chuqui@plaidworks.com  Wed Jun 28 20:31:00 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Wed, 28 Jun 2000 12:31:00 -0700
Subject: [Mailman-Developers] beta 3?
In-Reply-To: <14682.18515.929813.463810@anthem.concentric.net>
References: <p04320403b57ca081a9eb@[209.239.169.197]>
 <14682.18515.929813.463810@anthem.concentric.net>
Message-ID: <p04320401b580029f4841@[17.216.27.193]>

At 2:47 PM -0400 6/28/00, Barry A. Warsaw wrote:
>It dawned on me last night what the problem was, and I just
>checked in a patch for it.  Very nasty bug, but easy to fix.

God, I love those.

I'm working on an internal system that I hope to finish today. it's 
been ongoing for weeks, and the end system is going to be maybe 200 
lines of perl code. Maybe.

And thefirst time someone says "why did it take you so long to write 
200 lines of Perl", I'll laugh and say "because it took me this long 
to figure out how to NOT write 2,000 lines of Perl"

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From ricardo@rixhq.nu  Thu Jun 29 07:22:48 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 29 Jun 2000 08:22:48 +0200
Subject: [Mailman-Developers] b3 not working anymore?
Message-ID: <20000629082248.C688@miss-janet.com>

Hi,

I'm running the latest cvs (just updated again this morning just to be sure)
but their doesn't seem to be any more posts being send out on the list??
they all arrive on the approval page, but once approved they vanish into
nothing... I'm not sure how long this has been going on though...
anybody else having the same trouble?

Ricardo.

--



From bwarsaw@beopen.com  Thu Jun 29 07:45:23 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 02:45:23 -0400 (EDT)
Subject: [Mailman-Developers] b3 not working anymore?
References: <20000629082248.C688@miss-janet.com>
Message-ID: <14682.61571.230240.875717@anthem.concentric.net>

>>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:

    RK> I'm running the latest cvs (just updated again this morning
    RK> just to be sure) but their doesn't seem to be any more posts
    RK> being send out on the list??  they all arrive on the approval
    RK> page, but once approved they vanish into nothing... I'm not
    RK> sure how long this has been going on though...  anybody else
    RK> having the same trouble?

Take a look in the qfiles directory.  Do you see a bunch of files with
really long names and extensions .msg and .db?  You must reload the
crontab.in file to get all the new cron scripts running at the right
intervals.  Of primary importance is qrunner which clears the messages
waiting in qfiles.

This is documented in the UPGRADING file, which I know no one will
read.  Be prepared to answer this question over and over again. ;)

-Barry



From bwarsaw@beopen.com  Thu Jun 29 07:55:12 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 02:55:12 -0400 (EDT)
Subject: [Mailman-Developers] Announcing Mailman 2.0 beta 3
Message-ID: <14682.62160.749684.66627@anthem.concentric.net>

Okay folks, I am finally releasing Mailman 2.0 beta 3.  I think I have
nailed the duplicates problem -- at least I have seen no duplicates in
the last 24 hours on python.org, so I'm feeling good about it (we'll
see if that lasts tomorrow morning :).

Please give this version a thorough test; I'd like to have a much
shorter release cycle for the next few betas.  I am aiming to release
2.0 final on July 14th, the Friday before the O'Reilly OSSCON.  I plan
on spending time between now and then on slogging through the
discussion lists and bug reports, and working on the documentation.

See below for an excerpt from the NEWS file for changes since
2.0beta2.  If you have not been following the CVS updates and are
upgrading from 2.0 beta 2 or earlier PLEASE READ THE UPGRADING FILE!
A crucial step is to reload your crontab.in file, otherwise you won't
clear your message queue often enough (or perhaps not at all).

Enjoy,
-Barry

-------------------- snip snip --------------------
2.0 beta 3 (26-Jun-2000)

    - Delivery mechanism (qrunner) refined to support immediate
      queuing, queuing directly from MTA, and queuing on any error
      along the delivery pipeline.  This means 1) that huge lists
      can't time out the MTA's program delivery channel; 2) it is much
      harder to completely lose messages; 3) eventually, qrunner will
      be elaborated to meter delivery to the MTA so as not to swamp
      it.  The tradeoff is in more disk I/O since every message coming
      into the system (and most that are generated by the system) live
      on disk for some part of their journey through Mailman.

      For now, see the Default.py variables QRUNNER_PROCESS_LIFETIME
      and QRUNNER_MAX_MESSAGES for primitive resource management.

      The API to the pipeline handler modules has changed.  See
      Mailman/Handlers/HandlerAPI.py for details.

    - Revamped admindb web page: held messages are split into headers
      and bodies so they are easier to vette; admins can now also
      preserve a held message (for spam evidence gathering) or forward
      the message to a specified email address; disposition of held
      messages can be deferred; held messages have a more context
      meaningful default rejection message.

    - Change to the semantics for `acceptable_aliases' list
      configuration variable, based on suggestions by Harald Meland.

    - New mm_cfg.py variables NNTP_USERNAME and NNTP_PASSWORD can be
      set on a site-wide basis if connection to your nntpd requires
      authentication.

    - The list attribute `num_spawns' has been removed.  The mm_cfg.py
      variables MAX_SPAWNS, and DEFAULT_NUM_SPAWNS removed too.

    - LIST_LOCK_LIFETIME cranked to 5 hours and LIST_LOCK_TIMEOUT
      shortened to 10 seconds.  QRUNNER_LOCK_LIFETIME cranked up to 10
      hours.  This should decrease the changes for bogus and harmful
      lock breaking.

    - Resent-to: is now one of the headers checked for explicit
      destinations.

    - Tons more bounce formats are recognized.  The API to the bounce
      modules has changed.

    - A written LockFile module which should fix most (hopefully all)
      bugs in the locking machinery.  Many improvements suggested by
      Thomas Wouters and Harald Meland.

    - Experimental support (disabled by default) for delivering SMTP
      chunks to the MTA via multiple threads.  Your Python executable
      must have been compiled with thread support enabled, and you
      must set MAX_DELIVERY_THREADS in mm_cfg.py.  Note that this may
      not improve your overall system performance.

    - Some changes and additions to scripts: bin/find_member now
      supports a -w/--owner flag to match regexps against mailing list
      owners; bin/find_member now supports multiple regexps;
      cron/gate_news command line option changes; new script
      bin/dumbdb for debugging purposes; bin/clone_member can now also
      remove the old address and change change the list owner
      addresses.

    - The News/Mail gateway admin page has a button that lets you do
      an explicit catchup of the newsgroup.

    - The CVS repository has been moved out to SourceForge.  For more
      information, see the project summary at

      http://sourceforge.net/project/?group_id=103

    - Lots 'o bug fixes and some performance improvements.


From r.kustner@facingfacts.nl  Thu Jun 29 07:58:11 2000
From: r.kustner@facingfacts.nl (Ricardo Kustner)
Date: Thu, 29 Jun 2000 08:58:11 +0200
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jun 29, 2000 at 02:45:23AM -0400
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>
Message-ID: <20000629085811.E688@miss-janet.com>

On Thu, Jun 29, 2000 at 02:45:23AM -0400, Barry A. Warsaw wrote:
> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
>     RK> I'm running the latest cvs (just updated again this morning
>     RK> just to be sure) but their doesn't seem to be any more posts
>     RK> being send out on the list??  they all arrive on the approval
>     RK> page, but once approved they vanish into nothing... I'm not
>     RK> sure how long this has been going on though...  anybody else
>     RK> having the same trouble?
> Take a look in the qfiles directory.  Do you see a bunch of files with
> really long names and extensions .msg and .db?  

no it's empty unfortunately...

> You must reload the
> crontab.in file to get all the new cron scripts running at the right
> intervals.  

i've already fallen in that trap earlier ;) about a month ago my digests
weren't send out for a few days... but since then I've been doing a
crontab update with every cvs upgrade... 


Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com



From claw@kanga.nu  Thu Jun 29 08:02:45 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 00:02:45 -0700
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: Message from Ricardo Kustner <r.kustner@facingfacts.nl>
 of "Thu, 29 Jun 2000 08:58:11 +0200." <20000629085811.E688@miss-janet.com>
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>  <20000629085811.E688@miss-janet.com>
Message-ID: <26341.962262165@kanga.nu>

On Thu, 29 Jun 2000 08:58:11 +0200 
Ricardo Kustner <r.kustner@facingfacts.nl> wrote:

> On Thu, Jun 29, 2000 at 02:45:23AM -0400, Barry A. Warsaw wrote:

>> Take a look in the qfiles directory.  Do you see a bunch of files
>> with really long names and extensions .msg and .db?

> no it's empty unfortunately...

What do your MTA logs say?

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@beopen.com  Thu Jun 29 08:05:24 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 03:05:24 -0400 (EDT)
Subject: [Mailman-Developers] Announcing Mailman 2.0 beta 3
References: <14682.62160.749684.66627@anthem.concentric.net>
Message-ID: <14682.62772.737708.71176@anthem.concentric.net>

Oops, I forgot to tell you how to get the tarball.  You can down load
it from any of these urls:

ftp://www.python.org/pub/mailman/mailman.tar.gz

http://www.list.org/mailman.tar.gz

http://download.sourceforge.net/mailman/mailman-2.0beta3.tgz

It will also hopefully soon be available on ftp.gnu.org.

Cheers, and G'Night. :)
-Barry


From bwarsaw@beopen.com  Thu Jun 29 08:09:52 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 03:09:52 -0400 (EDT)
Subject: [Mailman-Developers] b3 not working anymore?
References: <20000629082248.C688@miss-janet.com>
 <14682.61571.230240.875717@anthem.concentric.net>
 <20000629085811.E688@miss-janet.com>
 <26341.962262165@kanga.nu>
Message-ID: <14682.63040.489790.863488@anthem.concentric.net>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    >> no it's empty unfortunately...

    JCL> What do your MTA logs say?

Also, check logs/errors and logs/smtp.


From ricardo@rixhq.nu  Thu Jun 29 08:24:56 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Thu, 29 Jun 2000 09:24:56 +0200
Subject: [Re: [Mailman-Users] Re: [Mailman-Developers] b3 not working anymore?]
Message-ID: <20000629092456.I688@miss-janet.com>

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

sorry for using 20 different from email addresses in 10 minutes, but forgive me
it's early in the morning... :)
anyway i can't find any errors in the log files either...
the MTA logs say nothing since postfix doesn't get contacted by mailman 
at all...

Ricardo.

--


--FCuugMFkClbJLl1L
Content-Type: message/rfc822
Content-Disposition: inline

Date: Thu, 29 Jun 2000 09:21:23 +0200
From: "Ricardo - Miss Janet . Fanclub" <ricardo@miss-janet.com>
To: "Barry A. Warsaw" <bwarsaw@beopen.com>
Subject: Re: [Mailman-Users] Re: [Mailman-Developers] b3 not working anymore?
Message-ID: <20000629092123.H688@miss-janet.com>
References: <20000629082248.C688@miss-janet.com> <14682.61571.230240.875717@anthem.concentric.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jun 29, 2000 at 02:45:23AM -0400

Hi again :)

i just posted a test message, and what happens is this:
1) a file ends up in the qfiles the directory (.db and .msg)
2) a few seconds later the crontab qrunner seems to pick up 
the message since it gets removed from the directory
3) postfix doesn't seem to be contacted to send out the
message to the world...

I've to leave soon, but i'll dig more into it tonight when
I get back... since appearantly our list hasn't been running
since june 26... (the digest log hasnt been touch since then)

Ricardo.

--
International Janet Jackson fanclub called MISS JANET.
For more information write to:
Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands
Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com
Or check out our website: http://miss-janet.com


--FCuugMFkClbJLl1L--


From claw@kanga.nu  Thu Jun 29 09:42:54 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 01:42:54 -0700
Subject: [Mailman-Developers] Large mail system configuration
Message-ID: <28192.962268174@kanga.nu>

I found this while looking data about setting up SNMP monitors for
Exim (I'm instrumenting all my systems under Cricket -- Mailman
might be next if I can think of something valuable to watch):

  "The Exim Mail Transfer Agent in a Large Scale Deployment"

  http://www.kierun.org/academic/

Most likely there are similar papers about for other MTAs.  I
haven't looked.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From Gergely Madarasz <gorgo@caesar.elte.hu>  Thu Jun 29 13:22:59 2000
From: Gergely Madarasz <gorgo@caesar.elte.hu> (Gergely Madarasz)
Date: Thu, 29 Jun 2000 14:22:59 +0200 (METDST)
Subject: [Mailman-Developers] b3 not working anymore?
In-Reply-To: <14682.61571.230240.875717@anthem.concentric.net>
Message-ID: <Pine.A32.3.96.1000629141720.38725v-100000@caesar.power.elte.hu>

On Thu, 29 Jun 2000, Barry A. Warsaw wrote:

> 
> >>>>> "RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
> 
>     RK> I'm running the latest cvs (just updated again this morning
>     RK> just to be sure) but their doesn't seem to be any more posts
>     RK> being send out on the list??  they all arrive on the approval
>     RK> page, but once approved they vanish into nothing... I'm not
>     RK> sure how long this has been going on though...  anybody else
>     RK> having the same trouble?
> 
> Take a look in the qfiles directory.  Do you see a bunch of files with
> really long names and extensions .msg and .db?  You must reload the
> crontab.in file to get all the new cron scripts running at the right
> intervals.  Of primary importance is qrunner which clears the messages
> waiting in qfiles.
> 
> This is documented in the UPGRADING file, which I know no one will
> read.  Be prepared to answer this question over and over again. ;)

Does this mean that message delivery is not handled at all when the
incoming mail is passed to mailman, and every message needs to wait for a
cronjob to run ? 
I found the method used in 1.1 (try to deliver immediatelly, if it fails,
the cronjob will handle it) much more appropriate, even though it often
resulted in mail duplication (if the mail was handled the same time when
the cronjob was run, it was sometimes delivered by both methods), which
could have been fixed by some better locking mechanisom...

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/




From klm@digicool.com  Thu Jun 29 21:06:53 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 29 Jun 2000 16:06:53 -0400 (EDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
In-Reply-To: <20000629192114.5BD1D1D4B8@dinsdale.python.org>
Message-ID: <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>

On Wed, 28 Jun 2000 Dan Mick <Dan.Mick@West.Sun.COM> wrote:

> > I also have significant problems with the new moderation interface
> > which has removed significant functionality by showing only an
> > excerpted/truncated version of the held message in a TEXTAREA rather
> > than the entire message.  The old format of showing the entire
> > message allowed me as list moderator:
> > 
> >   a) To know exactly what I was approving, and thus not miss
> >   something untoward toward the end of a message.
> 
> Yes, I miss this too.  I wish the textareas had the entire message
> in it, so that they have both wonderful attributes of 1) not taking
> up page after page of browser area, but 2) having the whole
> daggone message (or at least the first N kB, where N is configurable).

While i think the configurable N has a place, i think there's a better
way to address what i see as the underlying issue.

On the one hand, hugh (the typical list manager) sometimes wants to
preview the entire contents of an arbitrarily large message.  On the
other hand, hugh often doesn't - a preview is sufficient, and on rare
occassions numerous gargantuan holds would make for a painfully huge
admindb page (though to bulk is hidden in the textareas, it still has
to be transmitted, and the browser still has to bloat to hold it).

What i would prefer is to keep the configurable-N-Kb textarea, and add
a link that goes to a page that exhibits the entire held message.
This should be not hard to implement, afford the desired discretion,
and avoid the unnecessary bulk...

Ken
klm@digicool.com



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 29 21:31:44 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 29 Jun 2000 13:31:44 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
Message-ID: <200006292030.NAA24862@utopia.west.sun.com>

> What i would prefer is to keep the configurable-N-Kb textarea, and add
> a link that goes to a page that exhibits the entire held message.
> This should be not hard to implement, afford the desired discretion,
> and avoid the unnecessary bulk...

You're right, but it's harder to implement, and I'm always on a
broadband connection.  ;)

It would obviously be better that way.



From claw@kanga.nu  Thu Jun 29 22:15:14 2000
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 29 Jun 2000 14:15:14 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Extremely High Membership lists
In-Reply-To: Message from Ken Manheimer <klm@digicool.com>
 of "Thu, 29 Jun 2000 16:06:53 EDT." <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>
References: <Pine.LNX.4.21.0006291548510.4484-100000@korak.digicool.com>
Message-ID: <10195.962313314@kanga.nu>

On Thu, 29 Jun 2000 16:06:53 -0400 (EDT) 
Ken Manheimer <klm@digicool.com> wrote:

> On Wed, 28 Jun 2000 Dan Mick <Dan.Mick@West.Sun.COM> wrote:

>> Yes, I miss this too.  I wish the textareas had the entire
>> message in it, so that they have both wonderful attributes of 1)
>> not taking up page after page of browser area, but 2) having the
>> whole daggone message (or at least the first N kB, where N is
>> configurable).
...
> What i would prefer is to keep the configurable-N-Kb textarea, and
> add a link that goes to a page that exhibits the entire held
> message.  This should be not hard to implement, afford the desired
> discretion, and avoid the unnecessary bulk...

Good point.  When I get a chance later I'll update my patch to
beta3, and then have a stab at the "other" page bit.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From ckolar@admin.aurora.edu  Thu Jun 29 22:39:45 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Thu, 29 Jun 2000 16:39:45 -0500
Subject: [Mailman-Developers] Re: [Mailman-Users] Question: signup box kluge
In-Reply-To: <200006290106.SAA27534@utopia.west.sun.com>
Message-ID: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>

At 08:07 PM 6/28/2000, Dan wrote:
>The answer was "what's the question"?
>
>What does it mean to "type an email address and hit a submit button"?
>Yeah, one could add that right away:
>
><FORM METHOD=POST ACTION=....uh....what?>

[note to developers: is there a more elegant way to implement this?]

The list is not being very helpful today.  I think that what this person 
wants is something like the quickie subscription boxes that you see for 
eGroups of ListBot.    I have been working on something like this for a few 
lists that I run.  As long as security is not that important, it is 
possible to work the subscription box into a web page.

NOTE: this is a really quick kluge.

NoTE:  this is really not secure, I only use it on lists where it does not 
matter that much.

To use:

Drop into a page.  Edit the ACTION line to point to the proper 
server/listname on your MM server.  Also edit the two password fields so 
that they are the same.  What this will do is provide an initial password 
for the user, making joining easy.  What this will also do is provide the 
same initial password for all users, so IT IS NOT REALLY SECURE.  At least 
change it to something sufficiently random looking to encourage people to 
change it themselves.

Here is the HTML:

<!-- Begin insecure MM list signup box kluge. -->

<FORM METHOD="POST"
  ACTION="http://www.aocn.aurora.edu/mailman/subscribe/ilcomnets">
<!-- You will need to customize the above line for your site and list. 
--><P> </P>
<TABLE COLS="1" BORDER="0" CELLSPACING="4" CELLPADDING="5">
<TR>
<TD COLSPAN="2" WIDTH="100%" BGCOLOR="#99CCFF" ALIGN="CENTER"> <B><FONT
COLOR="#000000" SIZE="+1">ilcomnets -- Illinois Community Networking
List</FONT></B> </TD>
</TR>
<TR>
<TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> <B><FONT
COLOR="#000000">Subscribing to ilcomnets</FONT></B> </TD>
</TR>
<TR>
<TD COLSPAN="2"> <P> Subscribe to ilcomnets by filling out the following form.
You will be sent email requesting confirmation, to prevent others from
gratuitously subscribing you. This is a private list, which means that the
members list is not available to non-members. </P>
<TABLE WIDTH="65%">
<TR>
<TD>Your email address:</TD>
<TD><INPUT TYPE="Text" NAME="email" SIZE="30"></TD>
</TR>
<TR>
<TD COLSPAN="2"><INPUT TYPE="HIDDEN" NAME="pw" SIZE="15"
VALUE="ENTERSOMETHING"><INPUT TYPE="HIDDEN" NAME="pw-conf" SIZE="15"
VALUE="ENTERSOMETHING"> </TD>
</TR>
<!-- The terms ENTERSOMETHIN should be replaced on your site with something 
random. Note that this is the default password and it will be the same for 
everyone, so do not use this on a list where you need to have real 
security.  --><TR>
<TD>Would you like to receive list mail batched in a daily digest? </TD>
<TD><INPUT TYPE="radio" NAME="digest" VALUE="0" CHECKED="CHECKED"> No
<INPUT TYPE="radio" NAME="digest" VALUE="1"> Yes </TD>
</TR>
<TR>
<TD COLSPAN="2"> <CENTER>
<INPUT TYPE="Submit" NAME="email-button" VALUE="Subscribe">
</CENTER>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</FORM>

<!-- End insecure MM list signup box kluge. -->

And if anyone posts this without modification and I start to see lots of 
subscribers to ilcomnets then I will come after you with a vengeance.

--chris


 > --- Todd LaClair <todd.laclair@mail.dreamtheater.com>
> > > wrote:
>
> > >If I wanted to have a box on my webpage where a user would type their 
> email
> > >address and hit a submit button. Would MailMan be the best product to 
> manage
> > >this user list?


--
/////\\\\\/////\\\\\
  Christopher G. Kolar
    Director, Department of Instructional Technology
    Aurora University, Aurora, Illinois
  ckolar@admin.aurora.edu  --  www.aurora.edu/~ckolar
         [PGP Public Key ID: 0xC6492C72]



From Dan Mick <Dan.Mick@West.Sun.COM>  Thu Jun 29 22:55:15 2000
From: Dan Mick <Dan.Mick@West.Sun.COM> (Dan Mick)
Date: Thu, 29 Jun 2000 14:55:15 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Question: signup box kluge
Message-ID: <200006292154.OAA29267@utopia.west.sun.com>

> >The answer was "what's the question"?
> >
> >What does it mean to "type an email address and hit a submit button"?
> >Yeah, one could add that right away:
> >
> ><FORM METHOD=POST ACTION=....uh....what?>
> 

> The list is not being very helpful today.  I think that what this person 
> wants is something like the quickie subscription boxes that you see for 
> eGroups of ListBot. 

Ah.. Well, if the word "subscribe" had appeared anywhere in the question,
I might agree that you were right...but there's no way to tell
that.

Todd, didn't you ask the original question?  Is there some
reason you're not clarifying this?

> --- Todd LaClair <todd.laclair@mail.dreamtheater.com> wrote:
>
> If I wanted to have a box on my webpage where a user would type their
> email address and hit a submit button. Would MailMan be the best
> product to manage this user list?



From granveau@worldnet.fr  Thu Jun 29 23:49:27 2000
From: granveau@worldnet.fr (Boris Granveaud)
Date: Fri, 30 Jun 2000 00:49:27 +0200
Subject: [Mailman-Developers] Mailman 2.0b3 and gate_news
Message-ID: <395BD277.214B60F1@worldnet.fr>

Hello everybody,

I've just upgraded from b2 to b3 and I have the following error that the
cron daemon sends me by mail:

/home/python/bin/python -S /home/mailman/bigophone/cron/gate_news
produced the following output:

Traceback (innermost last):
  File "/home/mailman/bigophone/cron/gate_news", line 225, in ?
    main()
  File "/home/mailman/bigophone/cron/gate_news", line 203, in main
    process_lists(lock)
  File "/home/mailman/bigophone/cron/gate_news", line 188, in
process_lists
    syslog('fromusenet', '%s watermark: %d' %
TypeError: illegal argument type for built-in operation

Boris Granveaud.




From ricardo@rixhq.nu  Thu Jun 29 23:59:06 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 30 Jun 2000 00:59:06 +0200
Subject: [Mailman-Developers] approval & b3
Message-ID: <20000630005905.G1586@miss-janet.com>

Hi,

I just found out that our list hasn't been sending mail for a few days
now. All messages must go to approval on the admindb page, but even though
the moderators have been approving lots of mail every day, they never got
send out. I've always been running an up to date cvs version and it could
be that a certain change in de source a few days ago somehow conflicts with my setup.
I have another small list running on the same mailman that doesn't have
approval but posts are send out like they should. So it must be some
oddity in the approval code. From what I can see is that is goes like
this:
1) user sends message to list
2) mm holds it back for approval (message is stored in ~mailman/data)
3) moderator approves messages 
4) mm puts the appropiate db and msg file in ~mailman/qfiles
5) crontab runs qrunner
6) qrunner sends queued mail to list [*this seems the thing NOT working in my setup]
7) qrunner removes the files from ~mailman/qfiles (this IS working even though nothing gets send!)

some extra info:
1) postfix only logs step 1... at step 6 qrunner doesn't even contact postfix
2) Defaults.py has a 'SMTPPORT=0' -- i thought that was the problem, and that it should be 25, but
   changing it to 25 doesn't help anything :(
3) no errors or weird info in ~mailman/logs

the only way i can think of fixing everything is restart with a complete new install,
but that is going to be a lot of extra work to get all the settings back on the list...
plus i'm not 100% sure if that would fix anything at all...


Ricardo.

--



From GLeblanc@cu-portland.edu  Fri Jun 30 00:10:21 2000
From: GLeblanc@cu-portland.edu (Gregory Leblanc)
Date: Thu, 29 Jun 2000 16:10:21 -0700
Subject: [Mailman-Developers] RE: [Mailman-Users] Question: signup box kluge
Message-ID: <A5F46F4ED18FD211ABEE00105AC6CF0701093874@email.cu-portland.edu>

> -----Original Message-----
> From: Christopher Kolar [mailto:ckolar@admin.aurora.edu]
> Sent: Thursday, June 29, 2000 2:40 PM
> To: mailman-users@python.org; mailman-developers@python.org
> Cc: todd.laclair@mail.dreamtheater.com
> Subject: Re: [Mailman-Users] Question: signup box kluge
> 
> At 08:07 PM 6/28/2000, Dan wrote:
> >The answer was "what's the question"?
> >
> >What does it mean to "type an email address and hit a submit button"?
> >Yeah, one could add that right away:
> >
> ><FORM METHOD=POST ACTION=....uh....what?>
> 
> [note to developers: is there a more elegant way to implement this?]
> 
> The list is not being very helpful today.  I think that what 
> this person 
> wants is something like the quickie subscription boxes that 
> you see for 
> eGroups of ListBot.    I have been working on something like 
> this for a few 
> lists that I run.  As long as security is not that important, it is 
> possible to work the subscription box into a web page.

I was the first reply, and will take full responsibility for not being
helpful.  However, I, and at least one other person, was not clear on what
this person wanted to do.  I asked politely for some clarification, but
didn't get any.  Sorry if that offended anybody, but we really didn't
understand the question

> NOTE: this is a really quick kluge.
> 
> NoTE:  this is really not secure, I only use it on lists 
> where it does not 
> matter that much.
> 
> To use:
> 
> Drop into a page.  Edit the ACTION line to point to the proper 
> server/listname on your MM server.  Also edit the two 
> password fields so 
> that they are the same.  What this will do is provide an 
> initial password 
> for the user, making joining easy.  What this will also do is 
> provide the 
> same initial password for all users, so IT IS NOT REALLY 
> SECURE.  At least 
> change it to something sufficiently random looking to 
> encourage people to 
> change it themselves.

If you've got any sort of scripting language available on your server, like
ColdFusion, PHP, or whatever, it should be easy enough to generate a random
password here.  

[snip]
>  > --- Todd LaClair <todd.laclair@mail.dreamtheater.com>
> > > > wrote:
> >
> > > >If I wanted to have a box on my webpage where a user 
> would type their 
> > email
> > > >address and hit a submit button. Would MailMan be the 
> best product to 
> > manage
> > > >this user list?
> 
> 
> --
> /////\\\\\/////\\\\\
>   Christopher G. Kolar
>     Director, Department of Instructional Technology
>     Aurora University, Aurora, Illinois
>   ckolar@admin.aurora.edu  --  www.aurora.edu/~ckolar
>          [PGP Public Key ID: 0xC6492C72]
> 
> 
> ------------------------------------------------------
> Mailman-Users maillist  -  Mailman-Users@python.org
> http://www.python.org/mailman/listinfo/mailman-users
> 


From jim@cosource.com  Fri Jun 30 00:37:30 2000
From: jim@cosource.com (Jim Hebert)
Date: Thu, 29 Jun 2000 19:37:30 -0400 (EDT)
Subject: [Mailman-Developers] Re: Question: signup box kluge
In-Reply-To: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>
Message-ID: <Pine.LNX.4.10.10006291836480.25267-100000@ray.compu-aid.com>

[re: embed pw and pw-conf as hardcoded, hidden inputs]

You could use either a server side solution (php, xssi, whatever) or a
client side solution (javascript, etc) to give the two hidden password
fields random values.

jim
ashamed at his stupid hacks sometimes =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox




From chuqui@plaidworks.com  Fri Jun 30 01:35:23 2000
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 29 Jun 2000 17:35:23 -0700
Subject: [Mailman-Developers] freshmeat...
Message-ID: <p04320409b5819bb44ccd@[209.239.169.197]>

Just a nudge, Barry, to remind you to update freshmeat to show the 
new beta release...

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"


From bwarsaw@beopen.com  Fri Jun 30 04:07:27 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 29 Jun 2000 23:07:27 -0400 (EDT)
Subject: [Mailman-Developers] Re: quick-fix patch for newlist failure
References: <200006292103.OAA26391@utopia.west.sun.com>
Message-ID: <14684.3823.645620.176283@anthem.concentric.net>

>>>>> "DM" == Dan Mick <Dan.Mick@West.Sun.COM> writes:

    DM> Here's a fix that's probably safe, and fixes the "newlist"
    DM> problem.  Of course I'm not sure if it's the right final fix,
    DM> but I figure while Barry's examining the problem, this might
    DM> be worth a try for some of you.

I just got back from a gig -- thanks for the quick fix Dan.  Here's a
slightly better one that also fixes a few other ugly bits.

This is serious enough to warrant a quick beta4, but I want to spend a
couple of hours looking into Ricardo's problem (which I still can't
reproduce).  Better that then having to do a beta5 over the weekend ;}
I'm just too beat tonight.

-Barry

Index: MailList.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v
retrieving revision 1.172
diff -u -r1.172 MailList.py
--- MailList.py	2000/06/28 18:40:48	1.172
+++ MailList.py	2000/06/30 03:04:42
@@ -782,23 +782,21 @@
         Utils.MakeDirTree(os.path.join(mm_cfg.LIST_DATA_DIR, name))
 	self._full_path = os.path.join(mm_cfg.LIST_DATA_DIR, name)
 	self._internal_name = name
-	self.Lock()
-	self.InitVars(name, admin, crypted_password)
-	self._ready = 1
-	self.InitTemplates()
-	self.Save()
-	self.CreateFiles()
-
-    def CreateFiles(self):
+        # Don't use Lock() since that tries to load the non-existant config.db
+        self.__lock.lock()
+        self.InitVars(name, admin, crypted_password)
+        self._ready = 1
+        self.InitTemplates()
+        self.Save()
 	# Touch these files so they have the right dir perms no matter what.
 	# A "just-in-case" thing.  This shouldn't have to be here.
 	ou = os.umask(002)
 	try:
-	    open(os.path.join(mm_cfg.LOCK_DIR, '%s.lock' % 
-			      self._internal_name), 'a+').close()
-	    open(os.path.join(self._full_path, "next-digest"), "a+").close()
-	    open(os.path.join(self._full_path, "next-digest-topics"),
-		 "a+").close()
+            path = os.path.join(self._full_path, 'next-digest')
+            fp = open(path, "a+")
+            fp.close()
+	    fp = open(path+'-topics', "a+")
+            fp.close()
 	finally:
 	    os.umask(ou)
 	


From agemo@agemo.cc  Fri Jun 30 14:04:05 2000
From: agemo@agemo.cc (agemo@agemo.cc)
Date: Fri, 30 Jun 2000 15:04:05 +0200 (CEST)
Subject: [Mailman-Developers] Config.db
Message-ID: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>

Hi,

I'm sorry for my bad english...

I'd like to read the file config.db with a perl-program, where I can read
informations about the file format?

Thank's to all.

Ciao Davide
--
Davide Rizzo agemo@agemo.cc




From ckolar@admin.aurora.edu  Fri Jun 30 15:00:50 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Fri, 30 Jun 2000 09:00:50 -0500
Subject: [Mailman-Developers] Re: Question: signup box kluge
In-Reply-To: <Pine.LNX.4.10.10006291836480.25267-100000@ray.compu-aid.co
 m>
References: <4.3.2.7.2.20000629162858.00d17a40@admin.aurora.edu>
Message-ID: <4.3.2.7.2.20000630084953.00b1c750@admin.aurora.edu>

At 06:37 PM 6/29/2000, Jim Hebert wrote:
>[re: embed pw and pw-conf as hardcoded, hidden inputs]
>You could use either a server side solution (php, xssi, whatever) or a
>client side solution (javascript, etc) to give the two hidden password
>fields random values.
>jim
>ashamed at his stupid hacks sometimes =)

I was wondering how the code for random assignment of password is 
implemented in the admin's membership mass-subscribe function.  What if 
there was a reserved word, say RANDU, that the subscription script would 
recognize.  If you created a subscription box like I did, but in the hidden 
field put in RANDU, it would call the random algorithm that is used by mass 
subscribe to assign a password for the user.

Those tiny boxes sure are convenient, it would be nice if a little hook 
like this could be put in to support it.

--chris



From bwarsaw@beopen.com  Fri Jun 30 16:03:57 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 11:03:57 -0400 (EDT)
Subject: [Mailman-Developers] Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
Message-ID: <14684.46813.76030.881531@anthem.concentric.net>

>>>>> "agemo" ==   <agemo@agemo.cc> writes:

    agemo> I'd like to read the file config.db with a perl-program,
    agemo> where I can read informations about the file format?

The config.db is a marshal[1] of a Python dictionary object.  The
marshal format, however, is undocumented on purpose.  The contents of
the dictionary are all the attribute/value pairs of the MailList
instance.  See MailList.Save() and MailList.Load() for details.

-Barry

[1] http://www.python.org/doc/current/lib/module-marshal.html


From Dan.Mick@west.sun.com  Fri Jun 30 19:23:10 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Fri, 30 Jun 2000 11:23:10 -0700
Subject: [Mailman-Developers] Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net>
Message-ID: <395CE58E.D4512B7B@west.sun.com>


"Barry A. Warsaw" wrote:
> 
> >>>>> "agemo" ==   <agemo@agemo.cc> writes:
> 
>     agemo> I'd like to read the file config.db with a perl-program,
>     agemo> where I can read informations about the file format?
> 
> The config.db is a marshal[1] of a Python dictionary object.  The
> marshal format, however, is undocumented on purpose.  The contents of
> the dictionary are all the attribute/value pairs of the MailList
> instance.  See MailList.Save() and MailList.Load() for details.
> 
> -Barry
> 
> [1] http://www.python.org/doc/current/lib/module-marshal.html

Perhaps a portable method would be something like "dumpdb", perhaps 
modified slightly to be a little more parsing-friendly?  (if readonly
access is all that's required..)


From dgc@uchicago.edu  Fri Jun 30 20:02:53 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 30 Jun 2000 14:02:53 -0500
Subject: [Mailman-Developers] Re: Config.db
In-Reply-To: <395CE58E.D4512B7B@west.sun.com>; from Dan.Mick@west.sun.com on Fri, Jun 30, 2000 at 11:23:10AM -0700
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net> <395CE58E.D4512B7B@west.sun.com>
Message-ID: <20000630140253.D3359@smack.uchicago.edu>

On 2000.06.30, in <395CE58E.D4512B7B@west.sun.com>,
	"Dan Mick" <Dan.Mick@west.sun.com> wrote:
> 
> Perhaps a portable method would be something like "dumpdb", perhaps 
> modified slightly to be a little more parsing-friendly?  (if readonly
> access is all that's required..)

I would appreciate being able to load an edited dump, too.  To me, this
nonportability -- and thus the mere fact of using the Marshal module --
is very disturbing.  That's considerably mitigated if there are tools
for conversion in both directions, though.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@beopen.com  Fri Jun 30 20:13:17 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 15:13:17 -0400 (EDT)
Subject: [Mailman-Developers] Re: Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
 <14684.46813.76030.881531@anthem.concentric.net>
 <395CE58E.D4512B7B@west.sun.com>
 <20000630140253.D3359@smack.uchicago.edu>
Message-ID: <14684.61773.275647.868844@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> I would appreciate being able to load an edited dump, too.  To
    DC> me, this nonportability -- and thus the mere fact of using the
    DC> Marshal module -- is very disturbing.  That's considerably
    DC> mitigated if there are tools for conversion in both
    DC> directions, though.

I'm not exactly sure why you want such conversion tools.  It's very
easy to write a little Python script to hack on or inspect config.db
(see bin/dumpdb), but I'm not even sure why you'd want to do that
either.

Suffice to say that /eventually/ config.db will go away because all
this information will live in a real database.

-Barry


From dgc@uchicago.edu  Fri Jun 30 20:31:55 2000
From: dgc@uchicago.edu (David Champion)
Date: Fri, 30 Jun 2000 14:31:55 -0500
Subject: [Mailman-Developers] Re: Config.db
In-Reply-To: <14684.61773.275647.868844@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jun 30, 2000 at 03:13:17PM -0400
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc> <14684.46813.76030.881531@anthem.concentric.net> <395CE58E.D4512B7B@west.sun.com> <20000630140253.D3359@smack.uchicago.edu> <14684.61773.275647.868844@anthem.concentric.net>
Message-ID: <20000630143155.F3359@smack.uchicago.edu>

On 2000.06.30, in <14684.61773.275647.868844@anthem.concentric.net>,
	"Barry A. Warsaw" <bwarsaw@beopen.com> wrote:
> 
> I'm not exactly sure why you want such conversion tools.  It's very

Hypothetical example: when people fill out the form to request a
mailing list, they check off boxes for the initial configuration of the
list, and we generate the list in that configuration.

Or: it's the end of an academic year, and we've just closed 6,000
accounts.  We want to either rewrite subscriptions with people's new
alumni addresses, or remove them from the list.  (The latter's not
a big problem, I know.)

Or: again, it's the end of a year, and we've just closed 40 accounts
which own mailing lists.  We need to lock the lists pending resolution
of new ownership, because our EAUP prohibits services which don't have
accounts-eligible sponsors.

Is that convincing?

> easy to write a little Python script to hack on or inspect config.db
> (see bin/dumpdb),

Yes, but it's easier if I don't need to learn Python first (and do it
in a language that I'm going to use for other, related tasks).  None
of my administrative tools written in C, Perl or shell require
integration with (correspondingly) C, Perl, or shell.  Why should my
Python software require irt with Python?

> Suffice to say that /eventually/ config.db will go away because all
> this information will live in a real database.

That's good, too, if the database isn't required to be SQL or
something.  I think JC said that it was to be pretty open, though.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago


From bwarsaw@beopen.com  Fri Jun 30 20:49:16 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 30 Jun 2000 15:49:16 -0400 (EDT)
Subject: [Mailman-Developers] Re: Config.db
References: <Pine.LNX.4.10.10006271604490.1384-100000@tobia.agemo.cc>
 <14684.46813.76030.881531@anthem.concentric.net>
 <395CE58E.D4512B7B@west.sun.com>
 <20000630140253.D3359@smack.uchicago.edu>
 <14684.61773.275647.868844@anthem.concentric.net>
 <20000630143155.F3359@smack.uchicago.edu>
Message-ID: <14684.63932.397328.25837@anthem.concentric.net>

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> Hypothetical example: when people fill out the form to request
    DC> a mailing list, they check off boxes for the initial
    DC> configuration of the list, and we generate the list in that
    DC> configuration.

This can be done with bin/config_list.

    DC> Or: it's the end of an academic year, and we've just closed
    DC> 6,000 accounts.  We want to either rewrite subscriptions with
    DC> people's new alumni addresses, or remove them from the list.
    DC> (The latter's not a big problem, I know.)

bin/clone_member or bin/remove_member

    DC> Or: again, it's the end of a year, and we've just closed 40
    DC> accounts which own mailing lists.  We need to lock the lists
    DC> pending resolution of new ownership, because our EAUP
    DC> prohibits services which don't have accounts-eligible
    DC> sponsors.

Hmm, that's harder and I think being able to write to config.db would
even help you there.  What's involved in `locking a list'?  Do you
mean that email to the address should bounce, should autorespond but
not forward the email, hold the mail in a quarantine for later
delivery if the list is enabled?

    DC> Is that convincing?

Somewhat.  I totally agree that you'll want to be able to have script
and command-line access to list configurations, but I believe the
tools already exist to do this without having to touch config.db
directly.  I'd maintain largely the same attitute if there was a real
db on the back-end.

    >> easy to write a little Python script to hack on or inspect
    >> config.db (see bin/dumpdb),

    DC> Yes, but it's easier if I don't need to learn Python first
    DC> (and do it in a language that I'm going to use for other,
    DC> related tasks).  None of my administrative tools written in C,
    DC> Perl or shell require integration with (correspondingly) C,
    DC> Perl, or shell.  Why should my Python software require irt
    DC> with Python?

Well, I won't answer that learning Python takes about half a day for
anybody with C or Perl experience <wink>.

    >> Suffice to say that /eventually/ config.db will go away because
    >> all this information will live in a real database.

    DC> That's good, too, if the database isn't required to be SQL or
    DC> something.  I think JC said that it was to be pretty open,
    DC> though.

My very vague thoughts at the moment are that there will be a db API
with pluggable back-ends.  We'll ship with a connection to a GPL
compatible database (e.g. PostgreSQL, MySQL, ZODB) but you'd be able
to swap out the back-end if you want.

-Barry